Robocopy failure with Windows Server 2008 Scheduled Task

Question

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.

Solution 1

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

Solution 2

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

Solution 3

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

Solution 4

I was having trouble copying from Server2012 R2 to a Buffalo LinkStation connected to the domain. Many attempts failed but /COPY:DAT worked for me. If you are having permissions issues, then you don't want to include S O U in your COPY option flags.

my working example: robocopy G:\FEB2FRESH\ \\Ls220\FEB2FRESH\ /s /zb /COPY:DAT /move &pause

citing http://social.technet.microsoft.com/wiki/contents/articles/1073.robocopy-and-a-few-examples.aspx

Copy option flags: D=Data; A=Attributes; T=Time Stamps; S=NTFS access control list (ACL); O=Owner information; U=Auditing information

View more solutions

Comments

[MrGigu]

Do you get the same result if you use the runas command to run the robocopy command manually from the other accounts credentials?

[CC.]

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?

[Pacerier]

@CC., The task needs to be run as administrator.

[CC.]

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.]

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.]

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.