Error backup local one drive folders (server 2019)

Hi erveryone,

I’m using duplicati in my organisation and I have a problem to backup local copy of one drive folder. Here is the log for any files:

  • [Warning-Duplicati.Library.Main.Operation.Backup.FileBlockProcessor.FileEntry-PathProcessingFailed]: Failed to process path: C:\Users*****\OneDrive - **.ods

Is there any way to avoid this kind of warning? (enven with vss required it doesn’t chang anything)

Let me know if need more infos.

King regards

Hello and welcome!

VSS helps with file lock issues, but does the ACL allow the file to be read by the Duplicati process?


How can I know this? (what is the duplicati process “user”?)

EDIT: I change the settings like this and it seems to work:
–snapshot-policy=On (instead of required)
–usn-policy=On (add this line)

Same error: [Warning-Duplicati.Library.Main.Operation.Backup.FileBlockProcessor.FileEntry-PathProcessingFailed]: Failed to process path:

Open Windows Task Manager and click the Details tab. Find the Duplicati* processes and check the Username column.

As long as that user has read access to the files, and you are successfully using the snapshot policy, it should be able to read the files on your disk.

It is the SYSTEM user. It doesn’t have permissions on C\user\usernames folders when I trie to give it permissions it breaks users permissions. How can I give this user read permissions without breaking other users permissions ?

I tried to use local admin as service user but it didn’t work as well :-/

As drwtsn32 suggests this is likely an ACL/Permissions issue.

AFAIK only the “LOCAL SYSTEM” account can traverse into another users folder by default, any other account should require making some form of permission changes. You probably need to have Duplicati running as a Windows service that then runs using the “LOCAL SYSTEM” account. If you didn’t want to run Duplicati as a service then you’ll have to modify some permissions.

Permissions are fickle so best to test these changes in a test environment before rolling out to production server.

Presuming your using the “Administrator” account you would open the permissions for Bob’s folder, “C:\Users\Bob”, right-click Properties, Security Tab, click Advanced, click Add, click Select a principal, type in Administrator, change the “Basic permissions” to Full control. Leaving all other settings as is click OK. Wait while the permissions are applied to the files and folders, can take a long time depending on how many files are in the users folder. At this point the Administrator should be able to browse to that OneDrive file without issue and if run under the Administrator account Duplicati should be able to backup the files.

Hope this helps.


Duplicati already run as a service. That is the point. There is arround 30 users in this server (RDP) so changing by an all right for all servers is quiet long. Is it possible to do it in cmd line like a “chmod admin +r” or something like this?

Ok, so it’s running as a service but is that service using the “LOCAL SYSTEM” account?

FYI: The “LOCAL SYSTEM” is a different account from the “SYSTEM” account.

As for changing permissions via CMD line you’d use icacls. Test, test, test, it’s very easy to completely blow up your ACLs using icacls. icacls | Microsoft Docs

Given this is a Windows server why not run a full Windows Server Backup prior to making any ACL changes, one wrong switch in icacls and things can go very bad.

Yes it is local system account


It’s a VM, I snap it before any modifications.

Hmm, tu me fais travaillé aujourd’uis. (“Hmm, you’re making me work today.” for those of you that don’t speak French)

