The support forum

NtSetSecurityObject() failed with c000005a

NARBS :

Mar 30, 2017

2017.03.30 12:30:08.163 (UTC-5) 3 4                 Copying security information...
2017.03.30 12:30:08.287 (UTC-5) 0 5                     NtSetSecurityObject() failed with c000005a
2017.03.30 12:30:08.287 (UTC-5) 3 6                         Context: 1
________________________________________
I have gone from start to finish in the forum post, scanning to see if anyone else listed this error.  Without a working search feature; I admit I may have missed if someone else has asked this before - and if so, I apologize for re-starting an new thread.

My current backup is from a virtual server at a different site for the company I work for.  The VM is running on older hardware, so we are copying the data drive to a remote location.

I am in the local Administrators group for all servers and devices in this backup.  I am also by AD account name directly added to the root level of each device with full permissions propagated down through all folders and files.

The initial backup was done with RoboCopy to an attached USB drive; then shipped to the remote location and RoboCopy used to copy from the USB to the storage server.  Both location ran as administrator with the /MIR /CopyAll parameters.

Before finding Bvckup 2; I was using RoboCopy to attempt to keep the backup current to the remote location.  As discussed elsewhere on this site; Bvckup addresses the gotcha's of trying to use RoboCopy for such a task.

However, with RoboCopy there were no errors.  Yet with Bvckup, I have gotten up to and exceeded 20,000 of the NtSetSecurityObject() failed with c000005a errors.  Comparing the source to the destination; it appears there is not a problem.  Files are up to date, matching size, date, content, etc... and all NTFS permissions are correct, even for new files that were not part of the original RoboCopy backup.

So, what is this error and it is something I need to be concerned with?

NARBS :

Mar 30, 2017

Additional, clarifying information:
Bvckup 2 is installed on the VMWare host
Source is the D: drive of the VM running on the host
Destination is a network file share on a large drive of a remote server

I am using full file specification for the source and destination names:
\\server\d$\root_folder and \\server\fileshare\root_folder

I found other forum post concerning network shares; and I am currently going over all that I could find to see if I can identify a similar issue.

Alex Pankratov :

Mar 30, 2017



As per [1] C000005A is STATUS_INVALID_OWNER.

In order to copy the file owner info across a machine boundary an exact-matching user account needs to exist at destination, meaning that the owner account must be of domain type -OR- a local account with the exact same SID must exist at destination.

Not sure why robocopy'ing data with /copyall worked. It should've not. Perhaps something's somewhere changed after that.

[1] https://msdn.microsoft.com/en-us/library/cc704588.aspx

NARBS :

Mar 30, 2017

Seems I forgot to note something else that may be important for getting assistance in troubleshooting...

I have right-clicked and run the program As Administrtor
Inside Bvackup 2, I have used the "key" on the source and destination locations to put in my fully qualified domain\UserName with current password.

I was having the same error before I used the key to specify my username and password.  So, I don't know that putting these in specifically made any difference.

NARBS :

Mar 30, 2017

Alex,
This makes perfect sense then.  As on the source server, the owner is the local administrators group.  That does not and cannot exist on the destination.  As the fully qualified name would be server\administrators and since they are different servers, different FQN.

So, if I understand the settings correctly, I can simply un-tick the option to copy the owner.  Correct?

Alex Pankratov :

Mar 31, 2017

Correct. You generally can't copy Owner / Group / DACL between the machines.

NARBS :

Mar 31, 2017

From my use of Bvckup so far, in relation to the RoboCopy parameter /Copy:DATSOU
Data
Attributes
TimeStamp
NTFS Security (ACL/DACL)
Owner
aUditing

Bvckup works wonderfully well for DATS but not OU

This works in my case, at least, because the security is tied to forest domain groups that can exist anywhere within the domain to give access to any folder on any server.

Just Bvckup does it **SO** much better.  :)

New topic

Create
Made by Pipemetrics in Switzerland
Support


Follow
Twitter
Dev blog
Miscellanea Press resources
Testimonials
On robocopy
Company
Imprint

Legal Terms
Privacy