10 things you should know about working with NTFS permissions

NTFS and share-level permissions both affect the user's ability to access resources on a network, and you need a good understanding of both types to untangle and resolve certain access issues. These tips and best practices will help you avoid some typical problems.

Managing and troubleshooting permissions can be challenging, especially when everything looks like it should work. These tips and best practices will help you avoid some common problems.

#1: NTFS vs. share permissions

The biggest point of confusion about sharing with Windows systems is that the NTFS and share-level permissions both have an effect on the user's ability to access resources on a network. This is especially important to remember for Windows XP and Windows Server 2003—and likely subsequent versions of Windows—which have default share permissions as read-only. This makes the NTFS permissions limited to read when accessing them over the network.

The best way to distinguish share permissions from NTFS permissions is to consider share permissions as an entry point to the resources. Only after the share permissions offer Change and/or Full Control can the NTFS permissions of that type be used.

The combination of share-level and NTFS permissions can seem like administrative overhead, but consider this: Share permissions act as a point of entry for the NTFS permissions over the network. When you enter a network resource through a share, the share permissions dictate what you cando through the share as a whole. The NTFS permissions dictate what you can do to specific files and folders. In the troubleshooting mode, identify whether share-level permissions can be ruled out of the issue.

#2: Avoid nested shares

Troubleshooting issues that deal with both NTFS and share permissions can seem overwhelming. Avoid having nested shares in your file structures because they can create conflicting behavior for the same network resources if accessed through different shares. This can be asking for trouble, especially when the share permissions are different. A nested share is a shared folder that resides in a separate shared folder. There are, of course, the default hidden shares (C$, D$, etc.), which make all shares nested beneath them, and they're a default. However, if your users use two separate nonhidden shares that are nested, there can be conflicting share permissions.

#3: Use CACLS and XCACLS for granularity

You can use CACLS and XCACLS to gather information on files that are a reflection of the NTFS permissions you have configured. These tools will deliver data about the permissions for specific file and folder resources. What's the difference between NTFS permissions and an ACL (access control list)? The NTFS permissions are set in Windows Explorer or via an automated mechanism for files and folders, whereas an ACL (via these tools) is a display or management of allowed or denied file operations for the same resource.

You can use CACLS and XCACLS to add or remove NTFS permissions in a scripted fashion as well. So if you have a great deal of permissions to adjust, a sophisticated script using these tools may be in order.

A good matter of practice for important shared files and folders with unique NTFS permissions is to make a script utilizing the CACLS.EXE tool to document the ACL for individual files and folders (or manually execute the steps to do this). But be careful: You can easily document your NTFS permissions by running "CACLS * /T" from a command prompt and document a folder, its contents, and subdirectories. This is very resource intensive and can require 100% CPU utilization on some systems when traversing extremely large folder paths. Depending on many factors, a large recursive ACL audit can take large amounts of time as well. This is similar to the scenario where new NTFS permissions are propagated to a large folder.

#4: Distinguish between basic and special NTFS permissions

Only a right-click away, special permissions give more options to particular access requirements. It's important to note that using special permissions will increase the administrative overhead associated with NTFS permissions simply by being more complicated. Therefore, a best practice would be to use the special permissions only when needed. The standard NTFS permissions provide most of the necessary functionality to offer secure access to shared and local resources. However, there are scenarios where using the special permissions makes sense.

Note: Be sure to rule out special permissions in troubleshooting. Every administrator has at one point not been sure of the application of various permissions—share permissions, NTFS permissions, group memberships, multiple user accounts, etc. Taking a quick look at the special permissions can quickly provide a hint as to whether they're part of the issue you are troubleshooting.

#5: Keep resources warranting special permissions separate

If the scenario permits, it can be a good practice to keep resources requiring special permissions grouped in separate shares or folders with other resources that have special permissions. Having standard permissions intermixed with special permissions in the same location can add administrative overhead.

#6: Understand inherited permissions

Inherited permissions is a default attribute of NTFS permissions on Windows Server 2003 and 2000 systems. Inherited permissions allow NTFS settings for a folder be applied to its contents and all objects and folders contained within the top folder.

Inheritance is fairly easy to understand when all defaults are used. But when inheritance is blocked, it becomes more difficult to troubleshoot. This difficulty is manifested when a folder deep within another folder has the Inherit Permissions option cleared. In troubleshooting inherited permissions, it is best to start at the root of the problem and work your way up the folder structure.

#7: If clearing inheritance, be careful

When you clear inheritance of NTFS permissions from a parent container, you are presented with two options: Copy and Remove. The Copy option will recurse the child objects and write the NTFS permissions from the parent folder. The Remove option removes all default NTFS-created permissions—that of Administrators, Users, Creator Owner, System, etc.—from the list of Group or User Names. Exercise caution when using the Remove option on inheritance blocking!

#8: Don't dodge the issue

The worst thing you can do to solve a rights problem is to make someone a member of Administrators or some other powerful group to circumvent a permissions issue. Simply giving more rights to a user does not address the issue. Always identify the issue to determine the best solution.

#9: Never over-privilege

A common misstep is to provide too many rights—usually through group memberships—to users for access to resources. Especially if you are using Active Directory, a clearly organized structure with the membership and access requirements defined will lend to a more correctly administered user or group. Take the firewall stance of granting that which is explicitly required.

Too many permissions may not arise as a problem in a troubleshooting mode, but you may see one group or other membership attribute that gives too many rights—accidentally.

Group membership is one of the easiest ways to over- or under-privilege access to resources. Especially in domain configurations, the complexity is increased by multiple memberships and/or nested groups. Use the Effective Permissions tool to see what the resultant set of access is, determined by group membership when using Active Directory. Although this is not a direct display of NTFS permissions, you can then examine each group membership for an object as part of troubleshooting NTFS permissions.

#10: Know when to copy and when to move

Standard copy and move operations deliver default results that can maintain your configured permissions—or break them. A good way to remember this is that copy operations will create the permissions of the destination container, and move operations will maintain that of the parent container.

Memorization mechanism: CC/MM — CopiesCreate/MovesMaintain or CopiesCreate/MovesMake.

Of course, there is also the need to copy resources and maintain NTFS permissions that would be difficult to re-create. The fallen SCOPY utility has given way to XCOPY with the /O and /X parameters to perform this type of function. Using XCOPY with these parameters will allow copy operations to copy the files and/or folders to a new location and create them with the NTFS permissions equal to that of the source container.


Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

Editor's Picks