Rclone serve and rclone check has output of ERROR : No common hash found - not using a hash for checks

Help and Support
1

How can you resolve this ERROR : No common hash found - not using a hash for checks?

PS C:> rclone version
rclone v1.58.1

  • os/version: Microsoft Windows 10 Pro for Workstations 21H2 (64 bit)
  • os/kernel: 10.0.19044.1706 (x86_64)
  • os/type: windows
  • os/arch: amd64
  • go/version: go1.17.9
  • go/linking: dynamic
  • go/tags: cmount

Using rclone serve webdav --addr :8000 .

rclone check . storage:

Results in ERROR : No common hash found - not using a hash for checks

I could not find any information on how to resolve this, or fix it?
I also could not find if this is a big issue?

2

Webdav servers don't support hashes by default (there is a special case for owncloud/nextcloud).

Its warning out that because it can't find a hash, all it is testing is file size and file presence.

If you want a better check than that you can use the --download flag which will stream the files from the server and check them against the local files.

3

Thank you @ncw

I figured that was the case, but it is hard to distill that out of the docs and it seems like an obvious case a person would do. While --download flag will work for me, it would be nice to suppress the "ERROR". "ERROR" also doesn't seem right when this is rclone talking to rclone in a supported way. Seems more like a warning possibly with more descriptive text saying backend doesn't support hashes. Thanks again

4

It should be an error message as if you have a backend that doesn't support hashes, it is telling there are no supported ways to perform the check as the check is generally expecting size and a hash.

The download flag says to do it without hashes:

      --download                Check by downloading rather than with hash
5

@ncw Thanks again. Further confusion happens with --etag-hash for rclone serve webdav which implies you should be able to include the hash. In testing locally this does not work. Thanks for the help.

6

@Animosity022 this is rclone talking to rclone. Sure seems like in this unique case it could be more intelligent about it. It heavily implies the user is doing something wrong using rclone, when they are actually encountering expected behavior.

7

If you try to run rclone check and you don't have hashes in common, it would be an error as check is supposed to compare hashes.

I'm not sure what is relevant about rclone to rclone as that's how rclone check works as you are normally checking remotes to remotes as a common pattern.

Some folks check local to remote as well as that's another pattern.

It has to be an error as the command isn't doing what it's supposed to be doing.

8

Here is the usecase. A person new to rclone installs it and wants to try it out locally. webdav looks like the easiest to try and see how it works on the localhost. So, the person runs rclone serve webdav and then runs a couple rclone copies or sync. Then the user performs a check and "ERROR". Wait, what did the person do that is an "ERROR"?

For webdav the command is doing what it is supposed to be against a webdav backend. @ncw confirmed this above.

9

Sorry as I'm not following as ERROR do not generally mean the person did something wrong.

ERRORs are flagged as they require attention. If there are no hashes, it needs to be an ERROR as the command did not do what was expected.

The documentation for rclone check notes all already as someone new would hopefully refer to the documentation.

rclone check

10

That's a good point.

The rclone WebDAV client doesn't look for etags as hashes - maybe it should.

Or maybe the WebDAV server should support hashes in the same way as ownclowd.

These are all possibilities waiting for someone to implement!

1 Like
11

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.