FixHub
Windows

"Can't Access This Shared Folder — Security Policies Block Guest Access": Do This, Not That

Published June 10, 2026 · by The FixHub Team

You try to open a shared folder or a NAS and Windows refuses:

“You can’t access this shared folder because your organization’s security policies block unauthenticated guest access.”

(Sometimes surfaced alongside 0x80070035 — “The network path was not found.”)

Why this is by design, not a bug: starting with Windows 10 version 1709 and Windows Server 2019, SMB2/SMB3 clients no longer allow guest-account access to a remote server by default. A device that lets you in with no real credentials (many cheap NAS boxes, old routers’ USB shares) is using guest auth, and Windows now blocks it.

Why the popular fix is dangerous: nearly every top result tells you to enable “Insecure guest logons” (the Group Policy toggle, or Set-SmbClientConfiguration -EnableInsecureGuestLogons $true). Microsoft explicitly recommends against this — insecure guest access enables spoofed-server attacks, adversary-in-the-middle, and ransomware delivery, because an attacker can impersonate your “share” and you’ll connect with no authentication. Flipping that switch fixes the symptom by removing the protection.

The safe fix: give the share real credentials

The right move is to make the connection authenticated instead of guest:

  1. On the NAS / file server, create a real user account with a password and grant it access to the share (disable anonymous/guest sharing).
  2. On Windows, connect with those credentials: Win + R → \\server-name\share, and when prompted enter the username and password. Tick Remember my credentials (or save it in Credential Manager) so it persists.
  3. If the device only ever supported guest access and can’t do authenticated SMB, the documented recommendation is to update its firmware or replace it — guest-only sharing is end-of-life for a reason.

Check it’s actually the guest-access block (and not plain 0x80070035)

A bare 0x80070035 without the “guest access” wording has other causes worth ruling out:

  • SMB 1.0 only device: modern Windows disables the insecure SMBv1 client. The fix is not to re-enable SMBv1 — update or replace the device.
  • Network discovery / file sharing off: Settings → Network → Advanced sharing settings → turn on network discovery and file/printer sharing for your Private profile.
  • Name resolution: try the server’s IP (\\192.168.x.x\share) — if that works but the name doesn’t, it’s a DNS/NetBIOS issue, not guest access.

Edition note

This block is edition-dependent: Windows 10/11 Home and Pro still allow guest auth by default, while Enterprise, Education, Pro for Workstations, and Server block it. So the same NAS may “work on my laptop” (Home) but fail on a Pro-for-Workstations or domain-joined machine — that difference is expected, and the answer is still authenticated access, not weakening the stricter machine.

FAQ

But enabling insecure guest logons works instantly — why not? Because it disables a protection that stops a hostile machine from impersonating your file server. It’s the kind of change that turns one bad email into a network-wide ransomware event. Authenticate instead.

My NAS has no user accounts option. Then its sharing is guest-only. Update the firmware (many vendors added authenticated SMB), or move the data to a share that supports real credentials.

Sources: Microsoft Learn — Guest access in SMB2 and SMB3 disabled by default, Microsoft Learn — Enable insecure guest logons in SMB2 and SMB3 (and why not to)