Windows 11 Service Permissions

Support
#1

I’m trying to backup my Windows system. I have duplicacy running as a service. It defaulted to running as Local System account. With -vss set as an option, I still was getting the following:

WARN LIST_FAILURE Failed to list subdirectory My Documents/: open \?\C:\ProgramData.duplicacy-web\repositories\localhost\0.duplicacy\shadow\Users<user>\My Documents: Access is denied.

I tried to use my own account instead, but I’m logging in using my Microsoft account with a PIN. What is the right approach to running this service so it has admin rights to access things across the system?

Thanks

#2

Local system account does not have access to user data. You may want to change the service to run under Administrator account instead:

#3

Do you mean the built-in Administrator account or another account of admin type. I currently login to windows with my Microsoft account and have setup a pin. It doesn’t seem to accept my PIN or Microsoft account password, so I’m unsure what to provide there.
Maybe the simplest thing is to switch to a local account instead.

#4

Built-in administrator, per that article, is disabled after setup. I guess you could re-enable it, or try running it with local administrator account. (Ideally, I would create another system account to use with duplicacy and explicitly grant it access to all user data – but that’s what built-in admin account should already be configured to accomplish, without requiring you to mess with ACLs all over the system).

You can also try to look up which account does Windows built-in backup (File History) service is using, and use the same one for duplicacy – obviously, it will have the correct access privileges.

It would not accept your credentials – it’s a different account.

(Sorry, I’m out my depth at this point – haven’t used windows in 10+ years…)

#5

Yeah, I was kinda wanting to avoid enabling the administrator account as it seems like a great way to compromise your system. I’ll play around with setting up a local admin account.

#6

There is no difference from security standpoint between built-in admin account and another one, except that “Administrator” is the default name.

The widespread recommendation to disable it a and use a different one is for users to be forced to set a strong password on that new admin account, compliant with the security policies that may be enforced on the machines. The default administrator account does not have to comply with any policy – because it’s created early in the install process where policies are not yet applied – or have a password in the first place.

If you set a strong password it wont’ matter. But creating another account that is member of the same groups is also not a big deal.

#7

I thought users of type admin would get the prompt for elevated privileges whereas the administrator doesn’t. I could be wrong. Although requiring the elevated user prompt (or UAC or whatever it’s called) in the service might not be ideal. I need to do a bit of research I think.

#8

There would be no prompts, except when configuring another account in the system preferences. The system scheduler will just launch the process in the security of the selected user, there is no need for UAC, system scheduler has absolute control.

If you want best security – create another limited account for duplicacy, and grant it readonly access to all data you want duplicacy to have access to, and ensure the set of credentials to access the storage wont’ allow data deletion or mutation, only read and add. This is, however, an overkill.

personally,

I would not worry too much about this. Windows security measures are designed to protect clueless users against themselves. Security is always a balance between risk and convenience. An approach I always took is to have a reliable immutable backup of my data and not worry about anything else. UAC would get disabled first thing following the system install; defender, threat intelligence, and firewall (on the private networks only) next. This has worked for me for decades, without wasting compute resource on re-scanning files and my time fighting the UAC. I use the same approach on the non-windows systems I’m using today – prioritize convenience, and fix things when and if anything breaks (i.e. restore from backup). I cannot afford to waste resources on paranoia, to put it bluntly.

Of course, there’s an exception if you have sensitive data on your machine, and disclosing it would have significant detriments. However, in this case, you wouldn’t be using Windows in the first place, so the point is moot.

#9

This might be a moot issue. The three directories it’s complaining about are:
My Documents
Start Menu
Templates

My Documents seems to be different than Documents. All three of these are not visible in explorer or when doing a dir in CMD. They are special folders from what I can see.
If I go into powershell and do an ls -h I can see My Documents show up. But if I try to ls '.\My Documents\' I get permission denied. I think I can just safely exclude these special files and keep using Local System account for the service.

1 Like
#10

It absolutely does:

image

Practically most folders on a Windows OS have full perms for the SYSTEM account, hence why most services use said account.

On my personal PC I run Duplicacy on manual startup (no service mode and installed for just my user account), so I have to modify the shortcut to Run as admin.

On my brother’s PC he runs Duplicacy as a service (installed for all users) and it’s backing up C:\Users\<username>, but I modified the service account to a custom account .\Duplicacy*. HOWEVER, I didn’t change permissions on any files (and nor is it a good idea to either, since you don’t want to reset inheritance on a user’s profile). Since .\Duplicacy is part of the Administrator(s) group (note the ‘s’), it backs up the user account just fine. (Although I believe there’s a situation - perhaps on Windows Home - where you can create user accounts and lock it down, removing Administrators, but I don’t think that’s a default configuration; regardless, I use Pro.)

On one of our client’s workstations, we installed it as a service for all users with the default SYSTEM account. Here, it’s backing up the whole of C:\Users successfully without fiddling with permissions.

These are junction points - they point to other areas that already exist in the user’s profile. There’a about 12 of them, and they’re there mainly to support backwards compatibility with Windows 7 style locations. Don’t delete them, you can safely ignore the warnings, or exclude them from being backed up.

Problem solved? :wink:

* Edit: The reason for having a custom account is solely so it can access a network share on a Windows Server - with corresponding account name and password. Unfortunately, the new Samba backend isn’t very reliable for me, so I’m using old style UNC paths… reminds me, I need to file a bug report for that. :slight_smile:

1 Like
#11

You are right. This is what I remembered too, and reading again the document I linked above i do see

By default, the SYSTEM account is granted Full Control permissions to all files on an NTFS volume.

I’m not sure what did I misread there. My bad!

#12

Problem solved? :wink:

Yeah, I stuck with Local System account and excluded those junction points. All seems good now.