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.

So I have a batch script for robocopy. Running this from the command line does exactly what I want.

robocopy "D:\SQL Backup" \\server1\Backup$\daily /mir /s /copyall /log:\\lmcrfs4g\NavBackup$\robocopyLog.txt /np

Then I create a Scheduled Task in Windows Server 2008. If I set up the task to use my Domain Admin account, great. But I'm trying to get it to run as a separate domain account for Scheduled Tasks. If I use that account, folders get created, but files aren't copied. I get the following error:

2011/02/17 15:41:48 ERROR 1307 (0x0000051B) Copying NTFS Security to Destination Directory D:\SQL Backup\folder\ This security ID may not be assigned as the owner of this object.

I've verified my domain\Scheduled Tasks account has Full Control NTFS permissions on both the source and destination, and the Full Control Sharing on my hidden \server1\backup$ share. Just for giggles, I've tried adding the domain account to the local Administrators group on both servers. This works fine, but that seems like a lot of privileges just to copy files. Any ideas on what I'm missing?

EDIT TO ADD:

I've tried using the robocopy \copy:DATSO flag rather than \copyall (I can skip the auditing info), but I still get the same error.

I've also tried using runas \noprofile \user:my Scheduled Tasks user for the robocopy command. I get the same error again.

I'm not averse to simply adding the user to a Built-In group, though Administrators seems like it would be overkill. I'd be interested to know how others handle their Scheduled Tasks.

share|improve this question
    
Do you get the same result if you use the runas command to run the robocopy command manually from the other accounts credentials? –  Mark Henderson Feb 17 '11 at 22:22
    
I get a slightly different error. ERROR : You do not have the Manage Auditing user right. ***** You need this to copy auditing information (/COPY:U or /COPYALL). So I can poke around in Local Security Policy to find that. Or maybe the Backup Operators group would be OK? –  CC. Feb 22 '11 at 17:50

3 Answers 3

up vote 2 down vote accepted

The account used to perform the copy must have the "Restore files and directories" user right to change the owner to anything other than itself or Administrators.

http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx

share|improve this answer
    
There it is, right there in Local Security Policy. After going through the privileges for Backup Operators, it seems the sanest method for us is to add the Scheduled Task user to server1's Backup Operators group, then Deny Log On Locally to Scheduled Tasks so there's no interactive logons. Thanks for the help! –  CC. Feb 22 '11 at 20:27

I've run into this also. I tend to use /COPY:DATSO instead of /copyall, which copies everything but the "auditing info".

share|improve this answer
    
I tried that, but then I still get an error 'ERROR 1307 (0x0000051B) Copying NTFS Security to Destination Directory D:\SQL Weekly Backups\master\ This security ID may not be assigned as the owner of this object.' –  CC. Feb 22 '11 at 17:48
    
Follow-up: I have changed from /copyall to /copy:DATSO in my script. To copy the auditing info, the Scheduled Task user would need to be in the local Administrators group. We don't need that info for the backup so this was also quite helpful. –  CC. Feb 22 '11 at 20:29

I had a similar problem - changed to /COPY:DATS and no more error Copy was from Server 2003 to a Hitachi HDI.

share|improve this answer

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.