Corrupt chunk only on second storage, not checked for 10 days,

Support
,
#1

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)

  1. why was it created on May 2 but not getting checked until May 13?
  2. should I add another -v or -d to my Duplicacy calls so they log every chunk they read/write in backup/copy/prune operations to identify this in the future?
#2

One thing I would try to separate is: is the object on Filen actually different/corrupt, or is Duplicacy only now reaching a snapshot that references it?

For this chunk I would first compare the object itself, not only the Duplicacy log: size/date in Filen, and if the same chunk exists anywhere in the first storage, the size there too. If pCloud really has no chunks/9a/b812… object but the snapshots reference it on Filen, that sounds more like something went wrong during the copy/upload path than a normal prune issue.

For logging, a temporary run with more debug output seems reasonable, but I would not leave very verbose chunk logging enabled permanently unless you rotate the logs. I would also run the check against one affected revision, e.g. revision 169, and then one later affected revision, so the next log is smaller and easier to match to the rclone PUT/GET lines.

1 Like