SMB Hardening: Fix ‘Access Denied’ Without Turning SMB1 Back On

What “Access Denied” really means (it’s not one problem)

SMB is a stack of decisions. “Access Denied” is the user-facing summary when any of these decisions goes against you:

• Protocol negotiation: client and server agree on SMB dialects (SMB2/SMB3) and capabilities (signing, encryption, multichannel). If they can’t, you might see “Access Denied,” “The specified network name is no longer available,” or silent fallback behavior depending on the client.
• Authentication: the client proves identity using Kerberos, NTLMv2, or local accounts. Failures here can show up as access denied, bad password prompts, or “Logon failure.”
• Authorization: once authenticated, the token gets checked against share permissions and filesystem ACLs. This is the classic “you are you, but you still can’t come in.”
• Policy and hardening settings: server requires SMB signing; client doesn’t do it. Server requires encryption; share isn’t configured; client is too old. Domain policy forbids NTLM. These look like access denied because the server is refusing to proceed.
• Name resolution / SPN targeting: Kerberos is picky. Wrong hostname, alias without SPN, or time skew can lead to auth fallback or outright refusal.

Here’s the operationally useful mindset: “Access Denied” is a classification problem. You’re not “fixing SMB.” You’re finding which gate is shutting.

Interesting facts and historical context (short, useful)

1. SMB started as a DOS-era file sharing protocol and later became “CIFS” in the Windows NT/2000 timeframe—same family, different branding and capability sets.
2. SMB2 (Vista/Server 2008) was a major rewrite that reduced chatty behavior and improved performance over high-latency links.
3. SMB3 (Windows 8/Server 2012) introduced encryption at the protocol layer—no VPN required to get on-the-wire confidentiality.
4. SMB signing existed long before most orgs used it; it’s integrity, not encryption, and it’s often enforced by domain policy for good reasons.
5. The “SMB1 is legacy” push accelerated after major worms exploited SMB1-era weaknesses and sloppy patching habits. Security teams remember. They have long memories.
6. Samba’s job is translation: Unix permissions, Windows ACL semantics, identity mapping, and network auth all meet in one daemon. Translation is where bugs and misconfigurations breed.
7. “Access Denied” can be a deliberate security posture: modern hardening prefers “fail closed” when policy mismatches (e.g., refuse NTLM) rather than silently downgrading.
8. Kerberos is time-sensitive by design; a few minutes of clock skew can turn a healthy share into an “Access Denied” factory.

Fast diagnosis playbook (first/second/third)

First: is this authentication, authorization, or protocol negotiation?

• Try listing shares anonymously and authenticated: if anonymous fails but auth works, you have a guest policy change (good). If auth fails, it’s identity or policy. If listing works but opening a folder fails, it’s authorization (share ACL vs filesystem ACL).
• Check the dialect and signing state: if the client is negotiating SMB1 or failing to negotiate SMB2/3, you’re in compatibility/policy trouble, not “permissions.”

Second: validate identity mapping and group membership

• On AD/Samba member servers: if the user maps to “nobody” or an unexpected UID/GID, filesystem checks will deny even if share permissions look right.
• On Windows clients: cached credentials and “wrong user” sessions are common. One stale connection can poison all attempts to the same server name.

Third: check policy mismatches (NTLM restrictions, signing, encryption)

• Domain forbids NTLM: a Linux client using NTLM will get denied until you switch it to Kerberos (or adjust policy, which you probably shouldn’t).
• Signing required: older clients or misconfigured mounts fail.
• Encryption required: client must support SMB3 encryption and negotiate it.

Paraphrased idea, attributed: Werner Vogels has said you build reliable systems by assuming things fail and designing for it. Treat SMB auth and policy like a failure domain you can instrument, not a mystical handshake.

Practical tasks: commands, outputs, and decisions (12+)

These are the checks I run when someone pings “SMB access denied” and expects a miracle. Each task includes: command, sample output, and the decision it drives.

Task 1: Confirm the server is actually listening on 445

cr0x@server:~$ sudo ss -lntp | egrep ':445|:139'
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1223,fd=52))
LISTEN 0      128             [::]:445           [::]:*    users:(("smbd",pid=1223,fd=54))

