This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(102.4, 45%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET%3C/text%3E%3C/svg%3E)
Hello, I created a SQL 2016 Agent job which copies & replaces .bak files from Source Files Location to a Network Disk Share Target Files Location that are 1 day old as follows:
robocopy G:\Source_Files_Location \Network_Disk_Share\Target_Files_Location\ /mov /MAXAGE:1 /COPY:datso
This SQL Agent job looks like does complete copy & replace the .bak files that are 1 day old but overall SQL Agent job shows yellow Warning and within that step it mentions:
"This security ID may not be assigned as the owner of this object."
I ensured the SQL Agent service domain account its running as has full permissions to both Source and Target locations...(but seems like unable to make the Target Files Folder Location the Owner if that's the case)
I've researched around many sites and tried using PowerShell command instead but can't seem to get this SQL Agent job to go perfectly smooth so outcome shows overall green Success.
Am willing to try any other commands like PowerShell again brainstorming using to start with 'net use' perhaps or something else...can anyone provide me script that can do this please?
Thanks in advance.
The message "This security ID may not be assigned as the owner of this object" comes from RoboCopy, not from SQL Server.
The issue is likely related to permissions. You might want to refer to this thread. Although the permissions involved are probably different, you could try giving the domain user more permissions.
I look forward to the results of your attempt.
Thanks MikeyQiaoMSFT-0444 for your suggested reply, much appreciated.
I did try adding the SQL Agent domain service account as an Administrator in that particular [Take ownership of files or other objects] Security Setting within "Local Group Policy Editor" as your screenshot shows and also re-created both Source and Target folder locations as SQL Agent domain service account ensuring it now is the owner on both locations but still same error message.
Still scratching my head
So what happens if you manually attempt to make the service account the owner of the file?
What happens if you run the ROBOCOPY command manually?
You say in the command that you want to copy owner info. That owner would be the service account of SQL Server. Is that also a domain account?
This command would copy only data, attributes, and timestamps, skipping the security and owner information which might be causing the error.
robocopy G：\Source_Files_Location \Network_Disk_Share\Target_Files_Location\ /mov /MAXAGE：1 /COPY：dat
Thanks MikeyQiaoMSFT-0444, appreciate your provided reply.
I did try your robocopy script (removed the /mov option since I don't want to delete their original source files as am aiming to Copy instead) and it does work but strangley gives me a red error with that SQL Agent job step as "Executed as user: DOMAIN\DomainUser. The step failed." with no other information why it failed.
Is there any type of script PowerShell, Dos cmd, etc... that can copy the files and also check if there's the particular error "This security ID may not be assigned as the owner of this object." to by-pass/ignore so that the final outcome of the SQL Agent job will show full green Succeeded?
It would save much time to know that the copy did succeeded but to avoid that particular error message instead of having to dig further that the SQL Agent job final outcome show yellow warning which is kind of a false positive.
Regards.
but strangley gives me a red error with that SQL Agent job step as "Executed as user: DOMAIN\DomainUser. The step failed." with no other information why it failed.
On the Advanced page of the job step, you define an output file. Do that, to find out what is going wrong.
Thanks Erland, much appreciated also.
I did just try creating an output .txt file and re-ran the job and it does list the correct number of Files Copied and zero Failed...but still no explanation of error message why it failed.
But still strange why within that SQL Agent job step it shows the red X Failed...which then causes the overall outcome of that job to yellow Warning instead of full green Succeeded...could it be a bug within SQL Agent or something?
Regards.
That would be because ROBOCOPY returns a non-zero value so that %ERRORVALUE% is not zero.
I ran some quick tests with ROBOCOPY and the return value was 3 in both cases, even if the command completed successfully.
You would have to ask a question with a Windows tag to find out why ROBOCOPY behaves this way, and what you can do about it. I quickly browsed the options for ROBOCOPY, but I could not see anything. But it was a very quick scan. Maybe I missed something.
Try the following code: It will replace the return value of 3 with 0. As Erland mentioned, 3 means a successful copy with no errors, but the SQL Agent may confuse its actual execution results.
robocopy G:\Source_Files_Location \Network_Disk_Share\Target_Files_Location /COPY:DAT /MAXAGE:1
SET /A RC=%ERRORLEVEL%
IF %RC% LEQ 3 SET RC=0
EXIT /B %RC%
I got myself together and found: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy. Scroll down to see the return codes.
My conclusion of that table and the note below is is that LEQ 3 in Mikey's post above would better be LEQ 7. But I would recommend Techresearch7777777 to make your valuation of which return codes you think are good and which are not.
Thanks Mikey and Erland, really appreciate your efforts.
This LEQ related script sounds like it would make sense....though I tried every value from 0 to 8 and still got in each same "This security ID may not be assigned as the owner of this object."
Seems so strange in just trying to to do simple copy and replace some files from one location to another via cmd or PowerShell and getting this error/warning...would've thought this should be pretty basic to complete clean/smooth with no errors/warnings...wonder what my situation is missing and/or different than the normal?
Thanks again...still scratching my head.
This LEQ related script sounds like it would make sense....though I tried every value from 0 to 8 and still got in each same "This security ID may not be assigned as the owner of this object."
The check with LEQ only serves to modify the return code from ROBOCOPY so that SQL Agent does not think the operation has failed when it has not.
As for the error message about the security ID, do you still have /COPY:DATSO in your command? That is, you are trying to copy the owner of the file? But of that owner is a local machine account, it is not going work on the remote file share. As Mikey suggested earlier, stay with /COPY:DAT to avoid that problem.
Thanks Erland, I am using the DAT only and it still gives me that error "This security ID may not be assigned as the owner of this object." message.
Wonder if this could be some bug somewhere?
Can you configure the job step to run with an output file (it's on the "Advanced" page), and then upload the log file, so we can be sure what we are talking about?