NTFS Access Control Lists (ACLs) and Security Descriptors (SDs) describe who can access what NTFS objects, and to what degree. If a given user or group has access to an object, the ACL for that object will contain a reference to that user or group—not by their name, but by their GUID.
This way, if you have an object somewhere on an NTFS partition that belongs to a user on a specific machine, those permissions are unique. You can't create a user with the same name on another machine and expect to have unrestricted access to that object; you have to take ownership of the object first. (There are other ways around this issue, but taking ownership of the files is the least complicated solution.)
You may run into this problem head-on if you have an NTFS-formatted drive with files on it that are owned by a user who was only present in another installation of Windows somewhere. I ran into this when creating a new, clean installation of Windows on one of two drives in a system I own. The old installation of Windows wasn't bootable anymore, so I created a new one from scratch and started to sort through the files on the second hard drive. To my dismay, I found a directory that I couldn't delete, rename or do much of anything else with.
At first I thought it was a "file in use" issue, so I tried using Unlocker to free up the file. CHKDSK turned up nothing. Eventually I realized that the files in question had been owned by the administrator in the older, now-deleted installation of Windows. I took ownership of the problem folder and reset its permissions to inherit from the root of the drive. Once I did that, I was able to delete the directory without a hitch.
Soon after, a friend experienced similar problems. He was using an external hard drive, formatted as NTFS, which somehow had had the "Everyone" permissions revoked on most of the objects on it. The only user who could access the files on it was his Admin account on his desktop computer. . .which was no longer bootable. But once he restored and reset the permissions appropriately, everything was accessible once again.
The irony is that NTFS was simply behaving exactly as it ought to. But my friend had simply tightened permissions of the objects on that drive to the point where he was inconveniencing himself!
If you open the Security dialog for an object and see a CLSID-type number (a CLSID is a class ID GUID that identifies a COM object) instead of a username or group, that's a sign that the user information for that object isn't present on that system. Either it's either been deleted or it's from another computer. Such "missing" entries are not purged by default, because for all NTFS knows they could be perfectly valid user IDs from another computer. If you're confident that these user IDs are not valid, and you want to inspect a volume for all possible such entries, you can use the SubInACL command-line tool (from Microsoft) to find them.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter, which is devoted to hints, tips, tricks, news and goodies for Windows NT, Windows 2000 and Windows XP users and administrators. He has more than 10 years of Windows experience under his belt, and contributes regularly to SearchWinComputing.com and SearchSQLServer.com.
More information on this topic:
