Evan, Don't get rid of inheritance as such, because it's your friend.
Instead, work your way down from the top, and set the permissions on individual directories. We made a very deliberate decision to limit applications of permissions to no deeper than the 2nd subdirectory underneath the spot where the share lives. On the k$ drive on my file server, I have a directory called Groups that's shared to the world. Each department's directory in that shared directory is set up in the style of the dummy directory above. That first line is the secret sauce here - the permissions for Domain Users are limited to the top level (they can see the subdirectories and files, but can't navigate into the directories and the files at the root are R-O), and then subdirectories are given the explicit permissions needed. I use fileacl.exe to work through these situations, and this is the template I use to start with: FILEACL k:\ /S "BUILTIN\Administrators":F /S "NT AUTHORITY\SYSTEM":F /REPLACE /PROTECT FILEACL "k:\Groups" /S "EXAMPLE\Domain Users":RX/U/U FILEACL "k:\Groups\Dummy" /S "BUILTIN\Administrators":RWXD/U/U /S "CREATOR OWNER":U/RWXD/RWXD /S "EXAMPLE\Domain Users":RX/U/U /S "EXAMPLE\US-HomeGroupsDummyManagers":RAWaWeXDc/U FILEACL "k:\Groups\Dummy\Private" /S "EXAMPLE\US-HomeGroupsDummyUsers":RWXD /S "EXAMPLE\US-HomeGroupsDummyManagers":RWXD FILEACL "k:\Groups\Dummy\Public" /S "EXAMPLE\US-HomeGroupsDummyUsers":RWXD /S "EXAMPLE\US-HomeGroupsDummyManagers":RWXD /S "EXAMPLE\Domain Users":RX Fileacl.exe is a really good tool, well suited for this task. Modify the above to experiment with a test directory, then examine the permissions through the Properties dialog, and you'll see what's happening really quickly. BTW - This is the text of the Readme.txt file at the root of each department's directory, suitably modified, of course: ---------- Directions for using this directory: 1) Only new directories can be created at the top level of this directory - not new files - and those can only be created by members of US-GroupsDummyManagers or by IT. 2) If a new top-level directory is created, initial permissions on it will only be for US-GroupsDummyManagers - any further permissions will need to be added by IT. 3) Permissions will only be placed on top-level directories within the departmental directory. If permissions need to be modified further down the directory tree, the subdirectory in question should be moved to another top-level folder inside of you're deparment's directory. If you have any questions or concerns about how this works, please submit a helpdesk ticket. ------------ Kurt On Wed, Jun 22, 2011 at 15:02, Evan Brastow <[email protected]> wrote: > Amazingly simply question, but I've not done this in so long that I can't > remember. > > > > I have a folder on my file server (Windows 2008 R2) called Secure. > > > > Within that folder there are around 50 subfolders. Most users have no access > to these folder, but some do need access to a few. So I had set up SYSTEM > and Domain Admin full control on the Secure top level folder. Then I tried > to change the subfolders where some users needed permissions, but it told me > the folder permissions couldn't be changed because they were inheriting from > their parent. Do I need to get rid of inheritable permissions so that I can > have a few folders that have different permission levels than their parent? > > > > If I get rid of inherited permissions, and have to go set all 50 folders > manually, which would be a pain, what do I need to set them to? > > > > Essentially, I need User A to click on the Secure folder and see nothing in > it (or the folder list could be shown, I don't care) but I need User B to > click on the Secure folder and see (and be able to read/write to) the > folders he needs to access and change. > > > > Help!!?? > > > > I know I had this set up before, but when I moved to a new server, I lost > those permissions. > > > > Thanks, > > > > Evan > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
