SMB Share ‘Access Denied’: The One Permission Everyone Misses

The one permission everyone misses: share-level rights

SMB access is the intersection of multiple gates. You don’t “have access” because one ACL says you do; you have access because every gate says you do.

Windows: Share permissions + NTFS permissions

On Windows file servers, there are two separate permission systems involved when you access a share:

• Share permissions (the share object). Historically configured as Read/Change/Full Control on the share.
• NTFS permissions (the filesystem ACL) on the underlying folder tree.

Effective access is the most restrictive combination. If NTFS grants Modify but the share grants only Read, you get Read. If the share denies a group, you get denied even if NTFS is wide open.

Samba: share definition constraints + filesystem permissions

On Samba, the idea is the same even if the knobs look different. Your access is constrained by:

• Samba share-level controls: valid users, write list, read list, hosts allow, veto files, force user, guest ok, and friends.
• Filesystem permissions: POSIX mode bits, ACLs (NFSv4 ACLs on ZFS, POSIX ACLs on ext4/xfs), plus any MAC layer (SELinux/AppArmor).
• Identity mapping: if Samba thinks you’re one UID/GID and the filesystem expects another, it’s denial-by-math.

If you want a one-line operational truth: SMB is never “just permissions.” It’s permissions plus translation.

Joke #1: SMB permissions are like airport security: you can be cleared at the gate and still get stopped because you forgot you’re carrying a water bottle called “Deny ACE.”

A mental model that stops the ping-pong

When someone says “I have permissions,” they usually mean “I’m in the AD group.” When someone else says “the ACL is correct,” they mean “the filesystem looks fine.” Both can be true. You still get denied.

Think in gates, not in lists

For SMB access, walk the gates in this order:

1. Name resolution and reachability: are you hitting the server you think you’re hitting?
2. Authentication: did you log in as the identity you think you used?
3. Authorization at the share: does the share object allow you?
4. Authorization at the filesystem: does the directory ACL allow you (and traverse rights along the path)?
5. Policy layers: encryption/signing requirements, SMB dialect mismatch, “Network access: Sharing and security model”, Samba “map to guest”, etc.
6. Token/credential caching: Windows caches SMB credentials aggressively. So do humans.

Why share permissions matter more than they “should”

In many mature Windows environments, admins set share permissions to “Everyone: Full Control” and rely on NTFS ACLs. That’s a defensible standard: one control plane (NTFS), less drift, less confusion. But the moment someone deviates—often during a “quick hardening” or a “temporary restriction”—you get a second control plane and the drift begins.

In Samba environments, share-level gates are unavoidable: valid users and friends are the share permission model. If a share definition restricts access, you can chmod 777 until your fingers hurt; it won’t matter.

The permission everyone misses, explicitly

The recurring failure mode is this:

• Windows: the share’s Security/Permissions tab doesn’t include the user’s group, or includes it with Read while NTFS expects Write, or contains an explicit Deny.
• Samba: the share has valid users = @somegroup but the user isn’t actually in that group as Samba sees it (idmap mismatch), or the share has read only = yes, or a write list excludes them.

Fast diagnosis playbook (first/second/third)

This is the “stop arguing and find the bottleneck” routine. Use it when you have one user failing, one user succeeding, and everyone has theories.

First: prove which server and which credentials

• Confirm the client is connecting to the right host (DFS can send you elsewhere; DNS can lie; old IPs linger).
• Confirm which username is being used (credential manager, cached sessions, implicit domain).
• Confirm the SMB session is established (or failing at auth).

Second: check share-level access (the forgotten gate)

• Windows: Get-SmbShareAccess on the server for the share.
• Samba: inspect smb.conf and runtime view (testparm -s), check valid users, write list, read list, hosts allow.

Third: check filesystem-level access and traverse

• Windows: NTFS ACLs plus share path traversal. Use icacls and effective access checks.
• Linux: POSIX mode bits, ACLs (getfacl), plus SELinux denials (ausearch).

Stop condition

As soon as you find a gate that denies, stop. Don’t “fix” three other things “just in case.” That’s how you turn a permission bug into an incident.

Interesting facts & history (why this got weird)

