I started to get an error on one of my backup jobs (it is local, the b:\ drive is in the same Windows 10 PC and the remote equivalent is running fine) - it worked until last week.
The error is: Access to the path ‘\?\B:\backup-photos\duplicati-20221127T160000Z.dlist.zip’ is denied
The file is there, same permissions as other files in this and the other backup folder. How can I resume the backup (I don’t care about the old versions, mostly only last 2 or 3 instances)
11/27/2022 08:17 AM 27,250,515 duplicati-20221127T160000Z.dlist.zip 03/01/2023 09:54 AM 27,353,130 duplicati-20230227T210010Z.dlist.zip 04/08/2023 08:17 AM 27,382,625 duplicati-20230408T160000Z.dlist.zip 05/12/2023 08:15 AM 27,577,303 duplicati-20230512T160000Z.dlist.zip 06/12/2023 08:16 AM 27,610,140 duplicati-20230612T160000Z.dlist.zip 08/18/2023 08:16 AM 27,602,293 duplicati-20230818T160000Z.dlist.zip 10/04/2023 08:16 AM 27,602,749 duplicati-20231004T160000Z.dlist.zip 11/01/2023 01:06 PM 27,850,187 duplicati-20231101T194026Z.dlist.zip 11/10/2023 08:16 AM 27,850,225 duplicati-20231110T160000Z.dlist.zip 11/13/2023 08:16 AM 27,850,514 duplicati-20231113T160000Z.dlist.zip 11/15/2023 08:18 AM 27,849,958 duplicati-20231115T160000Z.dlist.zip 11/16/2023 08:17 AM 27,849,960 duplicati-20231116T160000Z.dlist.zip 12/08/2023 06:10 PM 27,851,620 duplicati-20231209T015214Z.dlist.zip
this is begging the question, what could be the problem with this file ? Is the B: drive a special kind of drive or a vanilla local one such as SATA, NVME…? If the former, could its driver have been updated, if the latter, could it be in some hardware failure state ? In both cases, anything done at the Duplicati level would not be the best solution.
you are right that it may be possible that only the first file is reported by Duplicati as failing, while the other are not even tested by Duplicati, so it may be a straight user rights change.
I can read the file as the user Duplicati uses with no issues.
The B drive is a local, large (20TB) SATA drive connected directly to the motherboard.
Files and directories for other backup jobs on the same drive are working fine and they have the same permissions set:
Failed PHOTOS job:
Working backup - same drive, B:\DATA
Last successful backup:Today at 12:25 PM (took 00:25:38)Run now
Next scheduled run:Tomorrow at 12:00 PM
Source:390.32 GB
Backup:270.23 GB / 80 Version
In testing, providing Duplicati admin rights (do not follow this, test only!) did fox the PHOTOS error. Still can’t point to why now the error and what changed. But it is definately a permission issue that appeared after 2 years of working.
Was that using the same user, only elevated (possibly needing a UAC prompt) to actually get rights?
Same question here. If you used something like “Run as administrator”, you put admin rights in effect.
Simply logging in as a user defined as an Administrator does not immediately give them added rights.
Alternatively, you can look at processes in Task Manager with header right click, add Elevated column.
Since there’s a verified fix involving permissions, is there a chance we can actually hear permissions?
If it’s difficult to redact something like screenshot of the file’s Security, icacls can make textual outputs.
I’m guessing the backup is working, then failing in the check at end where it actually tries reading files. Verifying backend files explains this. In original post, I noticed what looks like a new dlist file created.
Looking in the Restore tree would probably also show it, but it’s still not good to have file read problem.
Duplicati is not doing any magic. It’s just an application opening files. There are settings to control this.
can you select the first version (not the version 0, the oldest, the one from 11/27/2022) in the restore function ? and the most recent, from 11/17/2023 ?
Could you try to access the error in clicking the access denied error in the live log ? Or even try to use the Duplicati.CommandLine.BackendTool.exe in a command line window (not the UI, a system terminal, cmd.exe from the c:\program files\duplicati 2 directory) and to use the Get function for the failing file, this could provide a back trace that may (or not) be more informative.
Above is reverse-chronological <job> → Show log → Remote where you can see default 1 set (three different types) read and verified. About → Show log → Live → Information would have looked similar when watching as it happens. As the dlist is read first, possibly yours didn’t make it to its other files.
Live log will let you click on failure, and perhaps get more info. Also see About → Show log → Stored.
Reading files is also essential to restore, or compact, or database recreate. You want it to be working.
EDIT 1:
As you can see in the image, typically the dlist file read is the one that was just uploaded by backup.
Exactly which files are chosen is done with a balancing algorithm though, so it’s a little unpredictable…
EDIT 2:
The TEST command run in GUI Commandline in a Duplicati that has trouble at end of backup can test more files (maybe with trouble too, as you say permissions are similar). Testing all will be pretty slow.
EDIT 3:
… meaning a more time-effective plan may be to start with small values and see what issues they see.
Right now I’m not sure if we’re up against one (maybe intermittently) troublesome file, or a wider issue.
There are certainly lots of ways to explore, but also keep in mind the prior note on elevated versus not.
Although I don’t see why it would dislike a dlist file, I suppose you could also disable real-time antivirus.
