My NAS or shared folder disappeared after a Windows update
Why a NAS, router USB share or Samba box stops working after upgrading to Windows 11 24H2 (SMB signing and blocked guest access), how to tell which problem you have, and the safe fix before the risky workarounds.
Your NAS worked yesterday. After a Windows update (usually the jump to Windows 11 24H2) it’s gone: the mapped drive shows a red X, or opening \\nas gives an error. Nothing changed on the NAS. What changed is that Windows got stricter, and the NAS is relying on something Windows no longer allows.
There are two separate changes. Work out which one you’ve hit before changing anything.
What changed in Windows
- SMB signing is now required. Microsoft says Windows 11 24H2 Pro, Enterprise and Education require SMB signing on both outgoing and incoming connections. Home edition doesn’t. Signing adds a tamper-proof stamp to every message. Older NAS firmware, cheap router USB shares and some Samba setups have it turned off.
- Guest (no password) access is blocked. Windows 10 Enterprise and Education have refused “guest” logons over SMB2/3 since 2017, and current Windows 11 Pro builds refuse them too. Many NAS boxes and router shares are set up as “anyone on the network can open this” with no username, which is exactly a guest logon.
The two collide: Microsoft notes that guest logons can’t be signed. So a guest-only share fails once signing is required, even if you re-enable guest access.
Step 1: Read the error
| You see | It most likely means |
|---|---|
0xc000a000, STATUS_INVALID_SIGNATURE, “The cryptographic signature is invalid” | The NAS doesn’t support or allow signing. |
| “…your organization’s security policies block unauthenticated guest access” | The share uses guest access. |
0x80070035 “The network path was not found”, or System error 3227320323 | Usually one of the two above. Microsoft lists both of these for the guest case. First rule out a plain network problem (Step 2). |
Step 2: Rule out the boring causes (2 minutes)
- Check the NAS answers on the file-sharing port. In PowerShell:
Test-NetConnection nas -Port 445(use the NAS’s name, then its IP).TcpTestSucceeded : Falsepoints to a network problem (IP changed, NAS asleep, firewall, wrong Wi-Fi), not this guide. - Try the IP address: press Win+R and type
\\192.168.1.50(your NAS’s IP). If the name fails but the IP works, suspect name resolution. Treat it as a clue rather than proof, because connecting by IP can also change how Windows signs you in. - Note your edition (Settings › System › About). Home doesn’t require signing by default, but settings or security software can change that, so do the Step 4 check on every edition.
Step 3: The right fix, on the NAS
Microsoft’s recommendation, and the fix that keeps you safe:
- Update the NAS firmware. Most Synology, QNAP, TrueNAS, Unraid and current Samba versions support signing.
- Give the share a real user account. Create a user on the NAS with a password, grant it access to the share, and turn off guest access for that share.
- Turn signing on (or set it to “auto/allowed”) in the NAS’s SMB settings if there’s an option. Make sure SMB2 or SMB3 is enabled too. SMB1 should be off.
- On the PC, clear the old connections and saved password, then map it again with the new user. Close anything that has files open on the NAS first.
Open Credential Manager › Windows Credentials and remove old entries for the NAS. Leftovers cause error 1219 (“multiple connections… by the same user”) or sign you in as the wrong account. Then:net use # list every connection to the NAS net use Z: /delete # repeat for each NAS connection listed
Thenet use Z: \\nas\share * /user:nasuser /persistent:yes*makes Windows ask for the password instead of reusing an old one.
If the device can’t do signing or can’t use a username and password (old routers, ancient NAS firmware), Microsoft’s advice is to replace it or stop sharing from it. A cheap option is to plug the drive into another PC or a small Linux box and share it from there.
Step 4: Check what Windows is enforcing
In PowerShell:
Get-SmbClientConfiguration | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
RequireSecuritySignature : Truemeans signing is required (the 24H2 default on Pro and up).EnableInsecureGuestLogons : Falsemeans guest access is blocked.
Write both values down before changing anything. You’ll need them to put things back exactly as they were.
Last resort: weaken Windows (understand the cost first)
Risk: Both changes make it easier for anything on your network to impersonate your NAS, intercept what you copy, or plant malware through the share. Microsoft explicitly doesn’t recommend either. Only consider them on a home network you trust, for a device you’re about to replace, and write down what you changed.
Stop if: the PC is a work or school machine (policy will undo this or flag it), or you only need the share occasionally. Copying files off with a USB stick is safer.
In an elevated PowerShell window:
# Allow connections to servers that can't sign (affects ALL SMB connections from this PC)
Set-SmbClientConfiguration -RequireSecuritySignature $false
# Only if the share is guest-only and can't be given a password
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force
Microsoft notes that guest sessions support neither signing nor encryption. If the NAS also requires SMB encryption, guest access can’t work at all. Give the share a password instead of weakening Windows further.
Undo (once the NAS is fixed or replaced). Put back the values you wrote down. On Windows 11 24H2 Pro and up, the defaults are:
Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force
On Pro and up, the Group Policy equivalents are Computer Configuration › Windows Settings › Security Settings › Local Policies › Security Options › Microsoft network client: Digitally sign communications (always) and Computer Configuration › Administrative Templates › Network › Lanman Workstation › Enable insecure guest logons. If a policy is set there, it wins over the PowerShell setting.
Still not working?
- Event Viewer › Applications and Services Logs › Microsoft › Windows › SMBClient › Security. Event 31017 (“Rejected an insecure guest logon”) confirms the guest problem.
- An “SMB1” error means the device only speaks SMB1, which Windows removed. Don’t turn SMB1 back on. Replace the device or share the drive from something newer.
Sources
- Control SMB signing behavior — by Microsoft Learn
- Enable insecure guest logons in SMB2 and SMB3 for Windows client and Windows Server — by Microsoft Learn
- Can't access NAS folders in Windows 11 24H2 — by Microsoft Q&A community