1. SMB started life at IBM in the 1980s, then Microsoft adopted and extended it. That lineage is why you still find old concepts baked into modern Windows sharing behavior.
2. Share permissions predate NTFS ACLs as most people understand them today. Share-level controls were an early network gate; NTFS evolved into the finer-grained local security model.
3. “Everyone” changed meaning over time. In older Windows, “Everyone” could include anonymous; later hardening separated “Everyone” from “Anonymous Logon,” but old assumptions linger in scripts and tribal knowledge.
4. SMB1’s long deprecation arc created “compatibility hardening” habits: admins toggled settings to fix old devices, sometimes accidentally breaking modern auth or tightening access unexpectedly.
5. DFS can mask the real target. Users say “the share is down,” but they’re hitting a referral to a different server with different share permissions.
6. Samba’s idmap is a world of pain because it bridges Windows SIDs to Unix UIDs/GIDs. A perfectly fine AD group can become meaningless if the mapping backend changes or ranges overlap.
7. Windows access tokens are snapshots. Group membership changes don’t always apply until a new logon/token is created, which makes “I just added them to the group” a trap.
8. Explicit Deny ACEs win (generally). They exist for a reason, but they’re also the fastest way to create “it works for admins but not for finance” puzzles.
9. SMB signing/encryption requirements can look like access problems. Some clients fail with misleading errors when policy blocks the connection before authorization even happens.

Hands-on tasks: commands, outputs, decisions (12+)

These are real operational moves. Run them from the right place (client vs server) and read the output like it’s telling you a story. Because it is.

Task 1 (Windows client): list current SMB connections

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Format-Table -AutoSize"
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ----------- ------- --------
FS01       Finance$  CONTOSO\jdoe          3.1.1   4

What it means: You are already connected to FS01 as CONTOSO\jdoe to share Finance$. If the user “tested” with different creds, they might be lying unintentionally.

Decision: If the username is wrong, disconnect and reconnect explicitly with the intended account (see Task 2).

Task 2 (Windows client): clear cached SMB session to a server

cr0x@server:~$ powershell -NoProfile -Command "net use \\FS01\Finance$ /delete"
\\FS01\Finance$ was deleted successfully.

What it means: That SMB session is gone. Now your next access attempt will prompt/re-negotiate credentials.

Decision: Re-test access immediately. If it now works, your “permissions” problem was credential caching.

Task 3 (Windows client): confirm DNS is pointing you where you think

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS01 | Select-Object -First 3 | Format-Table -AutoSize"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
FS01  A   60  Answer  10.10.5.21

What it means: The client resolves FS01 to 10.10.5.21.

Decision: If this IP is not your intended file server (common in migrations), you’re debugging the wrong box. Fix DNS/DFS before touching ACLs.

Task 4 (Windows server): inspect share-level permissions (the missing gate)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShareAccess -Name Finance$ | Format-Table -AutoSize"
Name     ScopeName AccountName        AccessControlType AccessRight
----     --------- -----------        ----------------- -----------
Finance$ *         BUILTIN\Administrators Allow          Full
Finance$ *         CONTOSO\FinanceRW      Allow          Change
Finance$ *         CONTOSO\FinanceRO      Allow          Read
Finance$ *         CONTOSO\Interns        Deny           Full

What it means: There is an explicit Deny for CONTOSO\Interns. If your user is in that group (directly or nested), they lose, regardless of NTFS.

Decision: Confirm group membership and remove/replace Deny with a cleaner model. Deny should be your last resort, not your first instinct.

Task 5 (Windows server): show the physical path behind a share

cr0x@server:~$ powershell -NoProfile -Command "(Get-SmbShare -Name Finance$).Path"
D:\Shares\Finance

What it means: The share points to D:\Shares\Finance.

Decision: Now you know exactly which directory ACL to inspect. No guessing, no “it’s probably this one.”

Task 6 (Windows server): inspect NTFS ACLs quickly