What it means: SMB is reachable at the TCP layer. If you don’t see 445, this is not a permissions problem yet.

Decision: If 445 isn’t listening, fix the service (smbd not running, bound to wrong interface, container networking) before touching ACLs.

Task 2: Check firewall rules for 445/tcp

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 445 ip saddr 10.20.0.0/16 accept
  }
}

What it means: Only 10.20.0.0/16 can reach SMB. Everyone else will fail in interesting ways.

Decision: If clients are outside that CIDR, fix network policy. Don’t “debug SMB” while packets are being dropped on purpose.

Task 3: See which SMB dialects Samba will negotiate

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server min protocol|server max protocol'
	server min protocol = SMB2_10
	server max protocol = SMB3_11

What it means: SMB1 is already disabled. Good. This also sets expectations for older clients.

Decision: If you see SMB1 allowed, tighten it. If a critical legacy client can’t do SMB2, migrate the client; don’t weaken the server.

Task 4: Validate share definition and effective browseability

cr0x@server:~$ testparm -s 2>/dev/null
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_MEMBER_SERVER

[global]
	workgroup = EXAMPLE
	security = ADS

[finance]
	path = /srv/samba/finance
	read only = No

What it means: The share exists and points somewhere real (we’ll verify that next). “Weak crypto allowed” is not a crime, but it’s a clue about auth modes in play.

Decision: If the share isn’t present or points to the wrong path, fix that. If security mode isn’t what you think (ADS vs user), stop and re-check the design.

Task 5: Verify filesystem path, ownership, and mode bits

cr0x@server:~$ sudo ls -ld /srv/samba/finance
drwxrwx--- 3 root "EXAMPLE\\finance-rw" 4096 Jan 12 09:40 /srv/samba/finance

What it means: Mode bits allow group access, but only if identity mapping maps users into that group.

Decision: If permissions are 700 or owned by the wrong group, you’ll get access denied even with “valid users” set correctly. Fix POSIX permissions or ACLs first.

Task 6: Check SELinux/AppArmor blocking (the silent bouncer)

cr0x@server:~$ sudo getenforce
Enforcing

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

What it means: The kernel is denying smbd regardless of your Samba config. This often looks like “permissions” but isn’t.

Decision: Fix labeling (e.g., set proper context) instead of widening share permissions.

Task 7: Prove identity mapping works (AD user → UID/GID)

cr0x@server:~$ id "EXAMPLE\\alice"
uid=220110(EXAMPLE\alice) gid=220051(EXAMPLE\domain users) groups=220051(EXAMPLE\domain users),220220(EXAMPLE\finance-rw)

What it means: The user resolves and is in the expected group.

Decision: If id fails or groups are missing, fix winbind/sssd/idmap before touching ACLs. Wrong IDs equal wrong access decisions.

Task 8: Confirm the server can talk to AD and sees the domain

cr0x@server:~$ wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

What it means: The join is healthy enough for RPC trust. Not a guarantee, but a strong baseline.

Decision: If this fails, “Access Denied” may be the server failing to validate credentials. Fix domain join, DNS, time, and keytabs.

Task 9: Check Kerberos health and time (the boring culprit)

cr0x@server:~$ timedatectl | sed -n '1,8p'
Local time: Wed 2026-02-05 14:31:10 UTC
Universal time: Wed 2026-02-05 14:31:10 UTC
RTC time: Wed 2026-02-05 14:31:10
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

cr0x@server:~$ kinit alice@EXAMPLE.COM
Password for alice@EXAMPLE.COM:

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting     Expires            Service principal
02/05/26 14:31:25  02/06/26 00:31:25  krbtgt/EXAMPLE.COM@EXAMPLE.COM

What it means: Time is synced and Kerberos tickets work. If time is off, Kerberos fails and clients fall back—or fail—depending on policy.

Decision: If NTP isn’t active or kinit fails, fix time/DNS/KDC reachability. Do not start relaxing NTLM policies as a workaround.

Task 10: Reproduce from the server side with smbclient (cuts out Windows UX)

