File share permissions not applying to subfolders? Try this fix order
Permissions on a file share look right at the root but don't propagate to subfolders. Here's the fix chain — start simple, escalate fast.
Quick fix — Reapply inheritance (30 seconds)
Most of the time, the culprit here is a subfolder that had explicit permissions set at some point. That breaks the inheritance chain. The root share looks fine, but anything below it is locked to whoever set those old permissions.
Right-click the root share folder → Properties → Security → Advanced → Enable inheritance (button at the top). Then check "Replace all child object permission entries with inheritable permission entries from this object". Hit OK. Wait a few seconds if you have a ton of files — on a large share, it might take a minute. Test access again.
If that worked, you're done. If not, move to the next step.
Moderate fix — Use icacls to reset permissions (5 minutes)
When the GUI fix doesn't stick — and it won't if there's corruption or deeply nested explicit entries — you need icacls. Open PowerShell as Administrator on the file server.
icacls "D:\Shares\Sales" /reset /t /c /qWhat this does:
/reset— replaces all ACLs with default inherited permissions/t— recurses through all subfolders/c— continues on errors (won't stop on one bad file)/q— quiet mode, no spam to console
After that, reapply the root permissions: icacls "D:\Shares\Sales" /grant "Domain Users":(OI)(CI)(RX) /t (adjust the group and rights to your needs). The (OI) means object inherit — files get it. (CI) means container inherit — folders get it. Missing either is a common mistake I see juniors make.
Test again. If users still can't access something, we go nuclear.
Advanced fix — Check DFS, shadow copies, and Group Policy (15+ minutes)
Three things can override local NTFS permissions and make you chase ghosts:
1. DFS Namespace permissions
If you're using DFS, the namespace itself can have explicit permissions that override the target share. Open DFS Management → right-click the namespace → Properties → Advanced. Look at the Security tab. If you see "Deny" entries or overly restrictive ACLs, that's your problem. Remove or adjust them. DFS permissions apply before the target share NTFS permissions.
2. Shadow Copies (VSS) locking files
On Server 2016/2019/2022, I've seen VSS snapshots hold old ACLs, and Explorer sometimes shows those instead of the live permission set. Check if shadow copies are enabled: vssadmin list shadows /for=D:. If they are, temporarily disable them for the volume (after verifying permissions are correct on the live filesystem). Run vssadmin delete shadows /for=D: /all and re-enable after testing.
3. Group Policy — Restricted Groups or File System policies
GP can override local permissions in specific scenarios. Run gpresult /h gpresult.html on the file server and look for "Security Settings" → "File System". If you see your share path in there with explicit permissions, Group Policy is forcing ACLs every 90 minutes. That'll break any manual changes. Remove the policy entry.
One last thing: if you're on a Windows Server 2012 R2 or older box, you might run into a known issue where permissions don't propagate over 1 million files. The fix is the icacls reset above, but you might need to run it in batches using Get-ChildItem with -Directory to avoid memory blowout.
$dirs = Get-ChildItem "D:\Shares\Sales" -Directory -Recurse
foreach ($dir in $dirs) {
icacls $dir.FullName /reset /c /q
}That's it. Start with the quick fix, escalate if needed. Nine times out of ten, the inheritance enable does it. The other one time, icacls or DFS is the real problem.
Was this solution helpful?