The NAS Share That Stopped Mapping After the Windows 11 24H2 Upgrade

A network share on a NAS that has mapped without complaint for years can stop working the same afternoon a Windows 11 PC finishes a feature update. The drive letter disappears, Explorer throws an error that mentions a signature or a security policy, and every obvious suspect — the cable, the router, the NAS power light — checks out fine.

The short version: nothing is broken on the network. The SMB client on the upgraded PC now refuses two things it used to accept, an unsigned session and a guest logon. Which of the two is refusing shows up in the exact wording of the error, and the correct repair is different for each.

The Two-Minute Triage

Read the error text before changing anything. The two failure families are worded very differently, and Microsoft's own SMB signing documentation lists both sets verbatim.

Family A — the guest logon was rejected

• You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
• Error code 0x80070035 with the text The network path was not found.
• System error 3227320323 has occurred. when the attempt is made from a command prompt.

The two-minute action here is to stop using guest and supply a real account. Open an elevated command prompt and map with explicit credentials, substituting the NAS address, share name, and account:

• net use Z: \\192.168.1.50\media /user:nasuser /persistent:yes

In Explorer the equivalent is This PC > ... > Map network drive, then tick Connect using different credentials. If a blank or stale credential is cached from the guest era, the new one will not be used until the old one is removed: Control Panel > User Accounts > Credential Manager > Windows Credentials, then delete any entry whose name starts with the NAS hostname or IP address.

Family B — the session could not be signed

• 0xc000a000
• -1073700864
• STATUS_INVALID_SIGNATURE
• The cryptographic signature is invalid.

Confirm in one command which side is imposing the requirement. In an elevated PowerShell window:

• Get-SmbClientConfiguration | Format-List RequireSecuritySignature
• Get-SmbConnection

The first returns True on an upgraded Pro, Enterprise, or Education machine. The second lists every live SMB session with its negotiated Dialect and whether it is Signed — run it against a share that still works, such as another Windows PC, to see what a healthy session looks like on the same network.

What the Upgrade Actually Changed

Three SMB defaults moved in Windows 11 version 24H2 and carried forward into 25H2. None of them are visible in the Settings app, which is why the failure reads as a hardware fault.

1. Client-side signing is now required, not merely offered

Microsoft's documentation is explicit about the edition split: Windows 11 version 24H2 in the Enterprise, Pro, and Education editions requires both outbound and inbound SMB signing, while the Home edition requires neither. Before this change, a signing requirement applied only to the SYSVOL and NETLOGON shares on domain controllers. Everything else negotiated signing if both ends supported it and skipped it if they did not.

An appliance whose firmware ships with server signing switched off, or a Samba build configured that way, was perfectly usable under that older negotiation. Under the new default the client hangs up instead.

2. Insecure guest logons are blocked on Pro

Blocking guest fallback has been the default in Enterprise, Education, and Pro for Workstations since Windows 10 version 1709. Version 24H2 extended it to Windows 11 Pro. There is a second-order effect worth understanding: a guest session cannot be signed or encrypted at all, so requiring signing removes guest as an option even where the guest policy itself has not been touched. That is why some machines produce the signature error on a share that never had an account on it.

3. A deliberate delay on failed authentication

Windows 11 version 24H2 and later also ship an SMB authentication rate limiter, enabled by default with a 2,000 millisecond pause after each failed NTLM or Kerberos attempt. The value is adjustable from 0 to 10,000 milliseconds in multiples of 100 through Set-SmbServerConfiguration -InvalidAuthenticationDelayTimeInMs. This does not cause the failure, but it is why a retry loop that used to fail instantly now feels like it is hanging.

Why one PC in the same house still works

The edition split above is the single most common reason this gets misdiagnosed. A Home-edition laptop sitting on the same Wi-Fi, pointed at the same share, connects normally, which makes the failing machine look like a hardware problem. Check Settings > System > About or run winver on both machines before touching the router.

The Deep Fix, in the Order That Keeps the Protection

The order below matters. The first two options resolve the failure without lowering the security posture of the PC. The last one lowers it for every SMB connection that machine will ever make, which is why it belongs at the bottom rather than the top.

Step 1 — Turn signing on at the server

Microsoft's guidance for a third-party SMB server that refuses signing is to change the server, not the client. On a NAS this lives in the SMB or Windows file service configuration page of the admin interface. Two settings matter: a server signing option, and a maximum protocol or maximum SMB version option that must be at SMB2 or above. Label wording differs between vendors and between firmware revisions, so match on function rather than on an exact string.

If the server is a Linux box running Samba, the relevant parameters in smb.conf are server signing, which accepts auto, mandatory, or disabled, and server min protocol. Setting server signing = mandatory and a minimum of SMB2_10 or higher, then restarting the service, resolves Family B without touching the Windows client.

After any server-side change, force the client to renegotiate rather than waiting for a cached failure to expire:

1. net use * /delete /y
2. Re-map the share, or reboot if a drive letter is stuck in a disconnected state.