cr0x@server:~$ smbclient -m SMB3 -L //files01 -U 'EXAMPLE\alice'
Password for [EXAMPLE\alice]:
	Sharename       Type      Comment
	---------       ----      -------
	finance         Disk
	IPC$            IPC       IPC Service (Samba)
SMB1 disabled -- no workgroup available

What it means: The user can enumerate shares over SMB3. The “SMB1 disabled” line is informational and fine.

Decision: If listing fails with NT_STATUS_ACCESS_DENIED, it’s authentication/policy. If listing works but file operations fail, it’s ACLs or VFS modules.

Task 11: Attempt access to the share and a file operation

cr0x@server:~$ smbclient -m SMB3 //files01/finance -U 'EXAMPLE\alice' -c 'ls; mkdir _diag_test; rmdir _diag_test'
Password for [EXAMPLE\alice]:
  .                                   D        0  Wed Feb  5 14:22:01 2026
  ..                                  D        0  Wed Feb  5 13:59:11 2026
  budgets                             D        0  Tue Feb  4 18:04:41 2026

What it means: Directory listing and create/delete succeeded. This is not an authorization issue for this user.

Decision: If mkdir fails with ACCESS_DENIED, inspect share-level “write list” and filesystem ACLs; if ls fails, inspect execute/search permission on directories.

Task 12: Inspect Samba logs for the real reason (not the Windows dialog)

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2026/02/05 14:24:33.112233,  1] smbd/service.c:1234(make_connection_snum)
  create_connection_session_info: guest user (from session setup) not permitted to access this share (finance)
[2026/02/05 14:24:33.112544,  1] smbd/service.c:987(make_connection_snum)
  files01 (ipv4:10.20.5.44:51022) connect to service finance initially as user nobody (uid=65534, gid=65534) (pid 1422)

What it means: The client is coming in as guest/nobody. That’s why access is denied—even if “alice” typed a password somewhere.

Decision: Fix auth negotiation (NTLM/Kerberos), Windows credential manager, or Samba “map to guest” behavior. Don’t widen ACLs to let “nobody” in.

Task 13: Detect “map to guest” and guest access settings

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'map to guest|guest ok|restrict anonymous'
	map to guest = Bad User
	restrict anonymous = 2

What it means: Unknown users get mapped to guest. Combined with “restrict anonymous,” this can turn into confusing denies.

Decision: In hardened setups, prefer failing authentication rather than mapping to guest. Consider map to guest = Never unless you have a specific, controlled guest use case.

Task 14: Check Windows has a stale session to the server under a different user

cr0x@server:~$ smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
--------------------------------------------------------------------------------------------------------------------------------------------
2311    bob          domain users  10.20.5.44 (ipv4:10.20.5.44:51210)        SMB3_11           -                    partial(AES-128-CMAC)

What it means: That client already has an SMB session as bob. Windows is famous for reusing sessions per server name, then “Access Denied” happens when you expected alice.

Decision: On the client, disconnect existing mappings and reconnect with the intended identity. Server-side, don’t “fix” permissions for the wrong user.

Task 15: Validate share-level access controls (“valid users”, “write list”)

cr0x@server:~$ grep -nE '^\[finance\]|valid users|write list|read only' /etc/samba/smb.conf
42:[finance]
45:	valid users = @EXAMPLE\finance-rw
46:	read only = no

What it means: Only members of the finance-rw group can connect. That’s sane. But group resolution must work.

Decision: If you see a typo in the group name, or the domain prefix is wrong, fix it. If you want read-only access for others, create a separate group and specify it explicitly—don’t rely on everyone’s “Domain Users” membership.

Task 16: Check whether SMB signing is required and what the server is doing

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server signing|client signing'
	server signing = mandatory
	client signing = mandatory

What it means: This server demands signed SMB. Some clients/mount options won’t cope, and they’ll fail in ways that resemble access problems.

Decision: Keep signing mandatory in most corporate networks. If a client can’t do SMB signing, the client is the problem. Upgrade it or isolate it.

Short joke #1: SMB1 is like a flip phone: nostalgic, surprisingly durable, and absolutely not what you want guarding payroll.

Hardening that doesn’t break access

Stop treating SMB1 as a compatibility crutch

Re-enabling SMB1 to “fix access” is usually masking one of these:

