Windows 11 24H2 — Fix Network Drive Access, SMB Signing and Guest Login Errors

After upgrading to Windows 11 24H2, you may suddenly find that a previously working network drive, NAS or shared folder is no longer accessible—even when the device is online and accessible from another computer.

This guide explains how to distinguish basic connectivity problems from Windows' stricter SMB authentication and signing requirements, and how to restore access without unnecessarily weakening your security settings.

The symptoms#

You might encounter messages such as:

Error 0x80070035

Windows cannot access \\SERVER\Share
Error code: 0x80070035
The network path was not found.

System error 1272 / insecure guest access blocked

System error 1272 has occurred.
You can't access this shared folder because your organization's
security policies block unauthenticated guest access.

These messages do not all have the same cause. An error indicating that the network path cannot be found calls for different initial checks from an explicit guest-authentication error.

Why Windows 11 24H2 can cause this#

Windows uses SMB (Server Message Block) to access network shares and mapped drives. Windows 11 24H2 introduced stricter default SMB security requirements.

• SMB signing: Signing provides integrity protection for SMB traffic. Windows 11 24H2 Pro, Enterprise and Education require outbound and inbound SMB signing by default. Requirements differ by edition and configuration.
• Insecure guest authentication: Some old NAS devices permit access without a named account. Modern Windows installations restrict this kind of guest access, and guest sessions do not support the enforced signing requirements.

An older share that relied on guest access or an SMB implementation without compatible signing support may therefore stop working after an upgrade.

The preferred solution is authenticated SMB access with appropriate signing support, not disabling security controls on the Windows client.

Step 1 — Check network connectivity and name resolution#

Open PowerShell and test whether your file server's name resolves:

Resolve-DnsName SERVER

Replace SERVER with your actual server or NAS hostname.

If name resolution fails, check DNS configuration or test with the server's IP address to narrow down the issue.

Next, check whether TCP port 445 is reachable:

Test-NetConnection SERVER -Port 445

Look for:

TcpTestSucceeded : True

If it reports False, investigate:

• Whether the NAS or server is online and serving SMB.
• Windows Firewall or a firewall on the remote device.
• Routing, VLANs and network segmentation.
• Name resolution to an incorrect IP address.
• Whether TCP 445 is blocked between the two devices.

You can also try ping SERVER, but a failed ping does not prove the host is unavailable: ICMP may be blocked.

If port 445 is unreachable, changing SMB signing settings will not solve the connectivity problem.

Step 2 — Inspect the Windows SMB client settings#

Open PowerShell as Administrator and run:

Get-SmbClientConfiguration |
  Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

Example:

RequireSecuritySignature EnableInsecureGuestLogons
------------------------ -------------------------
True                     False

These settings mean that SMB signing is required and insecure guest logons are not enabled. They are expected in many secure Windows configurations.

Do not change these values just because they are enabled. First find out how the remote share authenticates and whether its SMB implementation supports signing.

Step 3 — Check how the file share authenticates#

In File Explorer, enter:

\\SERVER\Share

If Windows asks for credentials, enter the username and password configured on the NAS or file server.

If the share only supports guest access, configure a named account on the server where possible:

1. Sign in to the NAS or file-server management interface.
2. Create a dedicated account with a strong password.
3. Grant it access to the required shared folder.
4. Disable guest access to that share where practical.
5. Save the changes and connect from Windows using the new account.

On a Windows file server, both share permissions and NTFS permissions must allow the intended access.

Step 4 — Map the drive with explicit credentials#

Open Command Prompt and run:

net use Z: \\SERVER\Share /user:SERVER\username *

Replace:

• Z: with the drive letter you want.
• SERVER with the server name.
• Share with the correct share name.
• SERVER\username with the identity supported by the server (for example, a local NAS account or domain account).

The final * prompts securely for the password rather than embedding it in the command.

To inspect existing mapped connections:

net use

If a stale or conflicting connection is present, disconnect only the mapping you recognise and no longer need:

net use Z: /delete

Windows may refuse to connect to the same server using different credentials at the same time. Remove conflicting sessions or use the intended credentials consistently.

Step 5 — Check whether the server supports SMB signing#

If authentication is correct but access still fails, verify the server's SMB implementation.

On a Windows file server, run in elevated PowerShell:

Get-SmbServerConfiguration |
  Select-Object EnableSecuritySignature, RequireSecuritySignature

For modern SMB versions, the signing requirement is governed by the negotiated dialect and signing policy; RequireSecuritySignature is the important enforcement setting. If your server does not support the client's required security capabilities, fix the server configuration or update the system. Do not blindly alter organisation-managed server policy.

For NAS appliances or Linux Samba servers, consult the vendor's guidance to enable authenticated SMB2/SMB3 with signing support. Older devices may require firmware updates.

Do not enable SMB1 to restore compatibility. SMB1 is obsolete and exposes systems to significant security risks.

If a device cannot support secure authentication and signing, consider replacing or isolating it while planning an upgrade.

Step 6 — Verify the SMB connection#

After connecting, run this on the Windows client:

Get-SmbConnection |
  Select-Object ServerName, ShareName, Dialect, Signed, Encrypted

Look for the intended server/share, the negotiated SMB dialect, and whether the connection is signed.

For a connection that requires signing:

Signed : True

Then:

1. Open the mapped drive in File Explorer.
2. Confirm you can see the expected folders.
3. If you have write permissions, create a temporary test file.
4. Open the file and then delete it.

That checks basic share access and permissions as well as SMB connectivity.

Still seeing error 0x80070035?#

0x80070035 is not specific to SMB signing. Check these possibilities before changing security settings.

Incorrect DNS resolution#

Resolve-DnsName SERVER

Compare the resolved address with the actual IP address of the file server.

Firewall restrictions#

Test-NetConnection SERVER -Port 445

Confirm TCP 445 is permitted inside your trusted network. Do not expose SMB directly to the public internet.

Wrong share name#

Verify that the UNC path is correct. \\SERVER\Documents and \\SERVER\Document identify different share names.

Incorrect permissions or cached credentials#

Check the user's share and filesystem permissions. You can review stored credentials under:

Control Panel → Credential Manager → Windows Credentials

Remove obsolete entries only when you know the correct replacement credentials.

Should you disable SMB signing or enable guest logons?#

Some forum discussions recommend:

Set-SmbClientConfiguration -RequireSecuritySignature $false

Other posts suggest enabling insecure guest logons.

These changes may restore compatibility with some legacy devices, but they weaken security. Signing helps protect SMB communications against tampering and certain relay attacks; anonymous/guest sessions lack the security guarantees provided by authenticated connections.

For normal use, Microsoft's recommendation is to update the server or NAS, configure authenticated access and support appropriate SMB signing—not to lower Windows security requirements just to make an old share work.

Quick troubleshooting checklist#

Summary#

If a network drive or NAS stopped working after Windows 11 24H2:

1. Check the server's address and TCP port 445.
2. Inspect the client's SMB signing and guest-access settings.
3. Confirm the share offers authenticated access.
4. Connect using a valid account.
5. Check the file server's SMB signing support.
6. Verify the session, share permissions and file access.

Diagnosing the actual fault is safer—and usually more sustainable—than disabling SMB security features.

References#

• Microsoft — Control SMB signing behaviour
• Microsoft — SMB security hardening
• Microsoft — Insecure guest logons
• Microsoft — SMB version guidance