Windows · File Shares

SMB File Shares — Share vs NTFS Permissions

Share permissions and NTFS permissions are two separate gates on the same folder, they never add together, and the more restrictive of the two always wins.

By K Shankar R Karanth Windows

Quick idea: Every SMB file share sits behind two independent permission checks — the share permission at the network door and the NTFS permission on the folder itself — and a user’s real access is always the more restrictive of the two, never the sum.

Share Permission

Applies only when the folder is reached over the network through its share name.

NTFS Permission

Applies to the folder and files on disk regardless of whether access is local or remote.

Effective Access

The more restrictive result of the share and NTFS checks combined — never their sum.

An SMB file share is how Windows exposes a folder on the network so other machines can read and write files in it over the Server Message Block protocol. Once a folder is shared, it is reachable by a UNC path such as \\fs01\Finance, and clients connect to it directly or by mapping a drive letter to it.

SMB3 has been the effective baseline since Windows 8 and Windows Server 2012, adding encryption, multichannel, and better resilience over the older SMB1/CIFS dialect. SMB1 is disabled by default and not installed at all on Windows Server 2019 and later or Windows 10 version 1709 and later — if a legacy device still insists on SMB1, that is now an exception to actively manage, not a default to rely on.

Every shared folder is governed by two independent permission layers: the share permission, checked only for network access to that share name, and the NTFS permission, checked on the folder and files themselves no matter how they are reached. Confusing the two — or assuming generous settings on one make up for restrictive settings on the other — is the single most common cause of “why can’t this user open a file they’re supposed to have access to.”

How Share and NTFS Permissions Combine

Think of the share permission as the security guard on the building’s front door, and the NTFS permission as the lock on each office inside. Getting past the guard doesn’t unlock every office, and holding a key to an office is worthless if the guard won’t let you through the front door in the first place. A user needs to clear both checks to do anything with a file over the network.

The two permission sets are evaluated independently and then combined by taking whichever result is more restrictive. This is usually summarised as most restrictive wins: if the share grants Full Control but NTFS only grants Read, the user gets Read. If NTFS grants Full Control but the share only grants Read, the user still only gets Read. Nothing here is additive — a generous permission on one layer can never override a restrictive permission on the other.

Share Permission	NTFS Permission	Effective Access Over the Network
Full Control	Read	Read
Read	Full Control	Read
Full Control	Modify	Modify
Change	Full Control	Change
Read	No permission (not in an ACE)	No access

Key rule: The share permission only ever applies when the path is reached through its share name over the network. Someone logged on locally at the console, or reaching the same files through a different share pointed at a parent folder, is not subject to that share’s permission at all — only to NTFS.

This is also why NTFS permissions are the layer that actually protects the data. Share permissions are a network-only gate on top; NTFS permissions apply everywhere, including local logons, other shares over the same folder tree, and scheduled tasks or services reading the files directly on the server. A share permission of Read Only does nothing to stop someone with Full Control NTFS rights from modifying the file locally on the server itself.

Why Keep Two Permission Layers?

Share permissions predate the mature NTFS permission model — early Windows file sharing needed some access control even on FAT volumes that had no per-file ACLs at all, so the share itself carried the only security boundary. NTFS ACLs later became far more granular, and in most modern environments NTFS permissions do the real work.

Coarse Network Gate

A quick way to close off network access to a whole share without touching a deep NTFS ACL tree underneath.

Defence in Depth

Two independent layers mean a mistake in one ACL doesn’t automatically expose the data.

Common Practice

Most environments grant a broad share permission (often Change or Full Control to Authenticated Users) and do the real access control entirely with NTFS.

Practical rule: Set the share permission once, broadly (Authenticated Users / Everyone at Change or Full Control), and control real access exclusively through NTFS permissions on the folder tree. Maintaining two independent, granular permission sets that both need to be kept in sync is how access drifts out of alignment over time.

Installing the File Server Role

On Windows Server, file sharing works out of the box through the built-in Server service, but the File Server role service (feature name FS-FileServer) adds the management tooling — File and Storage Services in Server Manager, File Server Resource Manager, and DFS integration. On Windows client editions (Windows 10/11 Pro and Enterprise), no role installation is needed at all; File and Printer Sharing is a built-in Windows feature.

