Why did file sharing stop working after the Windows 11 24H2 update?

24H2 made SMB signing required by default and blocked insecure guest logons. Devices that do not support SMB signing (older NAS drives, some Samba/Linux boxes) and shares that relied on guest access stop connecting, showing credential prompts, a security-policy message, or error 0x80070035. The security tightening is intentional.

How do I fix SMB sharing after 24H2 without weakening security?

Update the NAS or device firmware so it supports SMB signing and SMB2/SMB3, enable signing in its file-service settings, and connect with a real user account instead of guest. This keeps 24H2's protections on. Only disable RequireSecuritySignature or re-enable insecure guest logons on a trusted network as a last resort.

Should I re-enable SMB1 to fix a device that stopped working?

No. SMB1 is the protocol exploited by WannaCry and is disabled for good reason — re-enabling it puts the whole network at risk. Update or replace the device instead. A tool that transfers over its own encrypted protocol, like Oxolan, is not affected by SMB signing or guest-access changes at all, because it does not use SMB between machines.

Windows 11 24H2 Broke File Sharing — SMB Signing & Guest Access Fix

What Changed in 24H2

After updating to Windows 11 24H2, many offices found that shared folders and NAS drives that worked for years suddenly failed — with credential prompts, "you can't access this shared folder because your organization's security policies block unauthenticated guest access," or a plain 0x80070035.

Nothing is broken. Microsoft tightened two SMB security defaults in 24H2:

SMB signing is now required by default for outgoing (client) and incoming (server) connections.
Insecure guest fallback is blocked — the SMB client will no longer silently connect as guest when authentication fails.

Both changes are good for security. They break connections to devices that do not support SMB signing (older NAS units, some Linux/Samba boxes, cheap network drives) and setups that quietly relied on guest access.

First: Fix It the Right Way

Before disabling anything, try the secure fix, because it keeps 24H2's protections in place:

Update the NAS or device firmware. Most current NAS firmware (Synology, QNAP, etc.) supports SMB signing and SMB3 — a firmware update usually restores the connection with signing left on.
Enable SMB signing / SMB2+ on the other device. On a Samba server, enable signing and disable SMB1. On a NAS, set the minimum SMB protocol to SMB2 or SMB3 and enable signing in its file-services settings.
Use a real account instead of guest. If the break is the guest-access change, create a proper user on the host/NAS and connect with those credentials (see enter network credentials).

If You Must Relax the Defaults

Only do this on a trusted network you control, and prefer the secure fixes above. These reduce security.

Allow connections to devices that cannot sign (client side, elevated PowerShell):

Set-SmbClientConfiguration -RequireSecuritySignature $false

Re-enable insecure guest access (only if a device genuinely needs it): Group Policy → Computer Configuration → Administrative Templates → Network → Lanman Workstation → Enable insecure guest logons → Enabled. On Home editions this is the AllowInsecureGuestAuth registry value under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters.

Re-enable the secure defaults once the device is updated:

Set-SmbClientConfiguration -RequireSecuritySignature $true

Why You Should Not Just Disable SMB1

If a device only works with SMB1, do not re-enable SMB1 to accommodate it. SMB1 is the protocol behind WannaCry and is disabled for good reason. Replace or update the device instead — an old drive that needs SMB1 is a security liability on an office network.

The Bigger Picture

24H2 is the latest turn of a long pattern: Windows file sharing keeps getting stricter and more fragile, and every hardening step breaks another office's setup. The changes are correct, but they land as broken shares and support tickets.

This is exactly why some teams move file transfer off SMB entirely. Oxolan does not use SMB for transfers between machines — it uses its own protocol with TLS 1.3 and certificate pinning that is secure by default and is not affected by Windows changing SMB signing or guest-access rules. A 24H2-style update cannot break it, because there is no SMB in the path. (Reaching a traditional NAS still uses SMB — that part stays subject to these settings.)