I’ve used forum posts (and LLMs) to deal with corrupt chunks before. Fortunately I have 2 storages and most of the time only 1 has a bad chunk. That said, I’m not sure how my latest situation has occurred, and I’d like advice on how to figure that out so I can prevent it. Forum posts mentioning “message authentication failed” have just advised how to move past it (create a new backup, delete affected snapshots), but that’s not quite what I’m going for here.
I have Duplicacy back up from local disk to storage pcloud-webdav, which is an rclone serve webdav endpoint for pCloud. I perform a duplicacy copy to storage filen-webdav, which is an rclone serve webdav endpoint for Filen.io. I then perform a duplicacy check -chunks and prune on each storage. I have both rclone serve instances running with one -v and logging to files. I run Duplicacy with -log -v and save the output as well.
Starting May 13, I have been having check failures for the filen-webdav storage with one chunk:
2026-05-13 06:51:26.536 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 9ab81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: cipher: message authentication failed; retrying
It is currently the only chunk that fails the check:
2026-05-25 16:51:48.301 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 9ab81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: cipher: message authentication failed; retrying
2026-05-25 16:52:02.930 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 9ab81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: cipher: message authentication failed; retrying
2026-05-25 16:52:12.056 WARN DOWNLOAD_RETRY Failed to decrypt the chunk 9ab81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: cipher: message authentication failed; retrying
2026-05-25 16:52:21.528 ERROR DOWNLOAD_DECRYPT Failed to decrypt the chunk 9ab81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: cipher: message authentication failed
But when I search all of my Duplicacy and rclone logs, this is the only evidence I find of this chunk’s existence:
rclone_filen.log:2026/05/02 05:28:32 INFO : //duplicacy-lore2/chunks/9a/b81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: PROPFIND from 127.0.0.1:38945
rclone_filen.log:2026/05/02 05:29:31 INFO : //duplicacy-lore2/chunks/9a/b81236aa5ce9b474952cf37a89380ec9771513a4b42e4f72d7a60082b6090a: PUT from 127.0.0.1:38945
I do not see this chunk in the rclone logs for pcloud, though I do find PUT events for other chunks on that day. I do not see this chunk in the verified chunks cache of the pcloud-webdav storage. I do not see this chunk in the pcloud file browser UI.
According to the Filen Web UI, this file was Uploaded May 02 2026 05:29:29, and Modified May 02 2026 05:28:32
It is not listed in duplicacy prune -storage filen-webdav -exhaustive -dry-run output.
If I rename this chunk and run another duplicacy check -chunks, it does complain that this chunk is referenced by snapshots 169 (created at 2026-05-02 05:06) through 187 (created at 2026-05-20 05:06)
- why was it created on May 2 but not getting checked until May 13?
- should I add another
-vor-dto my Duplicacy calls so they log every chunk they read/write in backup/copy/prune operations to identify this in the future?