Why Windows 11 24H2 may fail to access an old NAS: the new SMB signing baseline
Windows 11 24H2 requires SMB signing by default. Older NAS appliances, Samba releases and incomplete implementations can fail authentication or negotiation.
1. Conclusion and scope
SMB signing protects messages from in-transit modification. When Windows 11 24H2 raises the default security baseline, some older devices do not suddenly have a password problem; they cannot complete the required signing negotiation, or they advertise support but implement it incorrectly.
This issue involves SMB, file sharing, NAS, authentication and permission security. Separate protocol, name resolution, account and storage causes.
2. Risk signals that deserve priority
- The same NAS works from an older Windows build, but 24H2 shows 0x80070035, repeated credential prompts or negotiation failure.
- Access differs between IP address and host name, or the share connects but directory browsing and small-file operations become slow.
3. Pre-change assessment checklist
- Confirm client build, cumulative update, domain policy and SMB client signing requirements.
- Record NAS firmware, Samba version, SMB2/3, signing, encryption and account-authentication support.
- Separate guest access, NTLM, Kerberos, name resolution and signing; ping is not a sufficient test.
- Use event logs and PowerShell to inspect dialect, signing state and the exact failure path.
Get-SmbClientConfiguration | Select RequireSecuritySignature,EnableSecuritySignature
Get-SmbConnection | Select ServerName,ShareName,Dialect,Signed,Encrypted
Get-WinEvent -LogName Microsoft-Windows-SMBClient/Connectivity -MaxEvents 30corp.example, 192.0.2.0/24 and 203.0.113.0/24 are documentation-only examples. Replace them only after the actual environment values have been verified.
4. Recommended implementation sequence
- Upgrade NAS firmware or Samba and enable supported SMB2/3, authenticated access and signing.
- Use the correct DNS name and SPN rather than permanently connecting by IP and bypassing Kerberos.
- If a temporary exception is unavoidable, scope it to named devices, subnets and an expiry date, with documented risk.
- Move critical shares to a supported file server or NAS instead of treating disabled signing as a permanent solution.
5. Validation, rollback and common mistakes
- Windows 11 24H2, older clients and the server all access the share reliably.
- Read, write, rename, delete, large-file and high-file-count operations all pass.
- Logs no longer report signing failures, authentication downgrade or insecure guest access.
Common mistakes
- Disabling SMB signing across the domain.
- Treating signing, encryption and guest access as one setting.
- Testing only whether the share opens and ignoring performance and write permissions.
Official references
Frequently asked questions
Will disabling signing restore access?
It may restore some legacy devices, but reduces security and should only be a short, controlled diagnostic step.
Does SMB signing always cause a major slowdown?
Usually not on modern hardware; old CPUs, legacy Samba and small-file workloads should be measured.
Need an assessment based on the actual environment?
Provide versions, topology, complete errors, event-log timestamps, scope of impact, recent changes and actions already taken. We will first determine risk, service boundary and rollback, then confirm the implementation scope.