I’m now wondering if it isn’t an issue parsing the path vs a permission issue because the LOCAL SYSTEM account should have had sufficient access to read the files but there are reasons why it won’t so let’s see where these questions go.

  1. Is the failure always on the same file for the same user? i.e. If you exclude the whole folder for user1, does it then fail on the OneDrive folder for user2?

  2. Is the server a domain controller, a member server in a domain or stand-alone server in a workgroup?

  3. Can you list/anonymize the whole path C:\Users\ what is this path \OneDrive?

  4. Any sort of “folder redirection” in that path?

  5. Can Windows Server Backup backup those files?

  6. Not that it’s often an issue these days but could there be character in the path or filename that Duplicati possibly has an unknown issue with like an é or a really long file/folder/path +256 chars?

  7. So long as your comfortable to snap back, give my first suggestion a go. Confirm that when using the admin account and browsing to that folder you get an Access Denied message. Next, change the permissions on a users folder granting the admin account full control to the user folder as mentioned, next verify that said account can now browse to that file.
    Providing you can then browse to that file you should then be able to change the Duplicati service to run under that admin account and it should be able to backup that folder now. If so and the note below doesn’t scare the boss, repeat for the other users.
    NOTE: Not sure if you have any data policies around who can access what data but following this change that admin account will be able to access everything and anything within the user folder.

  8. You could also look into using the built-in Backup Operators group (you’ll need to specify a user) as anyone in that group should also have full access to backup any of the files in the local server. This would be the “better” way vs giving the admin account full control over user folders but given the LOCAL SYSTEM account didn’t work I don’t think the Backup Operators group will do any better.

Can you look at About → Show log → Live → Warning during a run to see the reason for failure? We’re guessing permissions is the cause, and it would be best to not guess – especially if fixing permissions.

I think that’s because Windows likes to set ACLs so that it gets Full Control, otherwise it can be blocked:

C:\backup source\restricted file here>whoami
nt authority\system

C:\backup source\restricted file here>type restricted.txt
Access is denied.

C:\backup source\restricted file here>

The above file gives access only to me, the ordinary user who set its security, and I removed SYSTEM.

I’m sort of curious why SYSTEM access went missing on the server 2019 system. On my Windows 10 desktop, C:\Users sets a new set of permissions (as opposed to inheriting from C:), and has SYSTEM. Specific users folders also have it (and also don’t inherit). Typically, inheritance is used heavily after the general security setup is set. I think this also makes it very easy to push permissions to folder contents, because there’s nothing to change for the contained files and folders. They just inherit top-level security, however there’s no telling what a user might do in their profile, so there’s still a potential for non-access.

Explorer right-click Properties → Security → Advanced shows what was inherited from, and what there inherits downward. For a test, I avoided Advanced screen and just added a permission. It inherits down.

Windows: Add system access to folder if needed are the CrashPlan 6 directions, and I remember doing this on CrashPlan Home when it still existed. Just add SYSTEM permission. Don’t remove anything else.

I suspect they’re the same, based on this saying S-1-5-18 System (or LocalSystem), Also see this.

Another place to see this is on the About → System info screen in the GUI. Look for the UserName value.


  1. Check your live log Warning details (click on lines if necessary) to see what actual problem was.
  2. Check your folder Security → Advanced permissions at least at C:\Users and C:\Users\<user>.
  3. If adding SYSTEM is acceptable, do so and make sure via Advanced security GUI that it inherits.

1 - it is on each user with an active OneDrive
2 - it is a server in a domain
3 - see 1
5 - Yes
6 - Maybe!
7 - Using the admin account didn’t change anything
8 - I will test this today

8 - I created a “backup” user and add it to admin and backup operators groups, restart the service, it failed exactly the same way.

1 - Live logs (same everywhere):

{"ClassName":"System.IO.IOException","Message":"Cloud file access refused.\r\n","Data":null,"InnerException":null,"HelpURL":null,"StackTraceString":" à System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)\r\n à System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)\r\n à System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)\r\n à Duplicati.Library.Common.IO.SystemIOWindows.FileOpenRead(String path)\r\n à Duplicati.Library.Main.Operation.Backup.FileBlockProcessor.<>c__DisplayClass1_0.<<Run>b__0>d.MoveNext()","RemoteStackTraceString":null,"RemoteStackIndex":0,"ExceptionMethod":"8\nWinIOError\nmscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.IO.__Error\nVoid WinIOError(Int32, System.String)","HResult":-2147024501,"Source":"mscorlib","WatsonBuckets":null}

2 - Here are the permissions on C:\Users\someuser\OneDrive - ORG:

