NTFS permissions - “Inherited from”?

Question

I have a NTFS external hard disk. It was in use primarily with one laptop, but that laptop has since been replaced. With my new laptop, I'm finding all my files are now read-only. The "read-only" checkbox is unchecked, but it seems to be ACLs causing the problem.

On all the files, the only writable permissions on the ACL is SYSTEM, Admistrators, and "S-1-5-21-....", the account number of the account on the old laptop, I'm assuming. Click "advanced" says this permission is "Inherited From" "E:\". However, if I open the ACL list on E:\, I do not see any permissions involving "S-1-5-21..." - why not?

Is there anyway to wholesale update this device to the new user's account, so that I can write to things?

Edit: This is an external drive, and does get shared about machines a bit. Is there a better way to do this?

Edit: The old machine was Windows Vista, the new machine (the one I'm working on) is Windows 7.

Answer 1

Yes there is. If you truly do want to reset all the permissions on this external hard-drive, the way to do it is to change the ACL at the top and then check the "Replace permission entries on all child objects..." checkbox. That will set all files and directories below that point with the ACLs you assigned to the top level. That should clean out the old SID and get things working again.

Why this happened in the first place is pretty simple. NTFS permissions are explicitly set on each object (file and directory). When you set something to inherit, Windows goes through and sets the inheritance on each file and folder below that point, skipping directories set to Block Inheritance. If you have a file-system with 5 million files and folders, this can take quite some time. If you set something on that 5 million file-tree and then cancel part way through only some of the files and folders will have that permission. Those that got set will show that they have an inherited right from above, but you won't see that on the object since that (oddly) gets set last. Cleaning that out requires either doing the procedure I lined out above, forcing permissions down, or setting that one permission on the top object and letting it completely percolate down the tree and then removing it again.

If you have an unnamed SID (like you have) you can also try removing it by setting and then unsetting the right. Assuming Windows 7:

icacls E:\ /grant S-1-5-21-....:(oi)(ci)(m)

Once that's done applying everywhere, remove it.

icacls E:\ /remove S-1-5-21-...

Answer 2

NTFS formatted external drives will act like an internal drive and setup permissions in a way where only users of one machine can access the drive. Administrator accounts can generally see everything on the drive do to some weird quirks of NTFS.

Almost all permissions set on an NTFS hard drive use the Security ID number instead of the display name of the user. The "S-1-5-21..." number is the security ID of the user account that created folders on the NTFS drive. NTFS was designed for use in a domain when user's Security ID's don't change between computers. I'm assuming that you are not part of a domain since you switched machines.

What I have found that works is to grant modify rights to the "Everyone" user on the root of the external drive. It will take some time to process, but it will open up the drive for any account to access the drive.

This does introduce a security risk that it makes it easy for anyone to edit files on the drive. If you are worried, encrypting the drive can mitigate that concern. Most people use these drives to pass files around so they want everyone to be able to read it.

Hope this helps

Answer 3

This can also be due to the "Creator/Owner" right being assigned. When a user creates a file, their specific user will be added to the File's ACL, and if/when their user is deleted, the now unmapped SID will remain, and cannot be removed, since the "Creator/Owner" is stil being inherited. The fix is to determine where the "Creator/Owner" permission is being inherited from, and then remove it from that folder. As long as you don't have any inheritance blocks in place, that should solve the issue.