Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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. –  HopelessN00b Aug 21 '12 at 22:49
    
@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. –  Oliver Salzburg Aug 21 '12 at 22:54
    
So that's not it, sorry. Deleted. –  HopelessN00b Aug 21 '12 at 23:18
add comment

1 Answer

up vote 5 down vote accepted

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.

share|improve this answer
    
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. –  Oliver Salzburg Aug 21 '12 at 23:11
    
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. –  Ryan Ries Aug 21 '12 at 23:22
    
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. –  Oliver Salzburg Aug 21 '12 at 23:32
2  
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... –  Ryan Ries Aug 21 '12 at 23:36
    
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 :) –  Oliver Salzburg Aug 21 '12 at 23:44
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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