Windows File Permissions: Share vs NTFS Stacking

Every Windows admin runs into the same question on a file server: “I gave the user Full Control on the Security tab — why can’t they delete the file?” The answer is almost always that two permission systems are in play at once, and they do not combine the way intuition suggests.

This is Part 2 of the Windows Permissions Deep Dive pathway. Part 1 covered the five design rules. Here we get into the mechanics: how share and NTFS permissions stack, when each layer applies, and why “Deny” behaves the way it does.

The two permission systems on every Windows file server

Windows controls access to files and folders through two completely separate permission systems. They live on different tabs of the folder Properties dialog, they were designed in different decades, and they answer different questions.

NTFS permissions — the file system layer

NTFS permissions are set on the Security tab of a folder or file. They are stored in the file system itself, as part of the file’s metadata. They apply to every access — whether the user is sitting at the console, connected via RDP, accessing via a UNC path, or hitting the folder through a mapped drive. Anything that touches the file passes through NTFS.

This is the canonical layer. NTFS is where the truth lives.

Share permissions — the network gateway

Share permissions are set on the Sharing tab when you create an SMB share. They are stored separately from the file system — in the LanmanServer service’s configuration, not on the volume itself. They only apply when somebody accesses the folder over the network through the share name.

If a user is logged in directly to the server (RDP or console) and opens the folder through its local path (D:\Shares\SalesData), share permissions do not apply. Only NTFS does. Share permissions only kick in when traffic comes through SMB.

The cumulative rule within each layer

Both systems use the same internal rule: a user’s effective access is the union of every Allow ACE that applies to them, across every group they belong to.

Take a user, John Smith, who belongs to three groups: Sales, Marketing, and Managers. The folder \\fileserver\SalesData has these NTFS permissions:

• Sales — Modify (read, write, change content; cannot change permissions or take ownership)
• Marketing — Read & Execute
• Managers — Full Control

What does John have? Add the Allow ACEs together: Modify + Read & Execute + Full Control = Full Control. The highest set wins because the rights are additive. It is not “the most restrictive” and it is not “the first match” — everything Allowed combines.

Think of it like a buffet: if you are allowed apples, oranges, and pineapples through three different memberships, you may eat all three.

Deny always wins

The one exception to cumulative-Allow is the explicit Deny ACE. A Deny on any group John belongs to overrides every Allow that grants the same right, no matter how many.

If the Managers group has Full Control but also has Deny Delete, John inherits both. He can read, write, modify — but he cannot delete, because the Deny supersedes the Allow Delete that came via Full Control.

Why Deny is dangerous

Deny is a footgun. Once applied, it survives changes to group membership and to permissions higher in the tree. A user added to a group six years later still gets that group’s old Deny — usually without anybody remembering why. Best practice: do not use explicit Deny except for unusual one-off cases. Express the absence of access by simply not granting it, not by denying it.

If you must use a Deny: log it (per Part 1, Rule 5).

The one exception — the explicit-vs-inherited precedence

Windows has a subtle wrinkle: an explicit Allow on the object itself beats an inherited Deny from a parent. Order of precedence:

1. Explicit Deny on the object
2. Explicit Allow on the object
3. Inherited Deny from parent
4. Inherited Allow from parent

So a Deny set directly on the file beats an Allow set directly on the file, but an Allow set directly on the file beats a Deny inherited from a parent OU. This rarely matters in practice, but it explains a few baffling cases.

Share permissions — same cumulative behavior, different names

Share permissions are simpler: only three rights exist.

• Read — view files and subfolders, run programs
• Change — everything Read does, plus add, modify, delete
• Full Control — everything Change does, plus modify permissions and take ownership

The cumulative rule applies inside the share layer too. If John’s three groups have Change + Read + Change on the share, his share-level effective access is Change. (Read+Change combines to Change; Change+Change is still Change.)

The default share — Everyone : Read

When you create a new share in modern Windows (Server 2008 R2 and later), the default is Everyone : Read. In older versions it was Everyone : Full Control. Modern best practice: leave the default share permission permissive (Everyone : Full Control or Authenticated Users : Full Control) and do all real access control on the NTFS side. The reasoning follows in the next section.

The combining rule — share AND NTFS together

Now the question that breaks intuition. When BOTH layers are in play (user accesses the folder over the network), what does the user get?

The most-restrictive permission of the two layers wins.

This is the opposite of the cumulative rule that operates within each layer. Within NTFS: union (more permissive wins). Within share: union. Between NTFS and share: intersection (less permissive wins).

Worked example

John’s NTFS effective access on SalesData: Full Control (via Managers).
John’s share effective access on \\fileserver\SalesData: Change (via Sales).

When John maps the share over the network, his actual effective access is the intersection: Change. Full Control was granted by NTFS, but the share layer is more restrictive, so Change wins. John can read, write, modify, delete — but cannot change permissions or take ownership, because the share layer never grants those even though NTFS does.

The same user sitting at the server console

If John RDPs into the file server and opens D:\Shares\SalesData through its local path, the share layer is bypassed entirely. He sees NTFS-only: Full Control. This is why direct console access frequently grants more rights than network access — people forget about the share layer.

