Share permissions control who can reach a shared folder over the network and offer three levels: Read, Change, and Full Control. They apply only to network access and cover the entire share as a single unit. NTFS permissions control access to the files and folders themselves, apply to local and network access alike, offer thirteen granular rights with Allow and Deny entries, and inherit down the folder tree. When a user connects through a share, Windows evaluates both layers and grants the more restrictive result.
Almost every "I have permission but still can't save the file" ticket on a Windows file server comes down to the interaction between these two layers. This guide explains what each one does, how they combine, the setup most administrators settle on, and the mistakes that generate the tickets. If you need a refresher on the NTFS side first, start with our NTFS permissions overview.
Side-by-Side Comparison
| Share permissions | NTFS permissions | |
|---|---|---|
| Applies to | Network access through the share (SMB) only | All access: local logon, network, scripts, services, backups |
| Scope | The whole share as one unit; every file and subfolder gets the same setting | Each file and folder individually, with inheritance from parent folders |
| Access levels | Three: Read, Change, Full Control | Six basic rights (Full Control, Modify, Read & Execute, List Folder Contents, Read, Write) built from thirteen advanced rights |
| Allow and Deny | Both, but rarely used with Deny | Both; explicit Deny overrides Allow |
| Inheritance | None | Yes, from parent folder to children, and can be blocked per folder |
| Where it is stored | Server registry (LanmanServer\Shares\Security) | Security descriptor on each file and folder on the NTFS volume |
| Survives a copy or restore | No; re-creating a share resets it | Yes when copied with security intact (robocopy /SEC, backup restore) |
| Default when created | Everyone: Read | Inherited from the parent folder |
| Works on FAT/exFAT volumes | Yes (the only protection available there) | No; NTFS or ReFS only |
| Set in | Advanced Sharing dialog, Server Manager, net share, Grant-SmbShareAccess | Security tab, icacls, Set-Acl, Group Policy file system settings |
| Best used for | A wide gate that lets authenticated users reach the share | The actual access control decisions |
Share Permissions Explained
A share is a folder the Server service exposes over SMB under a name such as
\\FileServer01\Finance. Share permissions are the access control list attached
to that share name. They are checked once, when a user's session connects to the share,
and they apply uniformly to everything beneath it. There is no way to give one subfolder a
different share permission from its siblings; that granularity belongs to NTFS.
| Share level | Allows |
|---|---|
| Read | List folders, open and read files, run programs |
| Change | Everything in Read, plus create, modify, and delete files and folders |
| Full Control | Everything in Change, plus change NTFS permissions and take ownership through the share |
Three details about share permissions cause most of the confusion:
- They are invisible to local users. An administrator logged on to the server, a scheduled task, a backup agent, or an application reading the disk path directly never touches share permissions.
- They live in the registry, not on the folder. Move the folder to a new server or restore it from backup and the share permissions do not come with it. When the share is re-created, Windows applies the default of Everyone with Read.
- They do not inherit and cannot be scoped. One setting per share, full stop. Nested shares (a share inside a share) each carry their own permissions, and the user gets whichever share path they connected through.
Two share-level features are worth knowing even if you keep share permissions wide. Access-Based Enumeration hides folders a user cannot open, based on their NTFS permissions, and is enabled per share. Offline caching settings are also per share. Neither changes what a user can do, only what they see.
NTFS Permissions Explained
NTFS permissions are stored with each file and folder in its security descriptor, so they travel with the data and apply no matter how it is reached. Each entry names a user or group, an Allow or Deny type, a set of rights, and inheritance flags that control whether the entry flows to subfolders and files. The six basic rights you see in the Security tab are bundles of thirteen advanced rights, from Traverse Folder and Read Attributes up to Change Permissions and Take Ownership.
The rules that matter when comparing with share permissions:
- Permissions accumulate across groups. A user in a Read group and a Modify group gets Modify.
- Deny beats Allow. One explicit Deny entry removes that right regardless of how many Allow entries grant it.
- Explicit beats inherited. An entry set directly on a folder outranks one inherited from a parent, which is how an explicit Allow can override an inherited Deny.
- Owners always win. The owner of a file can change its permissions even when the ACL denies them access.
The NTFS permissions overview covers each right and the inheritance model in detail, and the best practices guide covers how to structure groups and folders so the rules stay manageable.
How Share and NTFS Permissions Combine
When a user opens \\FileServer01\Finance\Budgets\2026.xlsx, Windows makes two
independent decisions and then takes the stricter one:
- Share check. Collect every share permission entry that applies to the user and their groups. Allows accumulate; any Deny removes that level. The result is Read, Change, Full Control, or nothing.
- NTFS check. Collect every NTFS entry on the file (explicit and inherited) that applies to the user and their groups. Allows accumulate, Deny wins, explicit outranks inherited. The result is a set of NTFS rights.
- Intersection. The user's effective access is whatever both checks allow. Share Change and NTFS Full Control yields Modify-level access; share Full Control and NTFS Read yields Read.
The rule in one line: within each layer, permissions are cumulative and Deny wins; between the two layers, the most restrictive result wins. Share permissions can never widen what NTFS allows, and NTFS can never widen what the share allows.
The same user logged on to the file server directly skips step one entirely, which is why access can look different locally and over the network.
Worked Examples
| Share permission | NTFS permission | Effective over the network | Effective locally |
|---|---|---|---|
| Everyone: Read | Finance-RW: Modify | Read | Modify |
| Authenticated Users: Full Control | Finance-RO: Read & Execute | Read & Execute | Read & Execute |
| Authenticated Users: Change | Finance-RW: Full Control | Modify (no permission changes) | Full Control |
| Finance-RW: Full Control | Finance-RW: Modify, Contractors: Deny Write (user is in both) | Read & Execute | Read & Execute |
| Authenticated Users: Full Control | No entry for the user or their groups | Nothing | Nothing |
| No entry for the user or their groups | Domain Users: Modify | Nothing | Modify |
| Domain Users: Read, Finance-RW: Change (user is in both) | Finance-RW: Modify | Modify | Modify |
The first row is the classic help-desk case: the folder was shared with the default Everyone Read, NTFS was set up correctly, and the users can edit files from the server console but not from their desktops. The last row shows share permissions accumulating across groups the same way NTFS permissions do.
Which One Should You Use?
Use both, but let NTFS make the decisions. The setup that most administrators and Microsoft guidance converge on:
- Share permissions: Authenticated Users with Full Control (or Change if you want to prevent permission edits through the share). Remove the Everyone entry.
- NTFS permissions: Domain local groups with the specific rights each role needs, assigned near the top of the tree and inherited downward, following the AGDLP model.
The reasons to keep the real control in NTFS:
- One place to manage. Every access decision is on the folder, visible in one Security tab, exported by one report.
- Consistent locally and remotely. Administrators, services, and backup jobs see the same rules as network users.
- Granular and inheritable. Different subfolders can have different rules; share permissions cannot express that at all.
- Survives migration. NTFS permissions travel with the data. Share permissions have to be re-created and are easy to forget.
- Auditable. NTFS supports auditing entries (SACLs) and effective access calculation; share permissions do not.
Why not Everyone Full Control at the share level? It works, and older guidance recommended it, but Everyone includes anonymous and guest sessions on servers where those are enabled. Authenticated Users gives the same practical result while excluding unauthenticated connections. Full Control at the share level is safe only because NTFS is doing the restricting; see Everyone Full Control security risks for what happens when it is set on the NTFS side as well.
The one case for restrictive share permissions is when you want a folder editable locally but read-only over the network, for example a share that publishes build output or reference documents that only a server-side process should change. Setting the share to Read enforces that without touching NTFS.
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| Users can edit on the server but not from their PCs | Share left at the default Everyone Read | Raise the share to Authenticated Users Change or Full Control |
| Everyone can read sensitive data across the network | Share and NTFS both grant Everyone; nobody restricted the NTFS side | Replace Everyone with role groups in NTFS; keep the share wide but not Everyone |
| Permissions vanished after a server migration | NTFS copied with the data, share permissions left behind in the old registry | Document shares before migrating; use Get-SmbShareAccess exports or net share output as the record |
| One user is denied despite being in the right group | A Deny entry at either layer, or the user is also in a group that carries a Deny | Trace both layers for every group the user belongs to, including nested groups |
| Different results through two share paths | Nested shares with different permissions pointing at overlapping folders | Consolidate to one share per top-level folder; audit for nested shares |
| Administrator cannot change permissions through the share | Share set to Change rather than Full Control | Grant Full Control at the share to the admin group, or change permissions locally |
| Access works, then fails after group changes | Kerberos ticket or SMB session still carries the old group list | Have the user log off and on, or wait for the ticket to refresh |
How to View Both Layers
Because the two layers live in different places, checking a user's real access means looking at both. On a single server:
# share permissions for every share on this server
Get-SmbShare | Get-SmbShareAccess | Format-Table Name, AccountName, AccessControlType, AccessRight -AutoSize
# NTFS permissions on the folder behind a share
(Get-Acl -Path (Get-SmbShare -Name "Finance").Path).Access |
Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited -AutoSizeOur Get-Acl cheat sheet covers the NTFS side in depth, including recursion, filtering, and export. The Windows Effective Access tab is useful but incomplete: it evaluates NTFS only, so it reports what a local user could do, not what a network user will get.
Across a whole environment the manual approach does not scale, because share permissions have to be collected per server, NTFS permissions per folder, and group membership from Active Directory, and then reconciled. Permissions Reporter collects all three in one scan: the share permissions report lists every share and its share-level entries, the folder and file reports cover NTFS with nested group expansion, and the share security metrics dashboard flags shares open to Everyone. The Basic edition is free.
Related Resources
- NTFS Permissions Overview - Every right, inheritance, and the Allow and Deny model
- Share Permissions FAQ - Troubleshooting network access problems step by step
- NTFS Permissions Best Practices - Group design and folder structure that keep both layers simple
- Everyone Full Control - Finding and fixing the most common share exposure
- View Folder Permissions with PowerShell - Get-Acl cheat sheet
- Set Folder Permissions with PowerShell - Set-Acl cheat sheet
- Auditing NTFS Permissions - Building a repeatable audit process