I have created an account for backup purposes on my Synology NAS. I have put it into all backup jobs and it works fine for backing up. Nonetheless, it appears that this account isn’t used by the application to clean up obsolete files.
When you say “clean up obsolete files” do you mean removing old versions of files from your backups or do you mean removing actual backup (dblock) archive files?
The second: “Access to the path “/Volumes/auto/XXXX/xxx-bd673be617fcc4406b0590d10f52ec427.dblock.zip” is denied.”
How are you determining that that the account isn’t being used?
It’s just my guess as backup procedure works well to ADD files, nonetheless it can’t remove them anymore since I’ve specified the backup account in the task settings.
I’ve also tested it manually, and I confirm that this account can delete files from the share.
I’m using SMB shares. They are mounted on my Mac as Volumes therefore I’ve specified the volume name in Duplicati settings (nothing like “smb://…”). Have never experienced any problems with data exchange. Only now (with obsolete dblock) as I’ve decided to use a special account for backup purposes. It’s because my own account doesn’t have RW access to the shares anymore for extra data protection.
I’d start by making a test backup in the same way as the one that’s failing (but with a smaller source, to a unique destination folder, and without scheduled backups). Note that if a user account change happened with the erroring one, out should be replicated with the new one.
Run the job, change the user account, then try deleting the job (including remote files).
I was thinking about the issue for a couple of days. It appears that the issue is related to how Duplicati works with network drives on MacOS. It’s not about Synology as any network shares experience the same problem. Look:
When I log in, MacOS automatically mounts the NAS share for backups (\Volumes\backup). Remember: now it’s read-only.
When Duplicati start the backup task, it’s trying to use the same share (\Volumes\backup). The fact that I’ve put another credentials in the task settings is irrelevant as the share is mounted already!
As far as I understand, it should be possible to specify the share network name, not local name. I.e. something like “smb://nas/backup” instead of “/Volumes/backup”. Only is such a case Duplicati could mount the share using the correct credentials.
Another idea is to always mount the share using backup credentials. Which is completely stupid as the reason for this special backup account was to zero chances of backup modification (because of human mistake or encrypting virus).
One more idea: is it somehow possible to specify pre-back and post-backup actions? In such a case it won’t be a big problem to mount the share using the proper account, and unmount after the backup operation.
You can use the --run-script-before, --run-script-before-required and --run-script-after. --run-script-before-required will abort the backup job is the scripts end with an error level other than 0.
Use --run-script-timeout to specify how long Duplicati will wait for completion of the script. Default value is 60 seconds.
Still thinking about this issue. Look:
There are a number of tasks (about 10) scheduled at, say, 0:01, 0:02, 0:03 and so on just to be sure that they will run in the proper order. Actually, all of them take many minutes (the last - up to 2h). As far as I understand, there is a scheduler / queue in Duplicati, therefore they won’t simultaneously, that’s good.
I suppose, instead of running mount and unmount before and after each task, it would be great to mount the share as the first (virtual?) task and unmount as the last (virtual?) task. Hence, I’m going to create two tasks:
At 00:00 (before any real task) to backup nothing, just run a script to mount the share.
At 00:10 (after any real task) to backup nothing, just run a script to unmont.
Is it a good plan?
I expect that would work as you describe, though you might want to check if the share exists before trying to mount it - just in case something happens causing “yesterday’s” step 2 to not fire thus leaving the share mounted.