Effective Permissions: Why a User Can't Access a File

When a user receives an access denied error, the cause is rarely a single permission entry. Windows evaluates the user’s effective permissions by combining the permissions granted to the user and to every group the user belongs to, then applying a set of rules. Understanding these rules is the first step to fixing the problem. This page explains how to determine the effective permissions for a user on a specific file or folder using the tools built into Windows, and how to correct the cause without resorting to taking ownership of system folders.

How Windows Evaluates Permissions

Windows uses an access control list (ACL) that contains access control entries (ACEs). Each ACE allows or denies specific permissions to a user or group. When a user attempts to access a file or folder, the system reads the ACEs in order and stops as soon as every requested permission has been either allowed or denied (How DACLs control access to an object). Windows keeps the entries in this order (Order of ACEs in a DACL):

1. Explicit Deny – entries set directly on the object that deny a permission.
2. Explicit Allow – entries set directly on the object that allow a permission.
3. Inherited Deny – denies inherited from the parent folder (then the grandparent, and so on up the tree, each level’s denies before its allows).
4. Inherited Allow – allows inherited from the parent folder, in the same order.
5. No matching entry – a permission that no entry allows is denied.

The key point: “deny always wins” is not accurate. An explicit deny beats any allow, but an explicit allow on the object beats a deny inherited from a parent folder, because the explicit allow is read first. Within the same level, deny comes before allow. Permissions are also cumulative – if the user is granted read through one group and modify through another, the effective permission is the union (read + modify). A deny at a higher-priority position blocks that specific permission even if an allow exists lower down.

Another important aspect is permission inheritance. By default, files and folders inherit permissions from their parent. When you see an access denied error, it may be because the parent folder’s permissions are not what you expect, or because inheritance has been broken (disabled) on the object.

Diagnosing with Built-in Tools

Step 1: Check Effective Permissions on the Object

Windows provides a built-in method to view effective permissions for a specific user. This is the most direct way to answer “why can’t this user access this?”

1. Right-click the file or folder, select Properties.
2. Go to the Security tab.
3. Click Advanced.
4. In the Advanced Security Settings window, go to the Effective Access tab.
5. Click Select a user and enter the user account name (e.g., domain\username or [email protected]).
6. Click View effective access.

The results show which permissions are allowed or denied. If a permission is marked as Deny, look for the source – the tool will show the ACE that caused the denial, including the group that inherited it.

This tool works on NTFS volumes and on shares, but it only shows the effective permissions as computed from the ACL. It does not account for share permissions (if the access is over a network share) or for other factors like encryption or read-only attributes.

Step 2: Check Share Permissions (if applicable)

If the user is accessing the file over a network share, share permissions also apply. The effective permission is the most restrictive combination of share and NTFS permissions. For example, if share permissions allow Read but NTFS allows Modify, the user gets Read. If share allows Full Control but NTFS denies Write, the user cannot write.

To check share permissions:

1. Right-click the shared folder, select Properties.
2. Go to the Sharing tab, click Advanced Sharing, then Permissions.
3. Review the entries for the user and groups.

Step 3: Use Command-Line Tools for a Detailed View

For a more detailed view of the ACL, use icacls from an elevated command prompt. This shows all ACEs, including inherited ones.

icacls "C:\path\to\folder"

The output lists each user or group and the permissions. For example:

BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)

• (OI) – object inherit (files inherit this ACE)
• (CI) – container inherit (subfolders inherit this ACE)
• (F) – full control
• (RX) – read and execute
• (M) – modify
• (R) – read
• (W) – write
• (D) – delete

There is no icacls switch that computes effective permissions. icacls lists the ACEs on an object; working out what they add up to for a particular user is a separate calculation, and the Effective Access tab is the tool that does it. In PowerShell, Get-Acl likewise returns the ACL rather than an effective result — reducing it to a yes or no for one user means resolving that user’s full group membership yourself, including nested and domain-local groups, which is exactly the work the GUI is doing for you.

Step 4: Check Group Membership

Often, the user is denied because they are a member of a group that has a deny ACE. To see all groups a user belongs to, use the command prompt:

whoami /groups

This lists all groups for the current user. For another user, use net user username /domain or Get-ADUser in PowerShell, but the simplest is to use the GUI: in the Effective Access tab, the source of each permission is shown.

Common Causes and Fixes

Cause 1: Explicit Deny Entry

A deny entry for the user or a group they belong to is the most common cause. Look for a deny ACE in the ACL. If you find one, you can remove it or change it to allow, but be careful: the deny may be there for a reason (security policy).