• Old device only supports SMB1 (MFPs are repeat offenders).
• Client is misconfigured for SMB2/3 (bad mount options, broken DNS, wrong hostname).
• Auth policy mismatch (NTLM restrictions, Kerberos failure due to time or SPN).

SMB1 hides the underlying issue by changing the negotiation path. That’s not solving; that’s rerouting the fire alarm to a different speaker.

Use SMB2/3 deliberately: dialects, signing, encryption

Hardening SMB isn’t “turn on all the knobs.” It’s selecting the right knobs for your threat model and client base.

• Dialects: Set server min protocol = SMB2_10 (or higher). SMB2_10 is a pragmatic floor for modern Windows and most Linux clients.
• Signing: Keep server signing = mandatory on member servers in domain environments unless you have a measured performance reason not to. Signing prevents tampering. It also prevents some downgrade games.
• Encryption: Use SMB3 encryption for shares that cross untrusted networks or contain sensitive data. But understand the operational costs: CPU overhead, troubleshooting complexity, and client compatibility.

Make authorization boring: share ACLs + filesystem ACLs + identity mapping

The fastest way to create “Access Denied” tickets is to let share permissions and filesystem ACLs disagree. Pick a model:

• Model A (recommended): Use AD groups as the source of truth. Gate share access with valid users and enforce on disk with ACLs. Keep POSIX mode bits minimal but not misleading.
• Model B: Use POSIX groups locally (not AD) and map them carefully. Works, but it’s easy to drift across servers.

In Samba, the “translation” layer is identity mapping. If idmap is unstable, you’ll watch users randomly lose access after reboots, upgrades, or domain changes.

Don’t break Kerberos with aliases

Kerberos tickets are issued for service principals. If users connect to \\files-alias\share but your SPNs only cover files01, clients may fall back to NTLM or fail outright if NTLM is blocked. This can manifest as “Access Denied” even though the password is correct.

Keep guest access explicit, not accidental

Guest access is either a deliberate product requirement or a misconfiguration. There isn’t much middle ground. The dangerous version is “it’s guest because something else failed.” If you don’t need guest shares, set map to guest = Never, disable guest shares, and let auth failures be loud.

Three corporate mini-stories (what actually happens)

Mini-story 1: The incident caused by a wrong assumption

They migrated a file server from an aging Windows VM to a shiny Linux box with Samba. The project plan had the usual optimism: “Same share names, same permissions, cut over after hours.” The team tested with one admin account, got in, created a folder, declared victory.

Monday morning, Finance couldn’t open anything. HR could browse but not save. Engineering was fine, because their group had broad Unix permissions from a previous era. Tickets piled up with the same screenshot: “Access Denied.” The on-call engineer did what humans do under pressure: looked for the fastest lever. Somebody said, “Maybe the old server used SMB1?”

It didn’t. The wrong assumption was subtler: they assumed Windows share permissions were the whole story. On the Linux side, the directory tree had POSIX mode bits set too tight at one parent directory. Admin tests passed because admins were mapped to a privileged group. Regular users hit a “no execute/search” on an intermediate directory and got denied. Windows UI reported it as if the file didn’t like them personally.

They fixed it by aligning models: AD groups mapped correctly, filesystem ACLs applied to the full path, and they stopped using “it works for me” as a test plan. The postmortem was blunt: access control isn’t a single knob, it’s a chain. If you only test with bolt cutters, every door looks unlocked.

Mini-story 2: The optimization that backfired

A different company had performance problems on a busy share. Users complained about slow directory listings and file opens. An engineer found that SMB signing had overhead. They changed the Samba config to make signing “auto” and celebrated when synthetic benchmarks improved.

Two weeks later, security rolled out a domain policy update requiring SMB signing for certain clients and servers. Suddenly, a subset of Windows clients started failing to access the share. Not consistently. Not loudly. Just intermittent “Access Denied” and “The request is not supported,” depending on the client version and what it negotiated.

The backfire wasn’t just the config change—it was the lack of an explicit contract. When you let signing float based on negotiation, you’re outsourcing security posture to whatever the client feels like doing that day. Mix in policy enforcement and you get chaos disguised as compatibility.

