What permissions are required to back up to a remote folder?

windows-server-2008 dfs windows-server-backup

10,803

I commend you for trying to stick to the principle of least privilege. But I think I see I where you got off track. Where you said:

I added "Backup" to the "Backup-Operators" group on a domain controller

The Builtin container in AD holds groups that are in essence like shared local groups for all the domain controllers. Adding a user to the Backup Operators built-in group in AD Users and Computers only gives that user Backup Operator privileges on domain controllers. As such, it will have no effect on non-DC servers in the domain.

Source: http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx

For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers in the domain.

The account you use should be a member of the Backup Operators local group on each server - the one being backup up, and the server hosting the share that will hold the backup. According to the documentation, that alone should allow the Backup user account to access the files necessary to perform the backup, regardless of his file permissions on the files being backed up.

Now being a member of the Backup Operators local group on the computer hosting the file share probably isn't going to give him write permissions to write the backup to the share, so you'll want to give those permissions accordingly. I recommend giving the Backup user full control share permissions, but just read/write permissions at the NTFS level.

10,803

halra

Never forget: :w !sudo tee % Save a file in vim when you neglected to open the file with sudo but already made changes you don't want to lose. Ctrl+X,* Evaluate globbing on your current input on the bash command line. postfix flush Pump out the postfix queue on your backup MX after you've fixed the issue with your primary MX. git tag -l | xargs -n 1 git push --delete origin; git tag | xargs git tag -d Delete all tags from a git repo - remotely and locally. sudo apt-get purge $(for tag in "linux-image" "linux-headers"; do dpkg-query -W -f'${Package}\n' "$tag-[0-9]*.[0-9]*.[0-9]*" | sort -V | awk 'index($0,c){exit} //' c=$(uname -r | cut -d- -f1,2); done) Delete old kernels https://signup.microsoft.com/productkeystart Register new Office 365 product keys for an existing tenant.

Updated on September 18, 2022

Comments

halra almost 2 years
I'm currently working with Windows Server Backup and am trying to run a scheduled backup with an unprivileged account.
- I want to create a full backup of the server exchange.dom.example.com.
- I created a new domain user "Backup", which I want to use for this task.
- I created a DFS storage location called \\dom.example.com\Backup\Exchange where I want to write my backup to.
- It is pointing to an SMB share on the server storage0.dom.example.com named \\storage0.dom.example.com\Exchange
- I gave the user "Backup" full access permissions to the SMB share \\storage0.dom.example.com\Exchange.
Now, this is where the confusion starts. I added "Backup" to the "Backup-Operators" group on a domain controller, but Server Backup would not let me create the backup job. So I created the job with my own user account and tried to change the scheduled task later on. When I then try to switch the user to "Backup", it tells me "Backup" is not allowed to log onto the system.

So, I added "Backup" to the local "Backup-Operators" group. Now I can create the task just fine. But when it runs, it will fail with error code 2155348039, telling me it wasn't able to write to the target location.

When I add "Backup" to the "Administrators" group, everything runs perfect. So I must assume this is a permissions related issue. But what other permissions do I have to set?

I also double-checked the error with Process Monitor. An ACCESS_DENIED error is captured from wbengine.exe while trying to write to the DFS location \\dom.example.com\Backup\Exchange\TempFile.tmp.

I've also tried to simply set the backup up without DFS at all (by writing directly to the SMB share), that leads to the same issue.

I've yet also started a command prompt as "Backup" on exchange.dom.example.com and pushd my way into \\storage0.dom.example.com\Exchange. This is the only place I can not write to. I can write to any subfolder just fine. Just not into the Exchange.
- HopelessN00b almost 12 years
  
  Why isn't it able to write there? Is an admin user, say yourself, able to copy a test file to that location? Sounds like you may have an issue with your DFS permissions not being set up to allow anyone to write to the share.
- halra almost 12 years
  
  @HopelessN00b: Yes, I can write to that location just fine. I can also map a network drive to that location using the credentials of Backup. I checked my DFS settings many times. Maybe I'm missing something. I've set the DFS share to inherit the permissions set on the file system level.
- HopelessN00b almost 12 years
  
  So that's not it, sorry. Deleted.
halra almost 12 years

Alright. Thanks for clearing a few things up for me. I removed Backup from the group on the DC. It was already a member of both local Backup-Operators groups on both parties involved. I double-checked all permissions that can be set on the DFS root, the Backup namespace and the NTFS permissions. I am not able to find what is blocking the write.
Ryan Ries almost 12 years

You mentioned the "DFS root, the Backup namespace and the NTFS permissions," but what about the share permissions on the shared folder? Let's forget about DFS for the time being and just focus on trying to write to a file share.
halra almost 12 years

I did some further tests. Even though the evidence clearly suggests otherwise, I'm certain my NTFS permissions are set to full control on the Exchange folder. But I'm slowly starting to think I left out a crucial detail... The Exchange folder on storage0.dom.example.com is actually a volume that is mapped into that folder. So it's not a normal folder.
Ryan Ries almost 12 years

I... uh... er... don't do that? So go check the permissions of the volume that is being mapped to and modify permissions there accordingly... but I have to say, your setup is getting pretty wonky now...
halra almost 12 years

Oh lord. Now it works. As you said, I had to adjust the permissions on the volume. I'm actually just playing around with DFS for the first time today and this is how Windows Server set everything up after I completed the "Share Storage" wizard (no idea what it's called in English). I don't know what the final setup will look like. Thanks :)