Almost every Windows admin has been here: you grant someone Full Control on a shared folder, they still can’t open a file, and you spend twenty minutes wondering what’s broken. Nothing’s broken. You set one of the two permission systems and forgot the other was quietly overruling it.
Windows file access runs through two separate permission layers — share permissions and NTFS permissions — and they’re evaluated independently. The effective access a user ends up with is the more restrictive of the two. Once that clicks, the mysterious “access denied” stops being mysterious. This article explains what each layer does, how they combine, how inheritance fits in, and the setup most admins settle on so they only have to reason about one layer day to day.
Two layers, two different jobs
The two systems exist for historical and architectural reasons, and they protect different things.
Share permissions vs NTFS permissions at a glance
| Where they live | Share permissions: on the SMB share. NTFS permissions: on the file system (folders/files). |
|---|---|
| When they apply | Share: only over the network (SMB). NTFS: always — network and local/RDP access. |
| Granularity | Share: per-share, three levels only. NTFS: per-file and per-folder, fine-grained. |
| Permission options | Share: Read, Change, Full Control. NTFS: Read, Write, Read & Execute, Modify, Full Control, plus advanced rights. |
| Inheritance | Share: none. NTFS: inherits down the folder tree by default. |
The key structural difference is reach. NTFS permissions apply no matter how the file is accessed — over the network, at the console, or through Remote Desktop. Share permissions only apply to traffic coming in over SMB. Someone who can log on to the server locally walks straight past the share permissions, which is exactly why the real security has to live in NTFS.
How the two layers combine: most restrictive wins
When a user opens a file over the network, Windows checks both gates:
- It works out the user’s effective share permission (from their group memberships on the share).
- It works out the user’s effective NTFS permission (from their group memberships on the folder/file).
- It grants whichever of those two is more restrictive.
It does not add them, and it does not let the more generous one win. Two gates in series — you only pass to the level both allow.
Effective access = the tighter of the two
| Share = Full Control | NTFS = Read |
|---|---|
| Share = Read | NTFS = Modify |
| Share = Change | NTFS = Full Control |
| Share = Full Control | NTFS = Full Control |
| Share = Read | NTFS = Deny Read |
Look at row two. That’s the classic support call: you set NTFS to Modify, the user still can’t save changes, and it’s because the share is capped at Read. Both numbers matter, and the smaller one is the answer.
Within a single layer, permissions accumulate
There’s a second rule that sits underneath “most restrictive wins,” and mixing them up causes confusion. Within one layer, a user’s permissions are cumulative across their groups — then an explicit Deny overrides.
Say Jane is in Staff (NTFS Read) and Editors (NTFS Modify) on the same folder. Within NTFS, those add up: she effectively has Modify. The “most restrictive” rule only applies between the share layer and the NTFS layer, not between two groups inside the same layer.
The exception is Deny. A Deny entry beats an Allow at the same level. If Jane is also in a group with Deny Write, that Deny wins regardless of the Allows she has elsewhere in NTFS.
NTFS inheritance
NTFS permissions flow downhill. By default, a new folder or file inherits the permissions of its parent, so setting permissions once at the top of a share propagates to everything beneath it. You’ll see inherited entries greyed out in the Security tab — you can’t edit them on the child; you edit them on the parent they come from.
Two things you can do with inheritance:
- Add explicit permissions on a child folder. These stack with the inherited ones (subject to the Deny rule).
- Break inheritance on a child so it no longer receives the parent’s permissions. Windows offers to either copy the existing inherited entries (so nothing changes immediately) or remove them (so you start clean). Copying is the safer default.
# View the ACL on a folder, including whether inheritance is enabled
Get-Acl "D:\Shares\Finance" | Format-List Path, AccessToString, AreAccessRulesProtectedAreAccessRulesProtected = True means inheritance has been broken on that folder. That’s worth checking when a subfolder behaves differently from its siblings — someone probably broke inheritance there and set explicit permissions.
The setup most admins actually use
After enough years of fighting two permission systems, the common practice is to stop using the share layer for real access control and let NTFS do all the work. The reasoning is simple: NTFS is far more granular, it applies to local access too, and managing one system is less error-prone than reconciling two.
The widely used pattern:
Recommended file share permission model
- Set the share permission once, broadly: Authenticated Users (or Everyone) = Full Control or Change
- Do all real access control with NTFS permissions on the folder tree
- Assign NTFS permissions to groups, not individual users
- Let inheritance carry permissions down; break it only where a subtree truly differs
- Avoid Deny entries unless carving a specific exception
- Use the Effective Access tab to verify before you walk away
Why set the share so wide? Because if the share is the tighter gate, it silently caps NTFS and you’re back to debugging two layers. Opening the share to Authenticated Users with Change/Full Control means the share never becomes the restriction — whatever you set in NTFS is what the user gets. That’s the whole point: one place to reason about.
Assigning NTFS rights to groups rather than users is the other half of a maintainable model. In a domain, the long-standing approach is to put users into a group, grant that group the access it needs on the folder, and never touch individual ACL entries. When someone joins or leaves a team, you change group membership — you don’t go re-permissioning folders. If you’re standing up the directory side of this, our guide to installing AD DS on Windows Server 2022 covers getting the domain in place first.
A worked example
Say Finance needs a share where the whole team can read, but only managers can change files.
- Share permission:
Authenticated Users= Full Control. (The share is wide open; NTFS does the gating.) - NTFS on
D:\Shares\Finance:Finance-Readgroup = Read & Execute;Finance-Managersgroup = Modify. - Inheritance carries those down to subfolders. A subfolder of confidential files breaks inheritance and grants only
Finance-Managers= Modify, removing the read group there.
A Finance-Read member opening a normal file gets: share = Full Control, NTFS = Read & Execute → effective Read. A manager opening the same file gets: share = Full Control, NTFS = Modify → effective Modify. The read user opening the confidential subfolder hits a broken-inheritance ACL that doesn’t include them → no access. One coherent model, all of it expressed in NTFS.
Wrapping up
The whole subject comes down to a few rules. There are two permission layers; share permissions apply only over the network while NTFS applies everywhere; and when both are in play, the more restrictive one wins. Within a layer, group permissions accumulate, but an explicit Deny overrides. Inheritance pushes NTFS permissions down the tree until you break it.
The practical takeaway is to stop splitting the work across both systems. Open the share to Authenticated Users, control everything with NTFS group permissions, lean on inheritance, and check the Effective Access tab before you call it done. You’ll spend far less time hunting for the layer that’s quietly saying no.
