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.

Control risk before changing productionValidate first in a test environment or on one representative system, and preserve configuration, logs and recoverable backups. Production cutovers, bulk policy changes, database repair and storage rebuild require a maintenance window and explicit rollback criteria.

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

  1. Confirm client build, cumulative update, domain policy and SMB client signing requirements.
  2. Record NAS firmware, Samba version, SMB2/3, signing, encryption and account-authentication support.
  3. Separate guest access, NTLM, Kerberos, name resolution and signing; ping is not a sufficient test.
  4. Use event logs and PowerShell to inspect dialect, signing state and the exact failure path.
Read-only checks and validation examples
Get-SmbClientConfiguration | Select RequireSecuritySignature,EnableSecuritySignature
Get-SmbConnection | Select ServerName,ShareName,Dialect,Signed,Encrypted
Get-WinEvent -LogName Microsoft-Windows-SMBClient/Connectivity -MaxEvents 30

corp.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

  1. Upgrade NAS firmware or Samba and enable supported SMB2/3, authenticated access and signing.
  2. Use the correct DNS name and SPN rather than permanently connecting by IP and bypassing Kerberos.
  3. If a temporary exception is unavoidable, scope it to named devices, subnets and an expiry date, with documented risk.
  4. Move critical shares to a supported file server or NAS instead of treating disabled signing as a permanent solution.
Remote assessment or on-site work?Logs, configuration and a small number of systems can usually be assessed remotely. Physical servers, storage, data-centre power, bulk cutover and recovery exercises should use a controlled on-site window. On-site service is available for Zhejiang, Shanghai and Jiangsu; other locations can be supported remotely.

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.

PreviousAfter Windows 10 support ended, what should enterprises test before moving to Windows 11?NextvSphere 7 is out of general support: upgrade to vSphere 8 or move to another platform?

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.