Network and Storage Protocols

issue with copying NTFS ACL's from a vol copied volume


Hi all,

I came across some really strange behavior.  I ran a vol copy between 2 filers, and now I am unable to copy NTFS permissions between said filers using robocopy.  This happens for every file. 

robocopy \\3070b\share1$ \\3020b\share1$ /COPYALL (date attr time, security (ntfs acl), owner info, audit)  /MIR /ZB /R:2 /W:5 /NS /NP /LOG:C:\robo1.log  ends up in a

2011/01/07 10:47:34 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory \\3070b\share1$

A required privilege is not held by the client.

If I change /COPYALL to /DATS I get an access denied error.

  New Dir   \\3070b\share1$

2011/01/07 10:52:16 ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory \\3070b\share1$

Access is denied.

and, if I only do /DAT (date attribute time) it copies fine, so there's no issue with actual write permissions.

Also, if I remove all of the content that vol copy created, and run a robocopy with /COPYALL... it also copies fine, with NTFS ACL's.  So something with the way the netapp vol copy is different than when I just use robocopy to replicate the data.

Has anyone ever experienced this?  The issue with just using robocopy to do everything is it introduces a middle man, taking the time to do the initial copy and increasing it severely. 

Any ideas as to what might be happening?  I thought the vol copy wouldn't have any affect on permissions/ownership as it was just copying blocks (regardless of what is actually in them).






Anyone have any thoughts?  I've been gone for a couple weeks.  It seems very strange to me that using robocopy works if there is no data in the target, and using vol copy is causing some sort of permission issues. 


Not sure what is causing that issue, but you should get in touch with netapp global support. maybe a vol copy bug or ntfs security settings bug.


just closing this off.  I blame the looming days before my vacation on my foggy actions...

It ended up being permissions issues.  I found that I needed to add some accounts to the administrators group on the filer to allow for the proper copying of ntfs acl's.  *sigh* stupid permissions.  But, on a good note, luckily it wasn't a vol copy bug


Hi , coudly you deatil what you have done to solve the problem?

I meet with the similar problem. I can't copy a single file.

The version I use was XP10, and server version is windows 2003.

I just can't copy one file with robocopy src dst /copyall /mir.

When copying the first file, the access is denied error is shown, but strangely , the parent folder is created and with the same permission as source.