2010-08-19 10:10 AM
Hello.. We use a netapp 3170 for filesharing using CIFS. We have migrated data to a new CIFS volume using robocopy through a windows 2008 server in order to retain permissions from the source system.
We have a strange problem where a folder contains NTFS permissions that need to be removed at that folder level.. However when trying to remove this permission, we get the error:
"You can't remove (Useraccount) because this object is inheriting permissions from its parent"
When we navigate to the parent folder, there are no permissions applied there. Is there a way to edit or change permissions so that this folder is the root, and we can add/edit permissions like we do normally through windows 2003. I suspect it got these permissions from ownership of file copied or something as the result of the robocopy used to bring the original permissions over to the netapp, The strange thing is the permissions shown on the netapp folder, do not even exist on the source we copied from.
It looks like this:
\\netapp\l$\30550 Library Shared (NTFS permissions - Administrators, Libary-SST, Library-CAT, Library-ORG, SYSTEM)
When we try to remove Library-CAT permissions via the windows Security Tab.. We get the error " You can't remove (Library-CAT) because this object is inheriting permissions from its parent. However as you can see the parent of this folder does not contain those permissions.
Is there a way to re-do the permissions on this folder, that fixes this "Ghost" inheritance the file system is seeing? Currently no changes can be made to any of these permissions due to the inheritance assumption?
What we did:
Did a /DATSO robocopy from a source, to "30550 Library Shared"
\\oldserver\shared$ (NTFS Permissions - GD-Library-SST, GD-Library-All_Staff, System)
\\ netapp\l$\30550 Library Shared (NTFS permissions - Administrators, GD-Libary-SST, Library-CAT, Library-ORG, SYSTEM)
As you can see netapp folder seems to be getting these permissions from children, because it didn't come over from the source. however explicit permissions from child folders for the Library-CAT and Library-ORG exists in folders well below the root.
I'm not even sure where these permissions sets have come from.. and due to the bug, I can not even re-assign the correct permissions due to the ghost inheritance.
Has anyone else seem similar issues with a migration.
2010-08-19 10:42 AM
You should be able to break the inheritance on the troublesome folder. Properties>Security>Advanced>Change Permissions then uncheck "include inheritable permissions from this object's parent". You should probably then select "Add" to make sure you keep everything you expect, then you should be able to remove the permissions you don't need.
2010-08-19 10:55 AM
This was what we were going to try but it is long process to do across a complicated structure. You risk losing the explict permissions on the subfolders that we tried to carry with robocopy. But we won't know untill we try. I was hoping for a quicker easier change.
Does anyone else know of a silver bullet?
2010-08-19 01:07 PM
To be honest I've never seen this issue with NTFS on Netapp before. Netapp's implementation seems to be very reliable. What do you get if you run the following:
substituting for your own names, of course.
2010-08-20 01:27 AM
Although I can't offer assistance, I would like to add the fact that we also had the same problem as this. In the end I have had to manually go through all of the folders and complete permissions manually again (not great with 650 user homw drives and profile folders I can tell you); but I just could get xcacls or icacls to work without only part doing the job. At one point it even stipped the permissions completely from ALL the folders it was running against :-0
I had also used Robocopy from a 2k8 box to move the shares.
2010-08-20 11:36 AM
Thanks everyone. I think we are resigned to the manual approach to resetting the permissions. Migrations are just a pain at the best of times!
I appreciate the input.