Step 2 — Replace the guest connection with an account

For Family A, create a dedicated user on the NAS, grant it read or read-write permission on the share only, and map with those credentials. Two details are easy to miss. First, the account must exist on the NAS, not on the PC — a matching Windows username does not help unless the NAS holds the same pair. Second, Windows caches the first credential it succeeds with, including an empty one, so clear Credential Manager as described above before testing.

Where a share genuinely must stay open to everyone, such as a media library read by a TV, the correct answer is still a low-privilege named account with a password, not a guest share.

Step 3 — Prove which side is refusing

Auditing turns a guess into a record. Windows 11 version 24H2 added client and server audit policies for exactly this:

• PowerShell: Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
• Group Policy: Computer Configuration > Administrative Templates > Network > Lanman Workstation > Audit server does not support signing

For the guest side, the events are already being written without any policy change. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > SMBClient > Security and filter for these IDs:

• 3023 — the SMB client logged on as the Guest account.
• 31017 — an insecure guest logon was rejected. This is the definitive marker for Family A.
• 31018 — a warning that an administrator has enabled AllowInsecureGuestAuth.
• 31022 — a warning that an insecure guest logon was allowed.

Audit events raised by the signing policies are written under the same Microsoft > Windows > SMBClient node, so check each channel there rather than assuming a single log.

Step 4 — Last resort: relax the client

Microsoft's documentation advises against disabling SMB signing as a workaround for third-party servers, and against signing with guest accounts. If an appliance cannot be updated and cannot yet be replaced, the exact controls are:

Signing, on Pro, Enterprise, or Education:

1. Run gpedit.msc.
2. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Set Microsoft network client: Digitally sign communications (always) to Disabled.

The PowerShell equivalent is Set-SmbClientConfiguration -RequireSecuritySignature $false. The registry equivalent, which is the only route on Home because gpedit.msc is not present there, is reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f.

Guest logons:

1. In gpedit.msc, go to Computer Configuration > Administrative Templates > Network > Lanman Workstation.
2. Set Enable insecure guest logons to Enabled.

The matching registry value is AllowInsecureGuestAuth, a REG_DWORD set to 1, in the same LanmanWorkstation\Parameters key. Because a guest session supports neither signing nor encryption, both the signing policy and any SMB encryption policy have to be off for a guest logon to complete — enabling the guest policy alone will not clear a Family B error.

Scope the cost honestly before doing this. The change is per-machine, not per-share. A PC with client signing disabled is more exposed to relay attacks on every SMB connection it opens, including to a work file server later that day.

When This Is Not the Cause

Several failures look identical in Explorer and have nothing to do with the 24H2 defaults.

• Non-Windows clients fail too. If a Mac, an Android file manager, or a phone app cannot reach the same share either, the problem is on the NAS — a stopped service, a degraded storage pool, or a share that was renamed. Windows client policy has no bearing on those clients.
• The error is a timeout or "The specified network name is no longer available." That is reachability, not authentication. Test the port directly with Test-NetConnection 192.168.1.50 -Port 445. A failed result points at the NAS being down, a VLAN or subnet change, or third-party security software filtering port 445.
• The machine is Home edition and RequireSecuritySignature returns False. Signing is not the cause. Look instead at the network profile being set to Public, at file and printer sharing being off, or at the NAS account being locked.
• The Network node in Explorer is empty but \\192.168.1.50\media opens fine when typed. That is a discovery problem, handled by different services entirely, and it is not fixed by any of the SMB policies above.
• The PC is domain-joined or managed. Local edits get overwritten at the next policy refresh. Run gpresult /h report.html and open the report to see which policy object is winning before assuming a local change failed.
• The appliance only speaks SMB1. None of this applies, and none of it will help. SMB1 is not installed by default on Windows 11; check with Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. Re-enabling it is not a repair, it is an unpatched protocol with known remote code execution history. Replace or update the device.

If None of This Works

Collect these five items before escalating, because they answer the first five questions any vendor or forum will ask:

1. The exact error string and numeric code, copied rather than paraphrased.
2. Edition and build from winver on both the failing machine and a working one.
3. Get-SmbClientConfiguration | Format-List output from the failing machine.
4. Get-SmbConnection output from a share that does work, showing dialect and signed state.
5. The NAS firmware version and the SMB protocol range it is configured to accept.

A STATUS_INVALID_SIGNATURE response with a healthy port 445 test is a server capability question, and the vendor is the right destination for it. If the firmware has no signing option at all, the device predates a requirement that is now the client default across the Windows fleet, and the realistic paths are an isolated VLAN, a small always-on Windows or Linux box acting as an intermediary, or replacement.

The reason this failure is so disorienting is that nothing in the visible chain changed. The same cable, the same subnet, the same share name, the same password. What moved was a default deep in the SMB client, applied to some Windows editions and not others, at a moment chosen by the update schedule rather than by anyone at the keyboard. Once the error text is read as a statement about signing or about guest access, the repair is short — and in most cases it belongs on the NAS, not on the PC.