Unable to view Logs of, or Restore from, my backups

Hi all,

Apologies if this has already been covered; I did search the forums but couldn’t find any case matching my own.

So, I have had Duplicacy running on my NAS for a year or so now and everything seems fine. However, I had a call today to try and restore a specific file from the most recent backup and it failed. I naturally went to check the backup logs, but they are also throwing errors.
The situation currently is that my backups seem to be running as normal, but I can’t check the logs for them or restore from them.

The current setup

  • The NAS is a Synology DS224+, running two 4TB Ironwolf Pro in a RAID1 configuration.
  • I have Duplicacy installed onto the NAS via Docker. It has its own user account, which has total administrative access.
  • I have set up a range of backup schedules via the http://:3875/dashboard interface which connect up to my Backblaze bucket. These backup different folders of the NAS at different times and cycles, depending on need
  • The system has been running perfectly like this for well over a year, and I’ve always been able to read the logs of any particular scheduled backup and restore from backups

The current problem

When I go into the Schedule section of the Dashboard I see all my backups have run successfully (their status shows as green “Completed”). If I click that “Completed” status I usually expect to get a log file of the most recent backup, however I’m now getting messages like this:

Failed to open the log file /tmp/duplicacy/logs/backup-20260110-040026.log: open /tmp/duplicacy/logs/backup-20260110-040026.log: no such file or directory

This goes for every single backup schedule I check. Obviously the logfile nomenclature changes, but they always fail with the same message.

If I try to restore from a backup via the Dashboard then my Duplicacy connects up to my Backblaze bucket and I see the backups, all correctly dated (so I know it’s backing up).
However, if I try to restore a backup to my designated restore folder - /volume1/backup$/restore - and pick a single file, I get this:

The restore command encountered an error:
Failed to change uid or gid: lchown /volume1/backup$/restore/<FILE I'M TRYING TO RESTORE>: operation not permitted

Exit code: 100

Then, if I click the “View Log” button on that warning I get:

2026-01-12 10:11:51.282 INFO REPOSITORY_SET Repository set to /volume1/backup$/restore
2026-01-12 10:11:51.282 INFO STORAGE_SET Storage set to <MY BB BUCKET>
2026-01-12 10:11:51.778 INFO BACKBLAZE_URL Download URL is: <MY BB BUCKET>
2026-01-12 10:11:52.270 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
2026-01-12 10:11:53.146 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path
2026-01-12 10:11:53.146 INFO RESTORE_INDEXING Indexing /volume1/backup$/restore
2026-01-12 10:11:53.146 INFO SNAPSHOT_FILTER Parsing filter file /tmp/duplicacy/repositories/localhost/restore/.duplicacy/filters
2026-01-12 10:11:53.146 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2026-01-12 10:11:55.848 INFO RESTORE_START Restoring /volume1/backup$/restore to revision 49
2026-01-12 10:11:57.456 INFO DOWNLOAD_PROGRESS Downloaded chunk 1 size 2683237, 656KB/s 00:00:01 100.1%
2026-01-12 10:11:57.456 ERROR RESTORE_CHOWN Failed to change uid or gid: lchown /volume1/backup$/restore/<FILE I'M TRYING TO RESTORE>: operation not permitted

Obviously, I’ve replaced the specific private URLs with placeholder text here, but the URLs are correct and functional.

It looks like it’s gone and grabbed the file just fine, but won’t write it to disk.
What confuses me is that Duplicacy uses a special backup user I created solely for this purpose and that user absolutely has full rights over the NAS, not just the folder I’m trying to write to.

Possible Causes

Finally, I have made two recent changes to the NAS that may or may not be relevant.

  1. I recently updated the Synology DSM to 7.3.2-86009
  2. I’m currently trying to set up a Jellyfin media server in my NAS, so have just installed ‘Container Manager’ as part of that process

It might be that neither of these things is relevant, but I mention them for the sake of completeness.

So, after a lengthy explanation, does anyone know what steps I can take to correct this problem? As I said, the backups themselves seem to be running as always; but I can’t check the logs or restore from them.

Try add -ignore-owner to the restore option.

Even with enough permissions, I don’t think Duplicacy and/nor the container has the ability to chmod to their original perms unless running as root, so that flag would bypass all that.

This suggests to me you may have run out of disk space for the logs? Check the container’s df.

Either that, /tmp is probably not a good long term location for the logs if you specifically put it there. The container will likely delete everything in there at some point.

Thanks. The -ignore-owner worked perfectly and restores now write to my restore folder.

The logs still remain something of a mystery. There’s plenty of space available but, based on your advice, I’ve now created a specific folder for logs within the backup drive hierarchy and am using that. All seems to be working correctly again.