3 - About Info UserName:

I don’t know what is the problem … Local System Account has full acces and I add it to backup operator group to see what happend, still same errors…

It’s a domain controller and DCs deal with security in a much more conservative manner which explains why things aren’t working as expected. If this was a member server everything probably would have just worked but DCs are well DCs and they do not follow the same rules. Many programs just will not function correctly when running on a DC, the security model is just too restrictive. Host the files on a member server and everything should be just fine. Wish I had better news.
Maybe there should be a mention in the Duplicati system requirements that it should NOT be run on a Domain Controller.

The LOCAL SYSTEM account is different from the SYSTEM account. To quote the Microsoft link below , “Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs” Link which may explain why you see it as “the same SID”. The LOCAL SYSTEM account has WAY more rights on the system than the SYSTEM account or even any member of Administators group.

I’m fairly certain it’s been this way since NT 4.0 (possibly NT 3.51 but that’s a bit too long ago for me to recall clearly, yes I’m old AF). Often times the SYSTEM account will have enough rights to do the trick but other times only the LOCAL SYSTEM account will do.

I think most of the confusion stems from people incorrectly talking about “the local, SYSTEM account” not “the LOCAL SYSTEM account” (yeah, that’s not exactly a clear distinction is it, thx MS) and most of the time it probably doesn’t matter but they are different accounts with different rights.

You won’t find the LOCAL SYSTEM in a permissions window, it’s not an assignable permission, it is a base permission (does not show). You can’t login as the LOCAL SYSTEM only a service can do that.

Your permission test needs to be tweaked, try a service that runs a batch file which copies the file out of your “restricted folder” into another folder (restricted or not).

Fun quote from the above link, “If the service opens a command window and runs a batch file, the user could hit CTRL+C to terminate the batch file and gain access to a command window with LocalSystem permissions.” BE CAREFUL but you should be able to try your permission test from there.

Let me know how that goes.

Are you certain that you have a local copy on a local drive? Can you check some files using Explorer?
It’s not a local file if the Status column shows a cloud. A green check mark means file is actually local.
You can also choose some file to right-click → Properties → Details to check Availability status.
On a Windows 10 desktop with Duplicati SYSTEM service, backing up OneDrive Personal, cloud fails.

Save disk space with OneDrive Files On-Demand for Windows 10 gives the icons and some settings.

If I actually make the files local, backup works. On cloud file, I get the same “Cloud file access refused”.
Web search shows a lot on this error. Many backup programs say make file local, so I’ll also suggest it.
You might want to test a folder to see if it helps things. Do a right-click Always keep on this device.

Solution! Can’t backup OneDrive files to external HDD shows the Files on Demand box uncheck, if the interface works the same way in your RDP usage. If not, there’s probably some way to get it turned off.

Does each user have a personal OneDrive area, or is there somehow a shared OneDrive they all get?

Somewhat oddly, if I access the file from a Command Prompt (e.g. by type), I can force it to download.
This changes its Explorer Status. I wonder if Windows Server Backup forced downloads also do this?
There’s also a chance (unless you checked backup contents) that it skips files that aren’t actually local.

It is not a DC. It’s a server in a domain.

Well, I think you get the point. It’s office 365 onedrives. Each users has a personal OneDrive The files are not synced localy.

Well if they don’y use the file, it will not be synced so it’s not that much a problem if it is not backuped. I will see how I can ignore it.

You can try exclude-files-attributes with the Offline attribute. Big discussion and an old fix at the below:

Exclude offline files broken with OneDrive?

The Microsoft documentation says that if you use Storage Sense, it will delete the local copy after awhile.
If this happens, and the exclude works to ignore that file’s existence, it will look to Duplicati like a deletion, and the file won’t appear in the Restore view for backup versions which exclude it, however other backup versions that include it may hold the blocks of its content in the backup, so adding it back is just a list edit.

1 Like