Every Windows administrator eventually hits the wall where “I granted Full Control but the app still cannot read the file” or “the share works but the website 403s.” The usual cause is a misunderstanding of the two independent permission layers on a Windows Server: share permissions applied at the SMB layer, and NTFS ACLs stored on the volume. They are not interchangeable, and the effective permission is always the most restrictive combination of both.
Where each layer lives
Share permissions are evaluated only when a client connects through a network share such as \\server\data. They are stored with the share definition, not with the files. NTFS permissions live in the access control list on the volume itself, which means they apply to every path of access: RDP logons, local service accounts, IIS application pools, scheduled tasks, and SMB connections alike.
Because the two layers are evaluated in sequence, a client must pass both. The effective permission is the intersection:
| Share permission | NTFS permission | Effective permission |
|---|---|---|
| Everyone: Full Control | Users: Read | Read |
| Everyone: Full Control | Users: Modify | Modify |
| Everyone: Read | Users: Full Control | Read |
| Everyone: Full Control | Users: Full Control | Full Control |
Which layer should carry your rules?
For a web server or any single-purpose box, the rule of thumb is: set the share to Everyone (or Authenticated Users) Full Control and do all real access control in NTFS. Three reasons. First, NTFS ACLs follow the files no matter how they are accessed, so a change applies to IIS, RDP users and SMB clients consistently. Second, NTFS supports inheritance, granular rights (read, write, execute, delete subfolders) and per-user ACEs; share permissions offer only Read/Change/Full Control. Third, NTFS is where tools like icacls and the Effective Access tab already look, so troubleshooting stays in one place.
Share permissions matter in the opposite scenario: when the volume is FAT or exFAT (no NTFS ACLs exist), when you want to hide a folder from everyone except a specific group at the SMB layer, or when you are sharing a NAS volume where the underlying file system ACLs are managed elsewhere.
Worked example: an IIS site folder
Take a site at D:\wwwroot\contoso served by app pool identity IIS APPPOOL\contoso. Create the share with full share-level access, then restrict at the NTFS layer:
New-SmbShare -Name "contoso-www" -Path "D:\wwwroot\contoso" -FullAccess "Everyone"
icacls "D:\wwwroot\contoso" /grant "IIS APPPOOL\contoso:(OI)(CI)(RX)"
icacls "D:\wwwroot\contoso" /grant "CONTOSO\webadmins:(OI)(CI)(M)"
icacls "D:\wwwroot\contoso" /grant "CONTOSO\uploaders:(OI)(CI)(WD,AD)"The (OI)(CI) flags make the ACE inherited by files and subfolders; (RX) is read-and-execute, (M) is modify, and (WD,AD) is write-data plus append-data for an upload directory. Any client connecting through \\server\contoso-www still has to pass the NTFS ACL, so the permissive share grants nothing by itself.
Verify with Effective Access, not guesswork
The Effective Access tab (right-click the folder, Properties → Security → Advanced → Effective Access) computes the real NTFS result for a user or group, including inherited ACEs and deny entries. It does not show the share layer, so combine it with a quick share check: Get-SmbShare lists the shares and their permission sets, and icacls "D:\wwwroot\contoso" dumps the raw ACLs.
When a client reports access denied, work the layers in order: can they reach the share at all (net use), does a share-level allow exist, does the NTFS ACL allow the action, and is a Deny ACE lurking at either layer? Nine times out of ten the answer is an inherited NTFS deny or a share set to Read that someone forgot about.
Common traps
- Deny beats allow across layers. A Deny ACE at the share level blocks access even when NTFS allows it, and it is applied to everyone on that path. Prefer NTFS-level deny or, better, no ACE at all.
- Multiple shares over one folder. Each share is evaluated separately. Two shares on the same directory can end up with different effective permissions for the same user.
- Admin shares are special.
C$andD$are only reachable by Administrators and Backup Operators, and they still enforce NTFS ACLs. Do not “fix” a permission problem by handing outC$access. - Copy vs. move. Copying a file inherits the destination folder ACLs; moving within the same volume keeps the original ACLs; moving across volumes behaves like copy-and-delete and inherits the destination. This trips up deployments that copy a hardened folder and wonder why permissions changed.
- IIS_IUSRS is a blunt instrument. It grants every application pool on the machine. One pool per site with its own identity keeps a compromise from spreading.
- FAT/exFAT data drives. If a data disk is not NTFS, share permissions are the only protection it has – convert it or accept the risk.
A quick decision checklist
- One share per site or data folder, named after its purpose.
- Share level: Everyone Full Control (or Authenticated Users Full Control if the folder is domain-adjacent).
- NTFS level: least privilege per identity, verified with
icacls /verifyand the Effective Access tab. - Never grant share-level permissions to individuals; manage people in NTFS groups.
- Document the intended effective permission for each folder in your runbook.
Mastering the two layers removes a whole class of “works locally, fails over the network” incidents. While you are planning the folder layout, it is also worth checking the storage and admin-access details in the feature checklist on our site, and comparing providers on the Windows VPS comparison table on our site if you are still shopping for the box itself.