They reverted to server signing = mandatory, then fixed the real performance issue: too many small files on a backing filesystem that needed tuning, plus a hot spot in antivirus scanning on the client side. The lesson landed: “optimization” that weakens correctness is just technical debt with better marketing.

Mini-story 3: The boring but correct practice that saved the day

A global org ran Samba member servers in multiple sites. Nothing fancy: AD auth, tight shares, SMB3. The boring practice: every change to SMB config required a canary test from three client types (Windows, Linux CIFS mount, and a service account using smbclient), plus log review for auth fallbacks.

One quarter, a routine OS upgrade pulled in a Samba update with slightly different defaults around NTLM and guest mapping. Most teams would have rolled it and waited for user complaints as free QA. This team ran the canary. The Linux CIFS mount started failing with “permission denied” while Windows worked.

The canary check pointed directly at the issue: the mount was using NTLM where the environment expected Kerberos, and the new Samba build was less forgiving. They updated the mount to use Kerberos properly and rotated the service account approach where needed. Users never noticed. That’s the point.

Short joke #2: The most reliable system is the one nobody mentions in the status meeting—because it refused to become “an exciting learning opportunity.”

Common mistakes: symptom → root cause → fix

1) Symptom: Windows prompts for credentials repeatedly, then “Access Denied”

Root cause: Wrong identity is being used (cached credentials), or server refuses the auth method (NTLM disabled, Kerberos failing).

Fix: Clear existing sessions to that server name, ensure correct SPN/hostname, verify Kerberos works (kinit on Linux, proper domain login on Windows), and check Samba logs for “mapped to guest” or NTLM blocks.

2) Symptom: Can list the share, but can’t open subfolders

Root cause: Missing “execute/search” permission on one directory in the path, or ACL inheritance mismatch between Windows ACLs and POSIX.

Fix: Inspect the full directory chain permissions and ACLs; don’t just look at the leaf folder. On Samba, consider consistent ACL handling (e.g., vfs objects appropriate for your design) and ensure identity mapping is stable.

3) Symptom: Linux mount -t cifs returns “Permission denied”, Windows works

Root cause: Linux mount using NTLM by default while server expects Kerberos or refuses NTLM. Or Linux client is negotiating an older dialect.

Fix: Mount with Kerberos (sec=krb5) and specify vers=3.1.1 (or at least SMB3). Ensure the machine has valid Kerberos tickets and DNS is correct.

4) Symptom: Everything broke after “disabling SMB1”

Root cause: A legacy device (scanner, NAS, old embedded OS) only supports SMB1, or relied on anonymous/guest behavior.

Fix: Replace or upgrade the device, or isolate it to a dedicated legacy server/VLAN with compensating controls. Do not re-enable SMB1 on your main file servers.

5) Symptom: Access works via \\server\share but fails via \\alias\share

Root cause: Kerberos SPN mismatch; alias not registered, leading to NTLM fallback or failure when NTLM is blocked.

Fix: Use the canonical name, register proper SPNs for the alias, or configure DFS properly. Treat name architecture as part of auth design, not cosmetics.

6) Symptom: Some users in the right AD group still get denied

Root cause: Group membership not visible due to token size issues, nested group resolution limits, or idmap inconsistencies across servers.

Fix: Reduce excessive nesting, validate identity mapping, and check effective group list on the server with id / getent group. Stabilize idmap ranges and backend.

7) Symptom: Samba logs show user becomes “nobody”

Root cause: Authentication failure mapped to guest (map to guest = Bad User), or winbind/sssd failing to resolve identity.

Fix: Disable guest mapping unless required, fix NSS resolution, fix domain join trust, and confirm wbinfo -t and id DOMAIN\\user work.

8) Symptom: “Access Denied” only for writes, reads are fine

Root cause: Share-level read only or write list mismatch; filesystem ACL denies create/delete; or an antivirus/EDR product blocks writes via SMB policy.

Fix: Confirm Samba share options and test with smbclient mkdir/rmdir; then inspect filesystem ACLs. If policies are involved, coordinate with endpoint/security teams with evidence.

Checklists / step-by-step plan

Step-by-step: fix “Access Denied” without weakening SMB

