Failed to decrypt error message

Hi gchen,

I backup from a Mac (10.13.3) to an AFP LAN mounted NAS drive and then use copy to replicate it to OneDrive. First 19 backup and copy revisions worked ok then with revision 20 the backup worked but the copy failed with the following error:

[fragment]

Chunk 41a3ffba2f63f7249faa51a736740588196965781a9b9d6de6aa6a3ede681721 (6717/15335) skipped at the destination
Chunk 8d027d92056253ce3dd2ae7f8e1643909620abef10d58aceb9c42afec77a13a6 (6718/15335) skipped at the destination
Copying chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec to 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed

After that further backups fail with the same message.

Storage set to /nas02/backup.users/
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed

Below is the corresponding check with -d :

Root# duplicacy_osx_x64_2.0.10 -d check -id users -files -r 20
Storage set to /nas02/backup.users/
Reading the environment variable DUPLICACY_PASSWORD
Reading password from preferences
Using 16384 iterations for key derivation
Chunk read levels: [1], write level: 1
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: 720706356b20259bd55394ff004871ad9cc5b6eb66ce4812879cf57a5c87c756
Reading the environment variable DUPLICACY_PASSWORD
Reading password from preferences
id: users, revisions: [20], tag: , showStatistics: false, checkFiles: true, searchFossils: false, resurrect: false
Listing all chunks
Listing chunks/
Listing chunks/ff/

Etc.

Listing chunks/02/
Listing chunks/01/
Listing chunks/00/
Downloaded file snapshots/users/20
Chunk dde41af50c6754ac06cb120a406ed2495ac31953faf5cd80b067e8b17367096d has been downloaded
Fetching chunk 805afe03ec5e6adefdf0e3918b222c979c536271bc58e733979676cfcc273a82
Chunk 805afe03ec5e6adefdf0e3918b222c979c536271bc58e733979676cfcc273a82 has been downloaded

Etc.

Fetching chunk 5cd5c95cee7d17e5f198561c0f72e4949e66dfa7d8e3a07576b43ea262a87f48
Chunk 5cd5c95cee7d17e5f198561c0f72e4949e66dfa7d8e3a07576b43ea262a87f48 has been downloaded
Fetching chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed; retrying
Failed to decrypt the chunk 98820ec50b224aefbbe45188d6d777db0a85154590764edfbb53582cbf4c1aec: cipher: message authentication failed

This chunk does exist on the NAS drive but not in OneDrive.

As far as I am aware there’s been no interruption to the backup or copy apart from the usual odd time-out when copying to OneDrive. Is there a way to resolve this rather than start again? I see one other similar issue in your forum where the advice was deleting the chunk and getting it to re-upload and I’m not sure that’s applicable in my case.

The only thing I could think of was purging revision 20 resolve it - would this work?

Thanks for your help, Guy.

So for some reason this chunk is corrupted.

Is revision 20 the latest revision? If not, there could be other revisions affected by this chunk

You can try to delete the chunk from NAS and run duplicacy backup -hash to see if it can recreate this chunk. Otherwise, you’ll have to remove the affected revision(s) by manually removing the revision files and run duplicacy prune -exclusive -exhaustive (make sure that not other backups are running).

Revision 20 is the latest and last backup. I ran a check on revision 19 and this ran clean. Therefore could you please advise what the cleanest fix is, delete the chunk or purge revision 20. Could you also clarify what ‘manually removing the revision files’ means: Is that deleting 20 from the repository cache and the storage?
Thanks, Guy.

Sorry for intruding on the topic.

I thought this -hash option only detected the differences.

From wiki:

-hash detect file differences by hash (rather than size and timestamp)

Does it recreate the chunks?

My bad. To be able to recreate the chunks, the -hash option isn’t enough. There should be another option to disable using the chunks from last snapshot as a cache. That is, for every chunk created from splitting local files, a look up is performed to check if it exists in the storage, as opposed to assuming chunks from last snapshot always exist by default.

So the only way to recreate the chunks now as explained in the wiki page is to switch to a new repository id (by editing the .duplicacy/preferences file) and perform an initial backup.

Yes, ‘manually removing the revision files’ means removing the file named repository_id/20 from the local cache and the storage.

Just to finish off the thread for those finding a similar problem. The resolution of my issue worked as gchen explained above.

The corrupted chunk was only in revision 20 (and in my case that was the last successful backup), confirmed by running a check -r backwards through the revisions. I deleted the revision 20 file manually from the repository cache and the storage cache and then ran a prune -exclusive -exhaustive.

The next backup, a new revision 20, completed successfully as well as the copy to a 2nd storage on OneDrive.

Thanks for the support, Guy.

Hi gchen,

I have had a repeat of this problem:

Failed to decrypt the chunk b3a18a7966835e1a8c5304fde9426f749f688ef621a95f3f79ff39a2536c8be2: cipher: message authentication failed; retrying
Failed to decrypt the chunk b3a18a7966835e1a8c5304fde9426f749f688ef621a95f3f79ff39a2536c8be2: cipher: message authentication failed

When copying from AFP mounted NAS drive on 1G wired network to OneDrive with a 10mbps upload and also now a new error during the backup phase:

The next day’s backup ran without error.

As there’s little traffic on this issue in the forums it’s likely to be my set-up up but could you please suggest some further diagnostics?

Everything, e.g. versions, repositories, storage, etc. is as per my original post.

Thanks, Guy.

Both the decryption errors and the input/output error are likely caused by bad sectors on the NAS drive. Maybe you can run a fsck on the drive?

Hello again, I’m still running into Failed to decrypt messages.

I ran several full disk checks and had a week or so without incident but errors started again - I think the improvement was coincidence or the disk failing. My other theory is the method the NAS is mounted to the Mac (I’m thinking autofs AFP mounted file systems are not a well used repository type?).

So before taking the more drastic step of a new disk my next move is to change it to appear as an SFTP storage backend.

Is there a way of doing this without starting from scratch?

Thank you. Guy.

You can just edit the .duplicacy/preferences file to change the storage url.

Ok hopefully I can close this thread once and for all.
Before I switched to SFTP I tried mounting the Mac to the NAS using SMB rather than AFP. Since then, 2 weeks, no further incidents so I’m putting this down to a slightly broken implementation of AFP on QNAP NAS drives. It was also faster so I’m kicking myself!
Thanks for all the advice and support for something that wasn’t a Duplicacy issue.
Guy.

For anyone: Feel free to use the :heart: button on the posts that you found useful.

For the OP of any support topic: you can mark the post that solved your issue by ticking the :ballot_box_with_check: box under the post. :slight_smile: