2015-11-11 01:24 PM - last edited on 2015-11-11 01:27 PM by alissa
I have a NetApp CIFS volume serving out many shares. The NTFS formatted volume root has a folder in it called ShareRoot e.g. /vol/shareroot/. In NetApp world,as this is a CIFS volume and not a LUN, you share out this root initially then create all your share root folders under this root e.g. to create more folders you access \\netappfiler\admin\ share and create the folders then create the shares with the NetApp mgmt. tools:
Naturally, for granularity we break inheritance on each subfolder under /vol/shareroot/ and add our DACLs as we see fit. For various reasons (3rd part monitoring apps etc.) I need to leave the root admin share open for admins. That means these admins can see the share root folders for all shares. because of this I wanted to add the following to each share root folder to protect it from someone doing anything silly:
I'm setting this by access the share path (e.g. \\mynetappfiler\share1\ and it works fine but when I click apply the explorer UI then seems to spin through every single subfolder and file in that share. It only add the permission to the root folder as required so why does it go through every file when the scoping s 'This Folder Only'? The reasons I ask is I have hundreds of these to do and it's time consuming. I was expecting it to return immediately as I'm only adding an entry that applies to a single folder.
Using icacls.exe yeilds saem result. The permissions get set correctly but it takes so long for such a simple change. I looked a fsecurity but it doesn't appear to have the ability to add a permission rather overwrite the entire thing.
Solved! SEE THE SOLUTION
2015-11-11 08:14 PM
Hi Darraghos -
Short answer - this is the way NTFS file permission semantics work, so NetApp implements the same semantics that Windows would in a native NTFS setup.
Longer answer - I don't claim this to be canon, rather this is based on my experience with NTFS semantics. I will gladly take correction by anyone more knowledgeable in low level NTFS semantics and operation.
You mention that you are adding a security that only applies to the folder in question. But, the "sum" of the ACLs for that folder sounds like they include at least one permission that does apply to sub-folders and files. My experience is that there is no real add or delete of individual ACLs. Rather, when the set of ACLs is changed the entire set is reapplied to the object in question as a whole. Thus since one element of the entire ACL set applies to sub-folders, the entire file tree has to be processed.
It is hugely time consuming I agree, especially where you have so many individual trees to work through. Unfortunately it's just the way it works.
I hope this helps you.
Lead Storage Engineer
Huron Legal | Huron Consulting Group
NCDA, NCIE SAN Clustered, Data Protection
Kudos and accepted solutions are always appreciated.
2015-11-12 01:51 AM
Hmm, after testing using a unicode file with this content supplied to fsecurity:
It seems to add this ACE and leave all others intact. It completes in less than 1 second as opposed to 5 mins when using a windows server and a UNC path to add the permission. I can't find the exact details of how fsecurity deals with existing DACLS thoug
2015-11-12 04:12 AM
I can't find the exact details of how fsecurity deals with existing DACLS thoug
All information I have seen suggests fsecurity completely replaces existing DACL.