cr0x@server:~$ powershell -NoProfile -Command "icacls D:\Shares\Finance"
D:\Shares\Finance CONTOSO\FinanceRW:(OI)(CI)(M)
                 CONTOSO\FinanceRO:(OI)(CI)(RX)
                 BUILTIN\Administrators:(OI)(CI)(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 Successfully processed 1 files; Failed processing 0 files

What it means: At the filesystem layer, the model looks sane: RW has Modify, RO has Read/Execute.

Decision: If the user is in FinanceRW and still denied, the share-level gate (Task 4) or identity/token issues are more likely than NTFS.

Task 7 (Windows server): check effective access (spot nested group surprises)

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl D:\Shares\Finance | Select-Object -ExpandProperty Access | Select-Object -First 6 | Format-Table -AutoSize"
FileSystemRights AccessControlType IdentityReference          IsInherited InheritanceFlags PropagationFlags
---------------- ----------------- -----------------          ----------- ---------------- ---------------
Modify           Allow             CONTOSO\FinanceRW          False       ContainerInherit ObjectInherit None
ReadAndExecute   Allow             CONTOSO\FinanceRO          False       ContainerInherit ObjectInherit None
FullControl      Allow             BUILTIN\Administrators     False       ContainerInherit ObjectInherit None
FullControl      Allow             NT AUTHORITY\SYSTEM        False       ContainerInherit ObjectInherit None

What it means: You’re looking at the raw ACEs. It won’t directly compute “effective” for a specific user, but it reveals if a Deny is lurking or inheritance is broken.

Decision: If you see unexpected explicit entries or broken inheritance, fix that before touching share permissions.

Task 8 (Windows server): confirm the user’s group membership as the server sees it

cr0x@server:~$ powershell -NoProfile -Command "whoami /groups | Select-String -Pattern 'Finance|Interns' -CaseSensitive"
BUILTIN\Administrators                                 Alias            S-1-5-32-544  Enabled
CONTOSO\FinanceRW                                      Group            S-1-5-21-...   Enabled
CONTOSO\Interns                                        Group            S-1-5-21-...   Enabled

What it means: The access token includes both FinanceRW and Interns. If the share denies Interns, that Deny wins.

Decision: Remove the user from the denied group, or redesign the share permissions so you don’t need Deny at all.

Task 9 (Windows server): verify SMB server config isn’t blocking auth

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RejectUnencryptedAccess,RequireSecuritySignature,EnableSMB1Protocol | Format-List"
RejectUnencryptedAccess : True
RequireSecuritySignature : True
EnableSMB1Protocol : False

What it means: This server requires signing and rejects unencrypted access (depending on client negotiation). Some older clients or appliances may fail and report it poorly.

Decision: If the failing client is old or non-Windows, verify dialect/signing/encryption support before you chase permissions.

Task 10 (Linux client): test share listing with explicit credentials

cr0x@server:~$ smbclient -L //fs01 -U 'CONTOSO\jdoe'
Password for [CONTOSO\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance$        Disk      Finance data
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

What it means: Authentication succeeded and the server listed shares. The “SMB1 disabled” line is informational in many cases.

Decision: If listing fails with NT_STATUS_LOGON_FAILURE, you’re not at the permissions stage yet. Fix auth or realm formatting.

Task 11 (Linux client): attempt to access the share and observe the exact error

cr0x@server:~$ smbclient //fs01/Finance$ -U 'CONTOSO\jdoe' -c 'ls'
Password for [CONTOSO\jdoe]:
NT_STATUS_ACCESS_DENIED listing \*

What it means: Auth succeeded, but authorization failed. That points to share-level permissions, filesystem ACLs, or a policy layer (less commonly).

Decision: Move to server-side checks: share ACL (Windows) or valid users/write list (Samba), then filesystem ACLs.

Task 12 (Linux server running Samba): print the effective Samba config for the share

cr0x@server:~$ testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_ACTIVE_DIRECTORY_MEMBER

[Finance$]
	path = /srv/shares/finance
	read only = no
	valid users = @FINANCE_RW @FINANCE_RO
	write list = @FINANCE_RW

What it means: Only members of FINANCE_RW or FINANCE_RO can access at all. Writes are restricted to FINANCE_RW.

Decision: If the user is in AD but not recognized as in these groups on the Samba host, investigate idmap and NSS group resolution.

Task 13 (Linux server): confirm the user identity and group mapping

cr0x@server:~$ id 'jdoe'
uid=123450110(jdoe) gid=123450513(domain users) groups=123450513(domain users),123450988(finance_ro),123450999(interns)

What it means: From the Unix perspective, jdoe is in finance_ro and interns. If the share expects finance_rw, they won’t get write. If the share blocks interns via invalid users or similar, they may be denied completely.

Decision: Align Samba share config group names with what the system actually resolves, and avoid ambiguous group naming across realms.

Task 14 (Linux server): check filesystem ACLs on the share path

cr0x@server:~$ getfacl -p /srv/shares/finance | sed -n '1,25p'
# file: /srv/shares/finance
# owner: root
# group: finance_rw
user::rwx
group::rwx
group:finance_ro:r-x
mask::rwx
other::---

What it means: Filesystem permissions allow finance_ro to read, finance_rw to write, and others to get nothing.

Decision: If Samba allows but filesystem denies, fix ACLs (or force group/create mask strategies). If filesystem allows but Samba denies, fix share-level config.

Task 15 (Linux server with SELinux): check for SELinux denials affecting Samba

cr0x@server:~$ ausearch -m avc -ts recent | tail -n 5
type=AVC msg=audit(1700000000.123:456): avc:  denied  { read } for  pid=1200 comm="smbd" name="finance" dev="sda1" ino=123456 scontext=system_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

What it means: SELinux blocked smbd from reading the directory labeled default_t.

Decision: Label the directory correctly for Samba (or configure SELinux boolean/policy). Don’t chmod your way out of a MAC layer.

Task 16 (Windows server): verify share permissions didn’t drift from the standard

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Where-Object Name -like '*$' | Select-Object Name,Path | Sort-Object Name | Format-Table -AutoSize"
Name      Path
----      ----
Finance$  D:\Shares\Finance
HR$       D:\Shares\HR
Legal$    D:\Shares\Legal

What it means: You have multiple administrative-style hidden shares. Drift tends to be share-by-share, not server-wide.

Decision: Compare share ACLs across shares. If Finance$ is the only one with a Deny or custom share ACL, you’ve probably found the culprit.

Three corporate-world mini-stories

1) Incident caused by a wrong assumption: “NTFS is all that matters”

The company had a tidy file server pattern: share permissions were “Everyone: Full Control,” and NTFS did the real work. It’s a common practice. It reduces the number of moving parts, and it makes audits more straightforward because one system is authoritative.

Then a compliance-driven change landed during a busy quarter. Someone tightened share permissions “temporarily” on a particularly sensitive share. They added a Deny for a broad group that “shouldn’t” have access anyway. On paper, it looked clean: remove a big population with one rule.

On Monday morning, a senior analyst couldn’t open month-end files. Their manager escalated, then Finance escalated, then the helpdesk turned it into a “file server outage” because that’s the only category with urgency attached. Classic corporate taxonomy: if it’s broken, it’s infrastructure.

The on-call SRE checked storage health. Fine. Checked network. Fine. Checked NTFS ACL. Fine. The analyst was in the right FinanceRW group. Everyone relaxed—until someone actually looked at Get-SmbShareAccess and noticed a Deny on a nested group that included the analyst due to a legacy onboarding bundle.

The fix was simple: remove the Deny and replace it with an allow-list model on NTFS. The learning was not. The postmortem noted the real root cause: an assumption baked into the org (“share perms are irrelevant”) collided with a one-off change that nobody reviewed because it seemed “small.”

2) Optimization that backfired: “Let’s speed things up with DFS and consolidation”