# Install the File Server role service and its management tools
Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools

# Confirm the role installed successfully
Get-WindowsFeature -Name FS-FileServer

In File Explorer, right-click the folder, choose Properties, open the Sharing tab, and click Advanced Sharing. Tick Share this folder, set the share name, and click Permissions to add the accounts and their share-level rights (Read, Change, or Full Control). This dialog only ever edits the share permission — the Security tab next to it is where NTFS permissions live, and it is a completely separate list.

From the command line, the legacy net share command still works on every supported version of Windows, and the SmbShare PowerShell module is the modern equivalent with far more control over encryption, caching, and access-based enumeration.

# Create a share with net share and grant Change to one group
net share Finance=D:\Shares\Finance /grant:"CORP\Finance Users",change /remark:"Finance department share"

# Remove a share created with net share
net share Finance /delete

# Create the same share with New-SmbShare, granting Full and Change to two groups
$Parameters = @{
    Name         = 'Finance'
    Path         = 'D:\Shares\Finance'
    FullAccess   = 'CORP\Administrators'
    ChangeAccess = 'CORP\Finance Users', 'CORP\Finance Managers'
}
New-SmbShare @Parameters

# Create an encrypted share (SMB3 encryption in transit)
New-SmbShare -Name "Payroll" -Path "D:\Shares\Payroll" -EncryptData $true -FullAccess "CORP\Payroll Team"

# List every share on the server
Get-SmbShare

# Remove a share created with New-SmbShare
Remove-SmbShare -Name "Finance"

Important: New-SmbShare‘s -FullAccess, -ChangeAccess, and -ReadAccess parameters set the share permission only, exactly like the Permissions button in Advanced Sharing. They do not touch the NTFS ACL on the underlying folder — a brand-new share created this way inherits whatever NTFS permissions the folder already has.

Setting NTFS Permissions

In File Explorer, the Security tab on the folder’s Properties dialog shows the NTFS ACL. Click Edit to add or change entries for users and groups, or Advanced to view inheritance, ownership, and the built-in Effective Access tab, which simulates what a specific user or group would actually end up with once every ACE and group membership is accounted for.

icacls is the command-line tool for NTFS ACLs and is the direct replacement for the older, deprecated cacls. In PowerShell, Get-Acl and Set-Acl do the same job as .NET security descriptor objects, which is more convenient when scripting bulk changes across many folders.

# View the current NTFS ACL on a folder
icacls D:\Shares\Finance

# Grant Modify, applying to this folder, its subfolders, and files (OI = object inherit, CI = container inherit)
icacls D:\Shares\Finance /grant "CORP\Finance Users:(OI)(CI)M" /T

# Replace (rather than add to) an account's existing explicit permissions
icacls D:\Shares\Finance /grant:r "CORP\Finance Managers:(OI)(CI)F" /T

# Remove all permissions - allow and deny - for an account
icacls D:\Shares\Finance /remove "CORP\Temp Contractor" /T

# Disable inheritance on a subfolder but keep a copy of the inherited ACEs as explicit ones
icacls D:\Shares\Finance\HR /inheritance:d

# Disable inheritance and strip out the inherited ACEs entirely, leaving only explicit ones
icacls D:\Shares\Finance\HR /inheritance:r

# Re-enable inheritance from the parent folder
icacls D:\Shares\Finance\HR /inheritance:e

# Copy an NTFS ACL from one folder to another with Get-Acl / Set-Acl
$templateAcl = Get-Acl -Path "D:\Shares\Finance"
Set-Acl -Path "D:\Shares\NewFinanceArchive" -AclObject $templateAcl

Key difference: /grant adds to an account’s existing explicit permissions on top of whatever is already there; /grant:r replaces them. Forgetting the :r when you meant to reset an entry is how folders end up with several overlapping, contradictory-looking ACEs for the same account.

Commands Cheat Sheet

The commands below cover the full lifecycle of a share: checking what is already granted, adjusting share-level access without recreating the share, and confirming SMB1 is off.

# List the share-level ACL for a share
Get-SmbShareAccess -Name "Finance"

