NTFS Permissions Explained: Evaluation Order and Fixes

NTFS permissions control which users and groups can access files and folders on NTFS volumes. They are the reason you sometimes get an “Access Denied” error even when you are the administrator. The rules for how permissions combine are straightforward, but the surprises come from the order of evaluation and from inheritance. This page explains how Windows evaluates permissions, how to read the effective result, and how to fix common permission problems without taking ownership of system folders—a step that often creates more problems than it solves.

How NTFS Permissions Work

Every file and folder on an NTFS volume has an access control list (ACL). The ACL contains access control entries (ACEs), each of which grants or denies a specific permission to a user or group. The basic permissions are:

• Full control – read, write, modify, delete, change permissions, and take ownership.
• Modify – read, write, modify, and delete.
• Read & execute – read and run executables.
• List folder contents – view file and folder names (folders only).
• Read – view file contents and attributes.
• Write – create files and folders, and write to files.

These are the “special permissions” that appear in the advanced view. When you see a simple checkmark for “Read” in the basic view, it actually includes several special permissions.

Evaluation Order: Allow, Deny, and Inheritance

Windows evaluates permissions in a strict order. Understanding this order is the key to predicting the effective permission.

1. Explicit deny – any ACE that explicitly denies a permission is applied first.
2. Explicit allow – any ACE that explicitly allows a permission is applied next.
3. Inherited deny – permissions inherited from a parent folder that deny are applied after explicit entries.
4. Inherited allow – inherited allows are applied last.

If any deny ACE matches the user or a group the user belongs to, the permission is denied, regardless of any allow. This is why a single deny rule can block access even if the user is also in a group that has full control.

Inheritance means that permissions set on a parent folder are passed down to child folders and files. By default, child objects inherit permissions from their parent. You can break inheritance for a specific object, which copies the inherited permissions as explicit entries and lets you modify them.

Effective Permissions

To see the effective permissions for a user, open the folder’s Properties → Security tab → Advanced → Effective Access. Select a user and click View effective access. This shows exactly which permissions the user would have, after all evaluation rules are applied. This is the first thing to check when you get an unexpected “Access Denied” error.

Common Permission Errors and Fixes

Error: “Access Denied” when you should have access

1. Check effective permissions for the user who is getting the error. If the effective access shows the needed permission, the problem is not NTFS permissions—it could be a share permission (if accessing over the network) or a file attribute like read-only.
2. Check for a deny entry that applies to the user or a group they belong to. Look in the Security tab → Advanced → Permissions and look for any “Deny” entries.
3. Check inheritance – if the object does not inherit permissions from a parent that grants access, the user may not have any permission. In that case, you need to add the user or group explicitly.

To add a user:

• Right-click the file or folder → Properties → Security → Edit → Add.
• Enter the user or group name, click Check Names, then assign the needed permissions.

Error: “You need permission to perform this action” when moving or copying files

This often happens when the destination folder does not grant Write permission to the user. To fix, add the user with Modify permission to the destination folder.

Error: “Access is denied” when opening a file that you own

If you own the file but still cannot open it, the ACL may have been corrupted or the file may have been copied from another system. Use icacls to reset permissions.

Using icacls to Fix Permissions

icacls is the built-in command-line tool for viewing and modifying NTFS permissions. It is more precise than the GUI and allows you to script fixes.

View permissions

icacls C:\path\to\folder

The output shows the ACL. Each line is an ACE. For example:

C:\path\to\folder BUILTIN\Administrators:(OI)(CI)(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 BUILTIN\Users:(OI)(CI)(RX)
                 BUILTIN\Users:(CI)(AD)

• (F) – full control
• (RX) – read and execute
• (M) – modify
• (OI) – object inherit (files inherit)
• (CI) – container inherit (folders inherit)
• (IO) – inherit only
• (AD) – allow delete
• (D) – deny

Grant permission to a user

icacls C:\path\to\folder /grant "DOMAIN\User":(OI)(CI)M

This grants Modify permission to the user, and the (OI)(CI) flags make it inherited by child objects.

Remove a deny entry

icacls C:\path\to\folder /remove:d "DOMAIN\User"

This removes all deny entries for that user.

Reset permissions to inherited defaults

icacls C:\path\to\folder /reset

This resets the ACL to the default inherited permissions. It does not delete the folder or its contents. Use this when the ACL is corrupted or you want to start fresh.

What NOT to Do: Taking Ownership of System Folders

A common piece of advice on the internet is to “take ownership” of a system folder (like C:\Windows\System32 or C:\Program Files) and grant yourself full control. This is almost always the wrong fix. It can break Windows security, cause system instability, and create permission problems that persist long after the original issue is solved.

Taking ownership changes the owner of the folder to your user account. This can interfere with Windows services that rely on the original owner (like TrustedInstaller) and can prevent updates or cause system files to be modified by mistake. If you have already taken ownership and want to undo it, you can restore the default owner using icacls.

To restore the default owner for a system folder:

icacls C:\Windows\System32 /setowner "NT SERVICE\TrustedInstaller"

This sets the owner back to the Windows service that normally owns system files. Do not do this for folders that are not owned by TrustedInstaller; check the current owner first with:

icacls C:\Windows\System32 /getowner

Comparison of Permission Fixes

What People Get Wrong About NTFS Permissions

The most common misconception is that the administrator account can access anything. In reality, even administrators are subject to NTFS permissions unless they take ownership or change permissions. The built-in Administrators group has Full control on most system folders, but not on every file. If a file’s ACL explicitly denies the Administrators group, even an administrator is blocked.

Another natural mistake is to think that if you are the owner of a file, you can always access it. Ownership gives you the right to change permissions, but it does not automatically grant you access. If the ACL does not include you, you still cannot open the file until you change the ACL.

A third common error is to confuse share permissions with NTFS permissions. When accessing a file over the network, both share permissions and NTFS permissions apply, and the effective permission is the most restrictive of the two. If you are getting “Access Denied” over the network but can access the file locally, the problem is likely share permissions, not NTFS.

Finally, many people try to fix an “Access Denied” error by taking ownership of a folder and granting full control to everyone. This is a blunt instrument that can expose sensitive files and break system functionality. The correct approach is to identify the specific user or group that needs access and grant only the necessary permissions.

Steps to Diagnose a Permission Problem

1. Identify the exact error – Is it “Access Denied” when opening, modifying, or deleting? The permission needed differs.
2. Check effective permissions for the affected user.
3. Check the ACL for deny entries.
4. Check inheritance – is the object inheriting permissions from a parent?
5. Apply the least-destructive fix – add the user, remove a deny, or reset the ACL.
6. Test – have the user try the action again.

If the problem persists after these steps, the issue may not be NTFS permissions at all. Check file attributes (read-only, hidden), share permissions, or disk errors.

Using chkdsk for Disk Errors

Sometimes “Access Denied” errors are caused by file system corruption, not permissions. Run chkdsk to check for errors:

chkdsk C: /f

This will scan the drive and fix file system errors. It may require a restart if the drive is in use. This is a safe diagnostic step that does not change permissions.

Summary of Key Commands

These commands are safe when used correctly. Always back up important data before making changes to permissions, and test on a non-critical file first if you are unsure.