Backup error - dlist file permission error out of the blue

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\’ 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
03/01/2023 09:54 AM 27,353,130
04/08/2023 08:17 AM 27,382,625
05/12/2023 08:15 AM 27,577,303
06/12/2023 08:16 AM 27,610,140
08/18/2023 08:16 AM 27,602,293
10/04/2023 08:16 AM 27,602,749
11/01/2023 01:06 PM 27,850,187
11/10/2023 08:16 AM 27,850,225
11/13/2023 08:16 AM 27,850,514
11/15/2023 08:18 AM 27,849,958
11/16/2023 08:17 AM 27,849,960
12/08/2023 06:10 PM 27,851,620

Last successful backup:11/17/2023 (took 00:36:48)

Thank you!


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.

Can you read the file running as whatever user Duplicati uses (About → System info → UserName):

For example, run copy \\?\B:\backup-photos\ NUL

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.

If access permissions somehow do not allow Duplicati to read files, it will interfere at end of backup:

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.


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…


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.


… 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.