1. Prove connectivity: server listens on 445, firewall allows it for the client subnet.
2. Confirm dialect policy: SMB1 disabled; SMB2/3 enabled. Make sure client supports it.
3. Reproduce with smbclient: test share list and simple file operations using the same credentials.
4. Read server logs: identify whether the user is authenticated, mapped to guest, or failing policy.
5. Validate identity mapping: id DOMAIN\\user and group membership match expected access.
6. Check share-level rules: valid users, read only, write list, force user/force group.
7. Check filesystem ACLs end-to-end: ensure execute/search along path and correct inheritance semantics.
8. Check mandatory security knobs: signing required? encryption required? NTLM restricted?
9. Fix the mismatch, not the symptom: update client mount settings, fix SPNs, fix time sync, fix idmap, adjust ACLs.
10. Lock it in: add a canary test and log-based alerting for guest mapping/auth failures.

Hardening checklist that shouldn’t cause access incidents

• Set SMB1 off by policy (server min protocol at SMB2_10 or higher).
• Require SMB signing in domain environments unless you have a measured exception.
• Use SMB encryption for sensitive shares crossing less-trusted networks; don’t blanket-enable it without CPU budgeting.
• Prefer Kerberos for domain clients; restrict NTLM thoughtfully and test Linux/service clients.
• Keep time sync healthy on clients and servers.
• Make identity mapping stable (consistent idmap backend and ranges across servers).
• Audit guest mapping and kill accidental guest access.
• Use explicit group-based access and keep ACLs consistent across layers.
• Enable logging sufficient to distinguish auth vs ACL vs policy failures.

FAQ

1) Why does “Access Denied” happen right after disabling SMB1?

Because a client/device was quietly relying on SMB1 (or SMB1-era guest/anonymous behavior). Disabling SMB1 removed the fallback path, revealing the real incompatibility.

2) Is SMB signing the same as SMB encryption?

No. Signing protects integrity (prevents tampering). Encryption protects confidentiality (prevents eavesdropping). You can have signing without encryption, and you often should.

3) If Windows can access the share, why does Linux CIFS mount get “permission denied”?

Windows in a domain often uses Kerberos automatically. Linux mounts may default to NTLM unless configured. If the server or domain policy blocks NTLM, Linux fails while Windows works.

4) Should I set “map to guest = Bad User”?

Only if you have a well-defined guest use case. In hardened corporate environments, it’s safer to fail authentication loudly than to silently map failures to guest and create confusing denies.

5) Can SMB encryption cause “Access Denied”?

Yes, indirectly. If encryption is required and the client can’t negotiate it (older OS, old NAS firmware, misconfigured client), the session setup can fail and surface as access issues.

6) What’s the quickest way to tell if it’s ACLs vs authentication?

If smbclient -L fails for a user, it’s auth/policy. If listing works but mkdir fails, it’s authorization (share rules or filesystem ACLs). Logs confirm which.

7) Do I need to enable SMB1 for old scanners?

Prefer replacing or upgrading them. If you absolutely must support SMB1-only devices, isolate them to a dedicated legacy endpoint with tight network controls—never on your primary file servers.

8) Why does access work via server IP but not via hostname?

Because Kerberos depends on the hostname (SPN). Using an IP often forces NTLM or fails policy. Fix DNS/SPN and use proper hostnames.

9) How do I avoid future “Access Denied” storms after updates?

Run canary tests from multiple client types, monitor Samba logs for auth fallback/guest mapping, and keep your identity mapping and time sync boring and consistent.

Conclusion: next steps you can do today

If you take one operational rule from this: never “fix” Access Denied by lowering the protocol floor. Disabling SMB1 is the baseline; you troubleshoot above it, not around it.

Do these next:

1. Run the fast diagnosis playbook: determine whether you’re failing at negotiation, authentication, or authorization.
2. Use smbclient and server logs to reproduce and classify the failure—don’t argue with a Windows dialog box.
3. Stabilize identity mapping and group resolution, then align share rules with filesystem ACLs.
4. Enforce signing, apply encryption where it’s justified, and test clients before changing policy.
5. Add a canary and keep it: one Windows client, one Linux mount, one service account test. Boring saves weekends.