A different place, different flavor of pain. They consolidated file servers and introduced DFS namespaces so users could keep using \\corp\files\... while storage moved underneath. This is normal modernization work. It’s also a great way to accidentally debug the wrong system for days.

To “optimize,” they redirected a busy share to a new backend server with faster disks and nicer monitoring. It worked for most users. For a small subgroup, access started failing intermittently with “Access Denied.” Intermittent is a strong word here; it means “nobody believes you until it happens on a screen share.”

It turned out DFS referrals were sending some clients to the new target and some to the old one based on site costing and cached referrals. The two targets had slightly different share permissions. NTFS was mirrored. Share ACLs were not. So the same path would succeed or fail based purely on which server you landed on.

The “optimization” wasn’t DFS; DFS was doing exactly what it was designed to do. The backfire was assuming share-level permissions would be “the same everywhere” without enforcing them as code. Once they standardized share ACL templates and validated them during changes, the intermittent failures vanished.

3) Boring but correct practice that saved the day: “One control plane, and test from the client”

At a healthcare org, the file services team was allergic to cleverness. They had a policy: share permissions are always permissive, NTFS is authoritative, and Deny entries require a peer review. They also required that every change ticket include a client-side test using the actual user identity, not an admin account “because it’s easier.”

One afternoon, a clinical app started failing to write reports to a share. The app team said, “Storage is full” (it wasn’t). The network team said, “SMB is down” (it wasn’t). The file services team asked for the ticket template fields: share name, path, user, client hostname, exact error, and a test using the service account.

