An observation first: Every time you block inheritance you're cutting yourself off from future flexibility. I avoid blocking inheritance at all costs.
If you need users to be able to list the contents of the top-level "E:\Home Directories" folder, for example, consider the following permission:
- SYSTEM - Full Control - Applied to this folder, sub-folders, and files
- BUILTIN\Administrators - Full Control - Applied to this folder, sub-folders, and files
- BUILTIN\Authenticated Users - Read and Execute - Applied to this folder only
The last permission doesn't inherit down into the subfolders. At each subfolder, inheritance remains enabled and you simply specify the user with "Modify" or "Full Control" rights (depending on how you feel about users being able to set permissions inside their home directory). (Typically I set that last permission by adding "Authenticated Users" in the non-"Advanced" Security properties sheet, unchecking the "Read" and "Read and Execute" check boxes. I then proceed into the "Advanced" dialog and change the "Apply onto" setting for that ACE to "This folder only". That's about the easiest way, in terms of number of clicks, to set it.)
Then, your script becomes:
set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
I strongly suspect that the addition of the "Authenticated Users" permission I've described above w/ the inheritance set to "This folder only" will give you what you're looking for in functionality and will give you future flexibility if you find out that you have to set a permission that might need to inherit into all the user home directories in the future.
This is my SOP for user home directories, redirected "My Documents", "Desktop", etc folders, and for roaming user profile directories. It works great.
Edit
re: your comment about BUILTIN\Administrators access
I've had various arguments with people about my take on granting BUILTIN\Administrators access over the years, and my take is this:
It's easier to solve a certain class of user problems if you can get to their files. It's a pain to "take ownership" and can be quite slow if there are a large number of files present, too.
As you've seen with ICACLS, BUILTIN\Administrators can "assign" ownership (besides "taking" it) so there's no "security" added by not having the files accessible to BUILTIN\Administrators in the first place.
Unless you're using auditing (and sifting through a potentially huge number of false-positive entries) there won't be an audit trail when a BUILTIN\Administrators user takes ownership of files they shouldn't be accessing, copies them, and then returns the files back to their "proper" owner and permission.
In the Microsoft world, Encrypting filesystem (EFS) is meant to solve the problem of keeping unauthorized BUILTIN\Administrators access from happening. NTFS ACLs don't solve that problem. (Obviously, EFS isn't the only show in town. Encryption is the real answer to solving the "limit the network Administrator's access" problem no matter how you slice it.)
To my mind, not specifying BUILTIN\Administrators with access to user home directories (and, in fact, any folder) means that you're increasing the complexity and time needed to resolve issues while providing less than no real security ("less than none" because it imparts a false sense of security where there is none).
I've given up trying to win the argument with people by way of logic. It seems to be an emotional issue with some people. It's like the silly "Deny / Receive As" ACE that gets placed at the root of an Exchange organization to prevent certain privileged groups from opening users mailboxes. It offers no real security (since w/o auditing one could remove / re-apply the ACE as necessary), a false sense of security, and gets in the way when solving real problems.
Even if you don't like my argument about BUILTIN\Administrators having access you want to keep the inheritance hierarchy intact by using "This folder only" inheritance where appropriate. Blocking inheritance in permission hierarchies is a sure sign that something about the design is "broken" (inverted, etc).
The easiest way, if you can have downtime, is to just do a copy instead of a move like you did. You might have to restore from backup and give it another go.
If you can't do that, you can use get-acl and set-acl in PowerShell to recursively apply permissions to a folder structure.
Best Answer
Want to reset NTFS permissions from the command line? Use this syntax:
This is the same as using the GUI command:
Warning: If you leave out the
\*
then the jshipp folder will have the same permissions as the users folder, which is not what the GUI does, and probably not what you want, but it's nice to know it's possible.Disclaimer: This is a copy-paste answer from http://www.jshipp.com/articles/icacls/icacls.php I thought it was too helpful to not be an answer on Server Fault.