SECURITY

Windows file permissionsNTFS ACLs, ownership and inheritance

Windows controls access to files and folders with NTFS permissions: each object has an access control list (ACL) of entries granting or denying specific rights to users and groups. Permissions are inherited from parent folders by default, an owner can always change permissions, and effective access is the combination of share and NTFS permissions. Access-denied problems usually come from a missing grant or a blocking deny.

BlackhawkHub Editorial · Updated

The ACL model

Every file and folder on an NTFS volume carries an access control list (ACL): an ordered set of access control entries (ACEs), each granting or denying specific rights to a user or group (identified by their SID). When an account tries to access an object, Windows evaluates the ACL against the account's group memberships to decide.

Standard permission levels

LevelAllows
Full ControlEverything, including changing permissions and ownership
ModifyRead, write, delete
Read & ExecuteRead and run files, traverse folders
ReadView contents and attributes
WriteCreate files and write data

Behind these sit finer-grained "special" permissions (traverse folder, take ownership, change permissions and so on) visible through the Advanced view.

Key rules

  • Deny overrides Allow. An explicit Deny for a group you belong to blocks access even if another entry allows it. Deny entries are a frequent cause of puzzling access-denied errors.
  • Inheritance. Child files and folders inherit the parent's permissions by default. Breaking inheritance on a subfolder lets you set different permissions there; changes at the parent then stop flowing down.
  • Ownership. The owner can always modify the ACL, even if no ACE grants them access. Administrators can take ownership to regain control of an object.
  • Effective access is the sum of all applicable Allow entries, minus any Deny.

Share versus NTFS permissions

Two permission systems apply to network access over SMB:

  • NTFS permissions apply everywhere, local and remote.
  • Share permissions apply only when the folder is reached over the network.

When both apply, the more restrictive wins. The usual practice is to set share permissions broadly (for example Authenticated Users: Full Control) and control real access with NTFS, so there is one place to manage it. A net use "access denied" (system error 5) is often a permission mismatch here.

Fixing access problems

  1. Confirm which account you are running as with whoami, and whether the session is elevated.
  2. Open the object's Security tab; add your account or group with the needed level, or find a blocking Deny.
  3. Take ownership if you cannot edit the ACL: right-click → Properties → Security → Advanced → Change owner, or:
cmd
takeown /f "C:\path\folder" /r /d y
icacls "C:\path\folder" /grant "%USERNAME%":(OI)(CI)M /t
  1. On a web server, an HTTP 403 or 500 can trace to the application pool or service account lacking read/execute on the site files; grant it precisely rather than opening the files to Everyone.

Good practice

  • Grant to groups, not individual users, and grant the least access that works.
  • Avoid Everyone: Full Control; it removes meaningful protection.
  • Use inheritance deliberately; breaking it in many places makes permissions hard to reason about.
  • The Unix world expresses the same idea more compactly with read/write/execute bits; the chmod calculator shows that model.

Frequently asked questions

Why do I get "access denied" to a folder I own?

Ownership lets you change permissions, but you may not currently have a permission granting access. Take ownership if needed, then add your account with the required rights on the Security tab, or use icacls. A Deny entry anywhere in the ACL overrides Allows and is a common cause.

What is the difference between share and NTFS permissions?

Share permissions apply when accessing a folder over the network (via SMB, port 445); NTFS permissions apply always, locally and remotely. When both are in play, the most restrictive of the two wins. The common advice is to leave share permissions broad and control access with NTFS.

How do I fix permissions from the command line?

icacls "C:\path" shows the ACL; icacls "C:\path" /grant Users:(RX) grants read and execute; takeown /f "C:\path" /r takes ownership recursively. Use these carefully and avoid granting Everyone Full Control, which removes protection.

Sources