They discovered the service account had been rotated and the new account wasn’t added to the NTFS group. Share permissions were permissive, so there was no second gate to confuse things. The ACL fix took minutes, not hours.

Nothing heroic happened. No war room. No midnight restore. The correct practice—boring, consistent, documented—made the failure obvious. That’s what reliability looks like: fewer interesting stories.

Common mistakes: symptom → root cause → fix

1) “I can access locally but not via \\server\share” → share permission denies

Symptom: User can open the folder when logged onto the server (RDP/console) but gets “Access Denied” over SMB.

Root cause: Local access uses NTFS; SMB access uses share permissions + NTFS. The share gate blocks them.

Fix: On Windows, run Get-SmbShareAccess and correct the share ACL. On Samba, review valid users/write list.

2) “Only this one user is denied” → they’re in a denied group (often nested)

Symptom: Same role, same team, one user fails. Everyone suspects “corrupt profile” or “Windows being Windows.”

Root cause: An explicit Deny applies through nested group membership, or their token includes a legacy group.

Fix: Check whoami /groups (Windows) or id (Linux). Remove the user from the denied group or eliminate the Deny entry by redesigning the allow model.

3) “It works after reboot/logoff” → stale access token or cached credentials

Symptom: You add user to a group, nothing changes, then later it magically works.

Root cause: Windows tokens are created at logon; group membership changes aren’t reflected until a new token. SMB sessions also cache credentials per server.

Fix: Log off/on (or restart the service/account session). Clear SMB sessions with net use ... /delete and retry with explicit creds.

4) “Read works, write is denied” → share set to Read or Samba write list excludes

Symptom: User can browse and open files but cannot create/rename/delete.

Root cause: Share-level is Read-only, or Samba write list doesn’t include them, or NTFS grants only RX.

Fix: Compare share access rights (Read/Change) vs NTFS Modify. On Samba, ensure read only = no and that write list matches the intended group.

5) “Intermittent access denied” → DFS referrals or multiple targets with mismatched share ACLs

Symptom: Same path sometimes works, sometimes fails, often based on location or time.

Root cause: DFS sends clients to different servers; share permissions differ between targets.

Fix: Standardize share permissions across all targets. Verify which server a client is connected to before debugging.

6) “Linux Samba share denies but filesystem looks open” → SELinux/AppArmor blocks

Symptom: Mode bits/ACLs show allow, but SMB still returns access denied.

Root cause: Mandatory Access Control denies smbd.

Fix: Inspect AVC denials and label paths correctly; don’t treat SELinux as a rumor.

7) “Everyone has access except non-domain machines” → auth model mismatch

Symptom: Domain-joined machines work; non-domain clients fail with confusing “denied” errors.

Root cause: Server requires Kerberos, signing, or specific auth policies; or Samba maps unknown users to guest and guest is blocked.

Fix: Confirm auth method; for Samba check map to guest and guest rights; on Windows check SMB server policy requirements.

Checklists / step-by-step plan

Step-by-step: diagnose one user failing to access one share

1. Identify the exact UNC path the user is using. If it’s a DFS namespace, note it.
2. From the client, list active SMB connections (Task 1). Confirm username.
3. Clear stale sessions to the target server (Task 2). Reconnect with explicit credentials.
4. Verify name resolution (Task 3). Confirm you’re hitting the correct server/IP.
5. Prove auth vs authz using smbclient (Tasks 10–11) or Windows mapping attempts. If auth fails, stop and fix auth.
6. On the server, dump share permissions (Task 4). Look for missing allows and explicit denies.
7. Confirm share path (Task 5). Make sure you’re checking the right folder.
8. Check filesystem ACLs (Task 6). Ensure correct group has Modify/Write and that inheritance makes sense.
9. Check token/group membership (Task 8 / Task 13). Confirm the server’s view, not the HR system’s view.
10. If Samba, validate runtime config (Task 12) and idmap/group resolution (Task 13).
11. If Linux, check MAC layer (Task 15) if permissions look correct but access still fails.
12. Change one thing, retest immediately, then document what gate was failing and why.

