Failed to authenticate decrypted block - bad password?

[kapitainsky]

@nielash

@Droplet4147

server_side_across_configs = true

I wonder if this could have had something to do with the above... is it possible that at some point files were server-side-copied from google: to google-crypt: and this option caused only the filename (not the data) to get encrypted? (It shouldn't have... but maybe there was a bug?)

Given that using these options this way is not logical I was considering it myself as a possibility but:

@Droplet4147

Based on inspection of encrypted files using a hex editor, the headers seem to be correct and the contents of each file are different from each other and non-zero/null; possibly indicating that the files themselves are still there.

So I assume content is encrypted if it has crypt headers.

I have replicated exactly the same setup with gdrive, crypt and server_side_across_configs = true. All works perfectly fine. I can encrypt and decrypt files no issue. Of course there is always possibility that in some special cases (retry on throttle maybe) this flag interferers - but I can not reproduce it.

Now unfortunately as it is impossible to test original setup it is all in realm of speculations. Could be anything really. Interestingly there are few more similar topics on the forum - always about google drive. None was concluded definitely, e.g.:

Copy crypt-A->crypt-B/mount crypt-A no longer working- failed to authenticate decrypted block

What is the problem you are having with rclone? As of 3 hours ago I am no longer able to copy files from crypt-A over to crypt-B or download files to server/locally. Crypts use same pass and salt. Data is still visible inside crypt-A, but can not be streamed or downloaded via mount. Checking file size of crypt-A still seems to show correct values. Crypt-B seems to be fine. Run the command 'rclone version' and share the full output of the command. rclone v1.61.0, os/version: alpine 3.12.12 (64…