Procedure for computing effective permissions

The correct order when staring at a folder with conflicting ACLs:

1. Combine all the user’s NTFS ACEs (Allow rights summed; Deny overrides) → NTFS-effective
2. Combine all the user’s Share ACEs the same way → Share-effective
3. Take the intersection of the two → net network access

Walked through with another example: share grants Change for Sales, Read for Marketing, Change for Managers; NTFS grants Modify for Sales, Read & Execute for Marketing, Full Control for Managers. Many admins gut-feel the answer to be Read (the lowest in either layer). Wrong — here is the correct walk:

1. NTFS: Modify + Read & Execute + Full Control = Full Control
2. Share: Change + Read + Change = Change
3. Compare: Full Control vs Change → Change (more restrictive)

The modern best-practice configuration

Real-world Windows shops have converged on a simple rule that sidesteps the whole share-vs-NTFS confusion:

Set share permissions to a wide permissive grant. Do all access control on the NTFS side.

Concretely:

• Share permissions: Authenticated Users : Full Control (or Everyone : Full Control in older environments)
• NTFS permissions: granular, group-based, designed per Part 1’s five rules

This works because the intersection of (wide-open share) AND (carefully controlled NTFS) is the NTFS layer alone — no surprises. You manage one set of permissions instead of two. Audits become tractable. New shares get the same broad share template, and NTFS does the actual work.

Why not the reverse?

Because share permissions only apply over the network. If you do all the access control at the share layer, console users (RDP, server-side scripts, scheduled tasks) bypass it entirely and see everything that NTFS happens to allow — usually too much. NTFS is the only layer that always applies, so NTFS is the only safe place to enforce real policy.

UNC paths and effective access

Anything accessed via a UNC path (\\Server\Share\Folder) routes through the share layer and then NTFS. Both layers evaluate, intersection wins. This includes:

• Mapped drives via net use or Group Policy preferences
• Direct UNC paths typed into Explorer or PowerShell
• Application-level SMB connections (SQL Server reading from a share, Office opening a network file)
• DFS namespaces — the DFS link resolves to a share, which then evaluates both layers

The only Windows file access that bypasses share permissions is going through the local file system on the server itself (the D:\Shares\… path while logged into that server).

How to read effective access with built-in tools

The Effective Access tab

Folder Properties > Security > Advanced > Effective Access tab > Select a user. Windows walks every group the user is in, computes the cumulative NTFS access, and shows the result. This tab only shows NTFS, not share. Useful, but partial — you still have to manually compare it against the share permissions.

icacls on the command line

icacls "D:\Shares\SalesData" dumps the NTFS ACL in a single readable block. For scripting and bulk auditing, much faster than the GUI.

Get-SmbShareAccess in PowerShell

Get-SmbShareAccess -Name SalesData dumps the share-side ACL. Combine with Get-Acl for the NTFS side and you have a scripted view of both layers for any share.

Things that bite people

“I gave them Full Control — why doesn’t it work over the network?”

Almost always: the share layer is set to Read for Everyone (or for Authenticated Users). NTFS grants Full Control; share grants Read; intersection is Read. Fix: widen the share permissions, or stop using the share layer for access control.

“It works for me on the server, not for the user remotely”

Same root cause: console access bypasses the share, network access does not. Test with the user’s actual account over an actual SMB session, not your own admin session on the server.

Deny ACEs that nobody can explain

Inherited Denies from a long-forgotten parent OU are a major source of mystery access failures. When troubleshooting, walk the Effective Access tab to the explanation column — it tells you which ACE caused the result.

Authenticated Users vs Everyone

“Everyone” includes anonymous users in some configurations; “Authenticated Users” does not. Modern shops prefer Authenticated Users for the permissive share-level template. Functionally identical in domain-joined environments where every connection authenticates.

BUILTIN groups that surprise you

BUILTIN\Users often grants Read on NTFS by default through ACL inheritance from the volume root. New folders under a tree-default ACL pick this up automatically. Audit the BUILTIN groups when shares behave more permissively than expected.

NTFS denied permission, share allowed — the user blames the share

Users see “Access Denied” with no clue which layer fired. Always check both layers. The Effective Access tab on the NTFS side is your friend; for the share side, you have to read the Sharing tab directly.

Quick reference table

Summary in one paragraph

NTFS sits on the file system and applies to every access. Share sits on the network gateway and only applies to SMB traffic. Within each layer, Allow ACEs are cumulative and Deny always wins. Between the two layers, the most restrictive permission wins for network access; console access ignores share. Best practice is to leave share wide-open (Authenticated Users : Full Control) and do all real access control on NTFS, because NTFS is the only layer that always applies.

What’s next

Part 2 covered the layer-stacking rules. Part 3 zooms into the NTFS layer itself: when you click Advanced on the Security tab, you get 14 fine-grained property-level permissions, most of which most admins never use. Understanding NTFS Advanced Permissions walks every entry, explains what each one does, and shows why the “Apply to” scope dropdown is the most-misread control in the Windows ACL dialog.