Few Windows fundamentals cause as much confusion as the difference between NTFS permissions and share permissions. They stack, they’re evaluated differently, and getting them mixed up is a classic cause of “I gave them Full Control but they still can’t write to the folder” tickets.
Two Separate Permission Systems
Share permissions apply only when a folder is accessed over the network via its share (\\server\sharename) — they’re coarse-grained (Read, Change, Full Control) and set on the Sharing tab. NTFS permissions apply to the actual filesystem object, regardless of how it’s accessed (locally or over the network), and are far more granular.
The Rule That Matters: Most Restrictive Wins
When a folder is accessed over the network, both permission sets apply, and the more restrictive of the two wins. If a share permission grants Read but NTFS grants Full Control, the effective access is Read. This is the single most common cause of unexpected access denials.
Checking Effective Permissions
# View NTFS ACLs on a folder
Get-Acl "D:\Shared\Reports" | Format-List
# View share-level permissions
Get-SmbShareAccess -Name "Reports"
# Grant a user Modify rights at the NTFS level
$acl = Get-Acl "D:\Shared\Reports"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"CORP\jsmith", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.SetAccessRule($rule)
Set-Acl "D:\Shared\Reports" $acl
Best Practice
Set share permissions to Everyone: Full Control (or Authenticated Users: Change) and do all your actual access control at the NTFS level. This avoids the “which layer is blocking this” debugging headache entirely, since there’s effectively only one permission system to reason about afterward.