Ever since the NTFS file system was introduced as the default format in consumer editions of Windows (starting with Windows XP), people have had issues with accessing their data on both internal and external drives. No longer are simple file attributes the sole cause of problems when finding and using their files. Now we have to contend with file and folder permissions, as one of our readers discovered.
Our Reader's Question:
I am unable to see folders on my internal hard disk. I ran the command "attrib -h -r -s /s /d" and it shows access denied on every folder. I can go to folders using the Run command but I can't see folders on my hard drive. How do I fix this?
Bruce's Reply:
Here are some safe assumptions based on the information we've been given: The operating system is Windows XP or later; the file system in use is NTFS; the user does not have Full Control permissions on the portion of the file system they are trying to manipulate; they aren't in the Administrator context; and the default permissions on the file system may have been altered.
Everything in Windows is an object, whether it is a registry key, a printer, or a file. Even though they use the same mechanisms to define user access, we will restrict our discussion to file system objects to keep it as simple as possible.
Access Control
Security of any sort is all about controlling who can do something on the object being secured. Who has the key card to unlock the gate to enter the compound? Who has the keys to open the CEO's office? Who has the combination to open the safe in their office?
The same type of thinking applies to the security of files and folders on NTFS file systems. Every user on the system does not have a justifiable need to access every file on the system, nor do they all need to have the same kind of access to these files. Just like every employee in a company does not need to have access to the safe in the CEO's office, or the ability to modify corporate reports, though they may be allowed to read them.
Permissions
Windows controls access to file system objects (files and folders) by setting permissions for users or groups. These specify what kind of access the user or group has to the object. These permissions can be set to either allow or deny a specific type of access, and can either be set explicitly on the object, or implicitly through inheritance from its parent folder.
The standard permissions for files are: Full Control, Modify, Read & Execute, Read, Write, and Special. Folders have another special permission, called List Folder Contents. These standard permissions are predefined sets of advanced permissions which allow more granular control, but are not normally needed outside of the standard permissions.
For example, the Read & Execute standard permission includes the following advanced permissions:
- Traverse Folder / Execute File
- List Folder / Read Data
- Read Attributes
- Read Extended Attributes
- Read Permissions
Access Control Lists
Each object in the file system has an associated Access Control List (ACL). The ACL is a list of security identifiers (SIDs) that have permissions on the object. The Local Security Authority Subsystem (LSASS) will compare the SID attached to the access token given to the user at login to the SIDs in the ACL for the object the user is attempting to access. If the user's SID does not match any of SIDs in the ACL, access will be denied. If it does match, the requested access will be granted or denied based on the permissions for that SID.
There is also an evaluation order for permissions that needs to be considered. Explicit permissions take precedence over implicit permissions, and deny permissions have precedence over allow permissions. In order, it looks like this:
- Explicit Deny
- Explicit Allow
- Implicit Deny
- Implicit Allow
Default Root Directory Permissions
The permissions granted at the root directory of a drive vary slightly, depending on if the drive is the system drive or not. As seen in the image below, a system drive has two separate Allow entries for authenticated users. There is one that permits Authenticated Users to create folders and append data to existing files, but not to change any existing data in the file which applies solely to the root directory. The other allows Authenticated Users to modify files and folders contained in subfolders, if that subfolder is inheriting permissions from the root.
The system directories (Windows, Program Data, Program Files, Program Files (x86), Users or Documents & Settings, and possibly others) do not inherit their permissions from the root directory. Because they are system directories, their permissions are explicitly set to help prevent inadvertent or malicious alteration of operating system, program, and configuration files by malware or a hacker.
If it is not a system drive, the only difference is that the Authenticated Users group has a single allow entry that allows Modify permissions for the root folder, subfolders, and files. All permissions assigned for the 3 groups and the SYSTEM account are inherited throughout the drive.
Problem Analysis
When our poster ran the attrib command attempting to remove any system, hidden, and read-only attributes on all files and folders starting at the (unspecified) directory they were in, they received messages indicating the action they wanted to perform (Write attributes) was being denied. Depending on the directory they were in when they ran the command, this is likely a very good thing, especially if they were in C:\.
Instead of attempting to run that command, it would have been better to just change the settings in Windows Explorer/File Explorer to show hidden files and directories. This can be easily accomplished by going to Organize > Folder and search options in Windows Explorer or File > Change folder and search options in File Explorer. In the resulting dialog box, select the View tab > Show hidden files, folders, and drives. With this enabled, hidden directories and files would show up as dimmed items in the list.
At this point, if the files and folders are still not showing up, there is an issue with the List Folder / Read Data advanced permission. Either the user or a group the user belongs to is explicitly or implicitly denied that permission on the folders in question, or the user does not belong to any of the groups that have access to those folders.
You may ask how the reader could go directly to one of these folders if the user doesn't have the List Folder / Read Data permissions. As long as you know the path to the folder, you can go to it provided you have the Traverse Folder / Execute File advanced permissions on it. This is also the reason that it is not likely to be an issue with the List Folder Contents standard permission. It has both of these advanced permissions.
The Resolution
With the exception of system directories, most permissions are inherited down the chain. So, the first step is to identify the directory closest to the root of the drive, where the symptoms surface. Once this directory is located, right-click it and select Properties > Security tab. Check the permissions for each of the groups/users listed, in order to verify they have a check in the Allow column for the List folder contents permission and not in the Deny column.
If neither column is checked, also look at the Special permissions entry. If this is checked (either allow or deny), click the Advanced button, then Change Permissions on the resulting dialog box if you are running Vista or later. This will bring up a nearly identical dialog box with a few additional buttons. Select the appropriate group, click Edit and ensure the List folder / read data permission is allowed.
If the checks are grayed out, it means it is an inherited permission, and changing it should be done at the parent folder, unless there is a compelling reason not to do so, such as it is a user's profile directory and the parent would be the Users or Documents & Settings folder. It is also unwise to add permissions for a second user to be able to access another user's profile directory. Instead, log in as that user to access those files and folders. If it is something that should be shared, move them to the Public profile directory or use the Sharing tab to allow other users to access the resources.
It is also possible the user does not have permission to edit the permissions of the files or directories in question. In that case, Windows Vista or later should present a User Account Control (UAC) prompt for the administrator password or permission to elevate the user's privileges to allow this access. Under Windows XP, the user should open Windows Explorer with the Run as... option and use the Administrator account to ensure the changes can be made, if they are not already running with an administrative account.
I know that many people would just tell you to take ownership of the directories and files in question, but there is one huge caveat to that solution. If it would impact any system files and/or directories, you will be severely weakening the overall security of your system. It should never be done on the root, Windows, Users, Documents & Settings, Program Files, Program Files (x86), Program Data, or inetpub directories or any of their subfolders.
Conclusion
As you can see, permissions on NTFS drives are not overly difficult, but locating the source of access problems can be tedious on systems with a lot of directories. Armed with a basic understanding of how permissions work with access control lists and a bit of tenacity, locating and fixing these issues will soon become child's play.