Fix: Remove the deny entry or modify it. To remove, use icacls with the /remove switch:

icacls "C:\path\to\folder" /remove "DOMAIN\GroupName"

This removes all ACEs for that group. To remove only a specific deny, you need to use the GUI or PowerShell. The GUI is safer.

Cause 2: Inheritance Broken

If inheritance is disabled on the object, it may not have the necessary permissions from the parent. You can check this in the Advanced Security Settings under the Permissions tab. If the Enable inheritance button is visible, inheritance is disabled.

Fix: Re-enable inheritance by clicking Enable inheritance. This will copy the parent’s permissions to the object. If you need to keep the permissions that are currently inherited, disable inheritance and choose Convert inherited permissions into explicit permissions on this object when Windows offers it — that keeps the entries and detaches them from the parent, rather than removing them.

Cause 3: The User Is Not in the Right Group

Sometimes the user simply lacks the required permission. For example, they need write access but are only in the Users group with read-only. In that case, you need to add the user or a group they belong to to the ACL with the appropriate permission.

Fix: Add the user or group with the needed permission using the GUI: on the Security tab, click Edit, then Add, enter the user/group, and select the permission. Or use icacls:

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

This grants modify permission to the user for this folder and all subfolders and files.

Cause 4: Share Permissions Restrict Access

If the access is over a network share, share permissions may be more restrictive than NTFS. Check the share permissions and adjust them if necessary.

Fix: On the Sharing tab, click Advanced Sharing, then Permissions, and add the user with the appropriate share permission (usually Read or Change).

Cause 5: Ownership Issues

Sometimes the error is not about permissions but about ownership. For example, if the user needs to change permissions, they must be the owner or have the special permission “Change Permissions”. Taking ownership of system folders is not recommended because it can break system security and cause more problems. Instead, grant the specific permission needed.

Fix: If the user needs to take ownership (rare), they can do it on a specific object, but avoid doing this for system folders. For regular files, you can grant the user the “Change Permissions” permission through the GUI or icacls:

There is no single-letter icacls code for “change permissions” on its own — the simple rights icacls accepts are F, M, RX, R and W. Granting only the ability to change permissions, without granting Full Control, means going through the GUI: Advanced Security Settings → Add → Show advanced permissions, and ticking Change permissions by itself.

Comparison of Diagnostic Methods

What People Get Wrong

A common mistake is to immediately take ownership of a file or folder when access is denied. This is a natural reaction because the error message often says “You need permission to perform this action” and the only obvious button is “Continue” to take ownership. However, taking ownership of system folders (like C:\Windows) can break the system’s security model, cause instability, and create more access problems. The correct approach is to diagnose the actual permission issue using the effective access tool, and then grant the specific permission needed, not to change ownership.

Another common misconception is that if a user is an administrator, they can access anything. This is false. Even administrators are subject to ACLs unless they explicitly take ownership (which they can, but it still changes the ACL). The effective access tool will show that an administrator may still be denied if a deny ACE applies to them.

Fixing Without Taking Ownership

If the user needs access to a file or folder, the proper fix is to grant the necessary permission to the user or a group they belong to. Do not take ownership unless absolutely necessary, and never on system folders. Use the following steps:

1. Identify the user and the required permission (read, write, modify, etc.).
2. Check the effective access to see what is blocking.
3. Add the user or group to the ACL with the appropriate permission using the GUI or icacls.
4. If inheritance is broken, re-enable it or add the permission explicitly.

If the user needs to be able to change permissions themselves, grant them “Change Permissions” (special permission) rather than making them the owner.

Summary of Commands

Here are the essential commands for diagnosing and fixing permissions:

# View ACL for a file or folder
icacls "C:\path\to\folder"

# Grant modify permission to a user for a folder and its contents
icacls "C:\path\to\folder" /grant "DOMAIN\User":(OI)(CI)M

# Remove all permissions for a group
icacls "C:\path\to\folder" /remove "DOMAIN\Group"

# Show groups for current user
whoami /groups

Remember: always test the fix by having the user attempt the access again. If the problem persists, re-check the effective access and share permissions.

When to Reinstall or Reset

Resetting permissions on system folders is not a solution. If you have taken ownership of system folders and caused problems, the only reliable fix is to repair the system using sfc /scannow or DISM, but this does not restore original permissions. The best practice is to avoid changing system folder permissions altogether. If you have already done so, you may need to restore from a backup or perform a repair installation of Windows, but that is a last resort.