Hi,
I have Duplicati 2.0.8.1_beta_2024-05-07 on my Synology NAS (220+) running in Docker. I access Duplicati by entering the IP of my NAS with port 8200. A few weeks back I upgraded my NAS to the latest DSM (version 7.xxx). Today I tried to restore one little TXT-file from my backup-drive (which is a hdd plugged into another switch), which I accidentally deleted this morning.
There are about 10 different backuped versions in my backup. Duplicati takes about 2-3 minutes to restore the file and finishes with a successfull restorating. BUT at the same time throws me a red error message and three yellow warnings. The file is NOT restored. Following errors are shown (I changed the patch+filename to blabla.txt ofc):
2024-11-17 15:26:24 +01 - [Warning-Duplicati.Library.Main.Operation.RestoreHandler-TargetFileReadError]: Failed to read target file: “/syndocs/blabla.txt”, message: Access to the path “/syndocs/blabla.txt” is denied. UnauthorizedAccessException: Access to the path “/syndocs/blabla.txt” is denied.
2024-11-17 15:27:18 +01 - [Warning-Duplicati.Library.Main.Operation.RestoreHandler-PatchFailed]: Failed to patch file: “/syndocs/blabla.txt”, message: Access to the path “/syndocs/blabla.txt” is denied., message: Access to the path “/syndocs/blabla.txt” is denied. UnauthorizedAccessException: Access to the path “/syndocs/blabla.txt” is denied.
2024-11-17 15:27:48 +01 - [Warning-Duplicati.Library.Main.Operation.RestoreHandler-MetadataWriteFailed]: Failed to apply metadata to file: “/syndocs/blabla.txt”, message: Read-only file system IOException: Read-only file system
Errors 1
2024-11-17 15:27:48 +01 - [Error-Duplicati.Library.Main.Operation.RestoreHandler-RestoreFileFailed]: Failed to restore file: “/syndocs/blabla.txt”. Error message was: Failed to restore file: “/syndocs/blabla.txt”. File hash is JX7H9rpdUJ1btprRDDot9quPPqmwkUQL1PbaN2SKRnE=, expected hash is c2PL2zXYpKZGfGNLn1LWaK5axvmiANcTB9vuRuzC2wo= Exception: Failed to restore file: “/syndocs/blabla.txt”. File hash is JX7H9rpdUJ1btprRDDot9quPPqmwkUQL1PbaN2SKRnE=, expected hash is c2PL2zXYpKZGfGNLn1LWaK5axvmiANcTB9vuRuzC2wo=
So it seems there is a problem with access rights, but how do I solve them?
PS It doesn’t matter if I chose to overwrite the file or restore write/read-permissions.
It definitely sounds like a permission issue. So now we just need to understand all the variables that could impact it.
I assume you’re running this in docker if on DSM 7.x since the Duplicati Synology package doesn’t work on 7.x. Although if you did manage to do that somehow, that might be your issue.
If Docker, then which image did you use?
If you open a terminal to the container, and run “ps -ef | grep Duplicati” which user is running the processes?
Ok, this may be slow going as I’m no expert with Docker myself (DSM’s Container Manager is a wrapper for Docker containers).
In Container Manager, when you click on “Containers” (along the left hand side) you’ll see a row on the right that represents your Duplicati container. What does it say in the “Image” column? (It’s probably either “duplicati/duplicati” or “linuxserver/duplicati”). I’m guessing it’s “linuxserver/duplicati”. Please verify.
Right click on the row for your Duplicati container and select “Details”. You probably have “PUID” and “PGID” entries in that list (note that I do not).
This PUID is the DSM user that Duplicati will be running as. The GUID is that users primary DSM group (I think). When Duplicati runs inside Container Manager, it is accessing the storage that you exposed to that container as that PUID user. If PUID user doesn’t have the right permissions for that file or directory then Duplicati doesn’t either. In your case it is “/syndocs/blabla.txt” inside the container. You probably already know this since you configured it, but to find the location in DSM (outside of the container) that “/synodocs” (inside the container) represents, look in the “Volumes” section of the same screen I referenced above. You’ll see something in the form of “xxxxxx:/synodocs:rw”. Does the user PUID have permissions to access “xxxxxx”? If not, that is your problem.
There are multiple ways of fixing this but let’s see the answers to my questions and make sure things look they way I’m guessing.
Hey Lerrissirrel,
thank you so much! It worked! In Container Manager I checked which DSM-locations were added to the package and which users had permissions. I noticed that somehow the /syndocs location was RO and not RW and switched it - now backup works flawless.