# Grant an additional account Read at the share level, without a confirmation prompt
Grant-SmbShareAccess -Name "Finance" -AccountName "CORP\Auditors" -AccessRight Read -Force

# Remove all of an account's allow entries at the share level
Revoke-SmbShareAccess -Name "Finance" -AccountName "CORP\Temp Contractor" -Force

# Change an existing share's description or caching mode without deleting it
Set-SmbShare -Name "Finance" -Description "Finance department share" -Force

# Confirm SMB1 is disabled on the server (it should be, on any current build)
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

# Disable SMB1 if it is somehow still on
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Confirm:$false

Gotchas and Best Practices

Gotcha	Why It Bites	Recommendation
“Everyone: Full Control” on the share	People assume this makes the share wide open, then are surprised the NTFS ACL underneath is still restricting who gets in.	Set the share permission broadly once and do all real access control with NTFS.
Editing the wrong tab	The Sharing tab’s Permissions button and the Security tab are two unrelated ACLs on the same Properties dialog.	Confirm which tab you are in before changing anything; check both if access looks wrong.
Inheritance silently broken	A subfolder with `/inheritance:d` or a manually cleared inherited flag stops picking up parent ACL changes.	Use the Effective Access tab or `icacls` against the specific subfolder, not just the share root.
Local access bypasses the share permission	Share permissions only apply over the network path; local logons, RDP sessions on the server, and services reading the files locally are governed by NTFS alone.	Never rely on the share permission as the only control for data that must not be readable locally.
Group nesting hides the real effective right	A user in two groups with conflicting Allow/Deny NTFS entries can end up with an unexpected result — an explicit Deny anywhere in the chain wins over any Allow.	Use the Advanced Security Settings Effective Access tab to check the actual combined result for that user.

Troubleshooting Cheat Sheet

Symptom	Likely Cause	Fix
User can map the drive but every file shows Access Denied	Share permission is fine, but the NTFS ACL on the folder or file doesn’t include the user or their group.	Check `icacls` or the Security tab on the specific file/folder, not just the share root.
User can’t even connect to `\\server\share`	The share permission itself denies or omits the account, or the account has no logon-over-network right.	Run `Get-SmbShareAccess -Name "Finance"` and confirm the account or one of its groups is listed with at least Read.
Read-only access when Full Control was granted on one side	Most restrictive wins — the other permission layer is capping the result at Read.	Check both the share permission and the NTFS ACL; whichever is lower is what the user gets.
Permission change to a parent folder didn’t reach a subfolder	Inheritance was disabled on that subfolder at some point, so it stopped inheriting from the parent.	Run `icacls <subfolder> /inheritance:e` to re-enable inheritance from the parent.
Access works locally on the server but not over the network	NTFS permissions are fine, but the share permission is missing or restrictive for that account.	Add or adjust the account with `Grant-SmbShareAccess` at the share level.
Legacy device can’t connect at all	The device only speaks SMB1, which is disabled by default on current Windows Server and Windows 10/11 builds.	Do not re-enable SMB1 server-wide; isolate or replace the legacy device instead.

Final Thoughts

Share and NTFS permissions get confused constantly because they look like the same kind of setting — a list of accounts with Read, Change, or Full Control next to them — sitting one tab apart in the same dialog. They aren’t the same setting. One is a network-only gate on the share name, the other is the actual protection on the files, and the two never add up in the user’s favour.

The practical pattern that avoids most of this confusion is to stop treating share permissions as a serious access-control tool at all: grant them broadly once, and do all the real work with NTFS, where inheritance, granularity, and the Effective Access tab give you the tools to actually reason about who can touch what.

The mechanics behind that inheritance and Effective Access calculation — including exactly why an explicit allow can override an inherited deny — are covered in more depth in NTFS Permissions and ACLs.

Key takeaway: If access to a shared folder looks wrong, check both permission layers before touching either one — the user’s real access is always the more restrictive of the share permission and the NTFS permission, never their sum.

Next in this series

If “Access Is Denied” is the error you’re actually chasing right now rather than the theory behind it, the “Access Is Denied” Mapping a Drive Over SMB troubleshooting post walks through diagnosing that specific failure end to end.

What Is an SMB File Share?