Share vs NTFS & Access Troubleshooting

Real-world analogy

What is it?

Share and NTFS permissions are two independent access gates. Enterprise file access respects both. Juniors who can explain and debug this layer cleanly are immediately more senior than juniors who cannot.

Real-world relevance

A new hire in Finance can open \\fs01\Finance but cannot edit a specific subfolder. Junior checks share → OK. NTFS → discovers a Deny ACE on that subfolder targeting a legacy group the user is still in. Removes legacy group from user → access normalizes.

Key points

• Share permission — the parking gate — Applies only when accessing the folder over the network (\\server\share). Simple (Read, Change, Full Control). Modern best practice: give Authenticated Users ‘Change’ at the share level and rely on NTFS for real control.
• NTFS permission — the office door — Applies on the file system itself, both locally and over the network. Granular (Read, Read & Execute, Modify, Full Control, plus special). Real access control lives here.
• Effective access — intersection wins — Final permission = most restrictive of share AND NTFS. If share says Read and NTFS says Modify, the user gets Read. If NTFS says Deny, deny wins everything.
• Deny > Allow — An explicit Deny beats any Allow. Use Deny sparingly — overusing it creates surprises. Prefer to NOT grant rather than granting and then denying.
• Inheritance — Child folders inherit parent permissions by default. Breaking inheritance creates independent ACLs — useful for restricted subfolders, but documentation is mandatory or future admins will never understand the design.
• Group-based permissions, always — Grant permission to groups, never individual users. Movers and leavers become group-membership changes — not re-ACLing every folder. This is not optional in mature shops.
• Effective Access tool — Right-click folder → Properties → Security → Advanced → Effective Access. Enter a user and see exactly what permissions evaluate to. Faster than thinking through every group and deny.
• Common access-denied causes — (1) Group membership not replicated yet, (2) logon token still cached — user must log off/on, (3) Deny ACE somewhere, (4) share permissions stricter than NTFS, (5) DFS/path problem, (6) file lock, (7) offline files cache.

Code example

// Access-denied troubleshooting order

1) Confirm identity
   whoami
   whoami /groups    # which groups are effective for THIS token?

2) If groups changed recently
   Log off / log on (or reboot) to refresh the Kerberos token.

3) Check share permissions
   \\server\share  -> right-click -> Properties -> Sharing -> Advanced Sharing
   -> Permissions

4) Check NTFS permissions
   Folder -> Properties -> Security
   -> Advanced -> Effective Access -> enter user/group

5) Look for Deny ACEs
   Deny beats Allow. Remove the group causing the deny
   rather than granting individual user permissions.

6) Confirm the path
   Correct server? Correct share? DFS referral sane?
   net use \\server\share  (or) dfsutil

Line-by-line walkthrough

1. 1. Access-denied triage
2. 2. Step 1 — confirm identity
3. 3. whoami for login check
4. 4. whoami /groups for token view
5. 5. Blank separator
6. 6. Step 2 — token refresh after group change
7. 7. Blank separator
8. 8. Step 3 — inspect share permissions
9. 9. Path and path to share permissions
10. 10. Blank separator
11. 11. Step 4 — inspect NTFS permissions
12. 12. Use the Effective Access tool
13. 13. Blank separator
14. 14. Step 5 — hunt Deny ACEs
15. 15. Prefer group redesign over user-level Allows
16. 16. Blank separator
17. 17. Step 6 — confirm the path
18. 18. Validate server and share and DFS referral

Spot the bug

User Alice is in 'G-HR' group with Modify NTFS on \\fs01\HR.
She can read but not write.
Admin keeps adding 'Alice' directly with Full Control; it still doesn’t work.

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• Share vs NTFS permissions (Microsoft Learn)
• Effective Access tool (Microsoft Learn)
• NTFS vs Share permissions explained (John Savill)