A safe standard that prevents most SMB permission incidents

• Windows: Set share permissions broadly (often “Authenticated Users: Full” or equivalent policy-approved broad allow), and enforce access with NTFS groups. Keep Deny entries rare and reviewed.
• Samba: Be explicit and consistent: define valid users and write list using a predictable group naming scheme. Avoid per-share creative exceptions unless you like pager fatigue.
• Everywhere: Treat identity mapping as production infrastructure. If you change idmap backends or ranges, you’re changing “who is who” on disk.

Operational checklist for changes (permissions, shares, migrations)

• Record the current share ACL and filesystem ACL before changes (screenshots are not a control system).
• Test with a real non-admin user plus the service account used by automation/applications.
• For DFS: test each target directly (\\server\share) and through the namespace.
• After group membership changes: ensure users refresh tokens (logoff/logon) for validation.
• Write down the intended permission model: “share permissive, NTFS restrictive” or “share restrictive, filesystem aligned.” Don’t let it be accidental.

Joke #2: The “temporary” Deny ACE has the same lifecycle as a staging database: it’s forever, just with worse documentation.

FAQ

1) What is the “one permission everyone misses”?

The share-level permission gate: Windows share permissions or Samba share definition restrictions. People obsess over NTFS/POSIX ACLs and forget the share can block access first.

2) On Windows, should I set share permissions to Everyone: Full Control?

In many enterprises, the safer modern variant is “Authenticated Users” (policy-dependent) with Full Control at the share, and then enforce real access with NTFS groups. The key is consistency: one authoritative place for restrictions.

3) Why does Deny cause so many weird bugs?

Because it’s blunt and it wins. Users accumulate group memberships over time (project groups, onboarding bundles, nested groups). One Deny can override multiple allows in ways that aren’t obvious from a quick glance.

4) I added the user to the right AD group. Why are they still denied?

They may be using cached SMB credentials, or their access token doesn’t include the new group yet. Clear SMB sessions and have them log off/on (or restart the service session for service accounts).

5) Why can an admin access the share but the user cannot?

Admins often have elevated rights, different group memberships, or bypass effects (like local admin access) that don’t reflect normal SMB authorization. Always test with the actual user identity or an equivalent test account.

6) How do I tell if the failure is authentication or authorization?

If you can list shares but can’t list directories inside the share, auth succeeded and authorization failed. Tools like smbclient make this visible: NT_STATUS_LOGON_FAILURE vs NT_STATUS_ACCESS_DENIED.

7) Can SMB signing/encryption policies look like “Access Denied”?

Yes. Depending on client and error handling, policy enforcement can surface as generic access errors. Check server configuration (and client capabilities) before rewriting ACLs.

8) On Samba, I set filesystem permissions correctly. Why is Samba still denying?

Because Samba may be restricting the share via valid users, read list, write list, or host restrictions, or mapping your user to the wrong UID/GID. Inspect testparm -s and verify id output for the user.

9) What’s the single fastest server-side command for Windows share permission issues?

Get-SmbShareAccess -Name <share>. If the intended group isn’t present with the right access, or a Deny exists, you’ve likely found the problem.

10) What quote best fits this whole mess?

Werner Vogels (paraphrased idea): everything fails eventually, so design and operate assuming failure—and make diagnosis fast.

Conclusion: next steps that actually stick

When SMB says “Access Denied,” don’t start by rewriting NTFS ACLs like you’re performing an exorcism. Prove the basics: correct server, correct identity, auth vs authz. Then check the share gate—because that’s the one everyone forgets exists.

Do this next:

1. Standardize your model: either “share permissive, filesystem restrictive” (common on Windows) or an explicit Samba share allow-list backed by consistent identity mapping.
2. Ban casual Deny entries: require peer review and a documented reason. Deny is a scalpel that people use like a shovel.
3. Turn the diagnosis playbook into muscle memory: client session check, share permissions, filesystem ACLs, identity mapping/token refresh, policy layers.
4. Automate drift detection: if you run multiple file servers or DFS targets, ensure share-level permissions are consistent and auditable.

If you do nothing else, do this: when someone says “but NTFS is correct,” reply “show me the share permissions.” Then enjoy the sudden silence in the room—the productive kind.