I've searched around for this, and all I can find is the usual "i'm an admin but need to elevate" kind of questions. This isn't quite the same.

I have a D drive on a file server (2008 r2 and same problem setting it up on 2012 too) with a folder which is shared out to users. Everyone has access to the entire shared drive over the network, apart from a few folders which only specific groups can access.

I set this up so that those specific sub folders stop inheriting permissions and just give full access to the groups in question (nothing to do with admins). I have a domain user which is a member of the backup operators group and all the local backup operators groups on every machine in the domain (set via GPO). This user is used to run a file sync program in order to sync the fileshare to a NAS every night for backup. This software also runs on the machine in question and not remotely.

I gave the user the ability to logon interactively so I can setup the software under that account and test that the backup works before I create a scheduled task for it.

The problem initially was that the software failed to access the more protected folders - which as far as I was aware wasn't possible with backup operators. So instead I added the backup operators group explicitly to those folder permissions with full access - the same error. So using explorer I went to find the folders in question - and note I'm not running as an admin, however despite this windows asked me to elevate.

Now this is the question - why on earth does a non admin account require an admin token to access a folder it has full permissions to (via it's group backup operators)? This is not in a system folder, or system drive, it's just a normal drive, under a bunch of normal folders with some slightly tighter restrictions on them.

I really don't get why UAC is even needed in this instance - it's got nothing to do with administrators!



Permissions on folders as requested by the comment:

C:\Windows\system32>icacls "d:\share\support\tech documents"
d:\share\support\tech documents
QUT\access tech docs:(OI)(CI)(F)
QUT\Domain Admins:(OI)(CI)(F)
BUILTIN\Backup Operators:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Windows\system32>icacls "d:\share\support"
d:\share\support BUILTIN\Administrators:(F)
BUILTIN\Backup Operators:(I)(OI)(CI)(F)
QUT\Enterprise Admins:(I)(OI)(CI)(F)
QUT\Domain Admins:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

The folder above the one in question is simply inheriting permissions, the tech documents one has inheritance disabled and explicit permissions set.

  • More information about the permissions on the folder is required. Lets start with what groups( Users, Administrator, ... ) have access to this folder. Check the permissions of the parent folders also.
    – Ramhound
    Jun 20, 2013 at 19:03
  • I've just updated the original question with the permissions.
    – icehot
    Jun 20, 2013 at 19:26

1 Answer 1


Some quick experimentation has confirmed my initial suspicion that Backup Operators is treated in the same way as Administrators, i.e., a user in the Backup Operators group is considered an administrator and given a split token. This means you need to elevate to take advantage of being a member of the Backup Operators group, in exactly the same way you need to elevate to take advantage of being a member of the Administrators group.

This makes sense, because malicious code running with backup operator privilege can easily leverage that privilege to give itself unlimited access.

Addendum: if I remember correctly, when this answer was first written Windows did not cope well with this scenario. This has since been fixed. If you attempt to elevate, e.g., using "run as administrator", you will be prompted for an administrative username and password. However, you can now provide your own username and password rather than an administrative one. The new process won't have administrator privilege, of course, but it will have whatever privileges and group memberships your account has been given, even if they would normally be filtered out.

The MSDN article "Teach Your Apps To Play Nicely With Windows Vista User Account Control" includes a list of all the groups and privileges that will cause a split token to be created.


  • Built-In Administrators
  • Power Users
  • Account Operators
  • Server Operators
  • Printer Operators
  • Backup Operators
  • RAS Servers Group
  • Windows NT 4.0 App Compat Group
  • Network Configuration Operators
  • Domain Administrators
  • Domain Controllers
  • Certificate Publishers
  • Schema Administrators
  • Enterprise Administrators
  • Group Policy Administrators


  • SeCreateTokenPriv­i­lege
  • SeTcbPrivilege
  • Se­Take­Owner­ship­Priv­ilege
  • Se­Back­up­Priv­i­lege
  • Se­Re­store­Privilege
  • Se­De­bug­Priv­ilege
  • Se­Im­personatePrivilege
  • SeRelabelPrivilege

Note: that list was written for Windows Vista. I do not know whether there have been any changes in later versions of Windows.

  • 1
    Thanks, that makes sense, it makes testing more tricky though, as there is no "runas backup operator" ;)
    – icehot
    Jun 21, 2013 at 6:38
  • If you don't actually need backup/restore privilege, I suggest you create a new group ("My Backup Operators") and give that group access to the folder(s) in question. If you do need backup/restore privilege, perhaps just make the relevant accounts administrators? Jun 24, 2013 at 22:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.