We stumbled across some strange acl problems when we move files at our fileserver (2008R2).
The first time we saw this problem, we thought it is a server problem, because moving files from one fileshare to another fileshare on the same server lead to inconsistent file acls on the moved files. All ACLs were inherited from the root folder, so moving a file from one share to another should inherit the ACLs as well. But that wasn’t the case.
After a bit of research we found some entries and a hotfix from microsoft, that addresses this issue. It can be found via google by searching for MoveSecurityAttributes.
For Windows XP you can set a registry key to solve this problem. To solve it with Windows 7 you have to download a hotfix and apply the registry key to your client to handle the ACLs by moving files corretly.
Everything worked perfect until another inconsistent ACL problem email hit our ticketsystem.
We investigated again and checked everything. Moving files from one share to another on the same server doesn’t occur. But this case doesn’t have anything to do with moving files from one share to another. It occurs when we move a file from inside of a share to another subfolder with different permissions..
Let me explain that.
Example 1 (solved by MoveSecurityAttributes)
File permissions of file1.txt: rol-grp-share2-RW (correct)
Example 2 (not solved by MoveSecurityAttributes)
File permissions of file1.txt after moving: rol-grp-share1-subfolder1-RW (incorrect)
As you can see, moving files across shares does inherit the ACL from above, but moving files inside a share from one folder to another with different ACLs doesn’t inherit the ACL.
This is one of our next call we will report to Microsoft
are you having any response from MS ?
we don’t have any response from MS for this issue.
At the moment we have an open call at premier support for our DFS problem ( http://marco-difeo.de/2014/01/16/dfsn-performance-where-are-you/ ).
If this issue is resolved somehow, we open a call for this ACL issue (maybe within the next 4-6 weeks).
I’m attending TechEd in Barcelona at the moment and I had the chance to talk to Ned Pyle at „ask the experts“.
Because Ned is Senior Program Manager in the Microsoft Windows File Server development group, he was able to say something to this.
He mentioned, that this problem have to be solved from the guys at the shell group, because Explorer at least is responsible for this particular problem. If you could use a tool like robocopy you can specify to not break the inheritance if you move a file from A to B.
Another idea Ned came to while we were talking was solving this problem by running a scheduled task, that corrects the inheritance for all files.
I don’t think we could do this within a reasonable time, because we have 140TB Storage. My idea was to use a watchdog for file changes, or just correct once all files and fun a script every night and correct files edited withing the last 24h.
Another idea Ned came to was to use DAC (http://blogs.technet.com/b/windowsserver/archive/2012/05/22/introduction-to-windows-server-2012-dynamic-access-control.aspx) with some complex rules to get this handled. Maybe we took this into account, if we move from 2008R2 to 2012 Server.
Maybe I have a chance to talk to the shell / explorer guys tomorrow to hear their opinion.
do you got already any official response from MS ?
Yes and no.
I wrote some mails with someone from another company in Germany who has more information on that and already has an open case at Microsoft.
MS confirmed this problem but has actually no solution for this, but is working on it.
Currently, they have round about 20 open cases for this particular problem (the more, the higher is the priority). The main problem for this is (in my opinion), that such a big problem in the shell (core part of windows) can’t be solved as fast as bug in a product like IIS or another installable software. So we have to wait for fix, but knowing they are working on it is much more reassuring, than looking for a way to solve it by yourself, which leads in frustrating googleing and reading this posting :).
We noticed exactly the same issue right now. But your article is quiet old now. Are there some news related to this problem?
Thanks for your update!
we have this issue with Windows 10 as well and didn’t have a fix for this yet.
As we are busy with Windows 10 deployment, we haven’t already opened a case for this problem.
If we get in touch with Microsoft I’ll update this article asap.
Is there any more information available about this problem? Any reply from MS?
nearly one year later: Are there any news on this?
For the „MoveSecurityAttribute“ to work, it seems like the user account moving the file must be allowed to „Change Permissions“ (Full Control). Has anybody managed to find a better solution?