Windows 11 Shared Folder Not Opening? Check SMB Safely

File Explorer reports that a network path cannot be found, a mapped drive has disappeared, or a NAS suddenly asks for credentials. The tempting fixes are to reset Windows networking, switch off the firewall or turn on an old SMB feature. Those changes can create new problems without identifying why the share failed.

Start with the exact shared-folder address, then test whether your PC can establish a TCP connection to port 445 on the host. If that port test works, investigate the share name, authentication and SMB security requirements. If it fails, check the host, name resolution and network path first. Neither result, on its own, means you need SMB1.

This is a documentation-based troubleshooting guide for Windows 11 clients opening a shared folder on another Windows computer or a NAS over a trusted home or office network. It covers the SMB behaviour documented for Windows 11 24H2 as well as the general checks that apply to other supported Windows 11 releases. The commands below have not been exercised against your network. Do not expose SMB directly to the internet or change a managed PC without its administrator.

Understand which part of file sharing failed

A path such as \\STUDY-PC\Projects contains a host name (STUDY-PC) and a share name (Projects). The host might be another Windows machine, a NAS or a file server. Windows acts as the SMB client when it opens the path; the other device acts as the SMB server. Microsoft's SMB troubleshooting primer draws that client/server distinction explicitly.

There are several separate questions behind the same File Explorer error. Check them in order instead of changing security settings at random.

A computer appearing under Network in File Explorer is a discovery clue, not proof that an individual shared folder can open. Conversely, Microsoft notes that legacy computer browsing methods depended on SMB1, so an absent discovery listing does not automatically mean that a modern SMB share is unreachable. Try the known share path directly before changing discovery settings. Microsoft documents the SMB1 discovery legacy.

1. Confirm the host and share name before diagnosing the network

On the device that actually stores the files, check that it is powered on, connected to the intended network and still presenting the correct share. A laptop that went to sleep or a NAS that moved to a different network address will not be repaired by changing the client PC's SMB policy.

For a Windows host, open File Explorer and review the folder's intended sharing permissions. Depending on the context menu, the sharing route includes Show more options → Give access to → Specific people. Verify the *share name*, rather than assuming the folder's local name or drive letter is also its network name. Microsoft's Windows network file-sharing instructions describe setting access and checking shares.

On the host, Microsoft also suggests opening \\localhost in File Explorer as a way to inspect shares. There is an important exception: a user profile can show personal folders to their owner in that view without those folders all being shared with the network. For a NAS, use the vendor's own shared-folder page and confirm that the share is enabled.

On the client PC, press Win + E, click File Explorer's address bar and enter the exact path. For this article, \\STUDY-PC\Projects is a fictional example; substitute the real host and share names. Record the whole error message and any hexadecimal code. Do not enter a local path such as C:\Projects when attempting to reach another device.

2. Check whether TCP port 445 is reachable

In Windows PowerShell on the client PC, run this read-only test, replacing the example name with your actual file server or NAS name:

Test-NetConnection -ComputerName STUDY-PC -Port 445

Look for RemoteAddress, RemotePort and TcpTestSucceeded. Microsoft documents these fields and the -Port parameter in the Test-NetConnection reference. It does not require you to disable anything or run PowerShell as administrator for this ordinary connectivity check.

A result of TcpTestSucceeded : True indicates that a TCP connection to port 445 succeeded at the resolved destination at the moment of the test. It does not mean the share exists, the account is permitted, the server supports the required SMB signing, or that a file can be read.

A result of False points earlier in the connection path. The host could be asleep, unreachable across a guest or isolated Wi-Fi network, resolved to the wrong address, not listening on that port, or blocked by a relevant firewall. Do not treat False as proof of one particular firewall fault.

If the name fails to resolve, compare the PC or NAS name with its actual network settings. If you have an authorised, known local IP address for that device, you may repeat the port test using that address to distinguish hostname resolution from basic TCP reachability:

Test-NetConnection -ComputerName 192.0.2.10 -Port 445

The 192.0.2.10 address is reserved here as a documentation example; it is not the address of your NAS. A matching successful IP test and failed name test is a lead to check name resolution. It is not a reason to permanently substitute an IP address in an organisation's file-share path; some domain authentication arrangements depend on names.

3. If the port test fails, stay at the network layer

Check whether another authorised computer on the same trusted network can reach the share. If every device fails, investigate the host, NAS service, access point, switch or router. If only one Windows PC fails, compare its active Wi-Fi/Ethernet connection and any VPN or security software against a working device.

On the Windows host, check that file sharing is enabled for the network profile you actually trust. A Windows device on a Public profile is intentionally less discoverable. Moving an unfamiliar hotel, guest or workplace network to Private just to remove an error broadens exposure; use Private only when you trust the other devices. Microsoft explains network profiles and discovery.

Inspect the host's firewall only after the previous checks point to it. Windows may require an inbound File and Printer Sharing rule for the relevant trusted profile; an outbound connection initiated by the client is not the same exception. Jitsumi's published guide to deciding when to allow an app through Windows Firewall explains how profile-scoped exceptions differ from turning the firewall off.

Do not open TCP 445 on your router to the public internet, set a catch-all allow rule, or disable the firewall to make a test pass. Microsoft's SMB security guidance calls for blocking inbound SMB from the internet and limiting access to the networks and machines that need it. For an off-site connection, use an approved VPN or supported secure remote-file-access method rather than forwarding SMB to the WAN.

Also avoid a full Windows Network reset at this stage. It affects adapter settings and can disrupt VPNs or virtual switches. Our guide to what Windows 11 Network reset changes explains why it is a last-resort recovery step, not the first response to one inaccessible share.

4. If port 445 works, check the share and credentials

Once TCP succeeds, go back to the precise failure in File Explorer. A misspelt share name, a folder that is no longer shared, a password change or missing permission can all prevent access even though the server's SMB port accepts connections.

Start with an account that the server recognises. A username from the client PC is not automatically a valid NAS account. If a credentials dialog appears, use an approved account and the format documented for that server; on a Windows workgroup, the computer that hosts the files may expect its own local account. Do not reuse an unknown password from another person or make the folder available to Everyone just to eliminate the prompt.

On a Windows host, both the share permission and the underlying file/folder permission matter to what the connected user can do. Ask the owner to confirm which account needs read-only access or writing rights. If browsing works but creating a file fails, focus on permission to modify that folder rather than assuming the network dropped.

Do not save credentials into a script, article comment or troubleshooting screenshot. On a work device, permission and credential changes belong with IT. If the error mentions guest access or an invalid SMB signature, move to the version-specific section below instead of repeatedly entering the same password.

Windows 11 24H2: guest access and SMB signing are separate checks

This matters most for older NAS devices and servers that have not been maintained. According to Microsoft's current SMB signing documentation, Windows 11 24H2 Pro, Enterprise and Education require inbound and outbound SMB signing by default. Windows 11 24H2 Home does not impose those same signing requirements by default. Edition, policy and server configuration therefore matter; do not assume every Windows 11 installation behaves identically.

SMB signing lets the endpoints detect altered SMB messages. It is a security mechanism, not a test of whether a password is correct. If a third-party NAS cannot sign SMB traffic, Microsoft recommends enabling signing on that server rather than switching off the client's requirement. A message such as STATUS_INVALID_SIGNATURE is a reason to inspect the device's SMB configuration and firmware, not to enable SMB1.

Guest access is another compatibility trap. A guest-only share has no properly authenticated user session. Microsoft's insecure guest-logon guidance recommends upgrading or replacing equipment that only permits guest authentication and warns about the risks of enabling it. If Windows explicitly reports blocked unauthenticated guest access, create an authenticated share on the NAS where supported and use an account with the necessary permissions.

Microsoft's general Windows sharing instructions include a shortcut for disabling password-protected sharing. That may be convenient in a narrow home setup, but it is not a universal security recommendation—particularly where newer client editions require stronger authentication. This guide intentionally prefers named accounts, limited permissions and compatible signing rather than weakening guest access controls.

Why turning on SMB1 is not a modern fix

SMB1 is an obsolete version of the file-sharing protocol. Microsoft documents that Windows 11 does not install the SMB1 client or server by default after a clean installation. Newer SMB versions are included without it. The absence of the SMB1 optional feature is therefore normal.

Microsoft's SMB protocol-version guidance explicitly recommends updating the old server rather than reinstalling SMB1. It also explains that changing SMB protocol versions does not fix SMB signing requirements. Turning on SMB1 to treat a signing error solves the wrong problem and reintroduces a protocol with serious security weaknesses.

For a legacy NAS, check the manufacturer's firmware notes for SMB2/SMB3 support, account-based shares and signing. If the device cannot support those features, consider replacing it or migrating the data. Keep any temporary migration arrangement isolated and authorised; do not make the rest of your household or workplace network accept an unsafe file-sharing configuration.

Worked example: port 445 succeeds but the NAS folder still fails

Suppose a fictional household NAS, STUDY-NAS, contains a share called Media. The Windows 11 Pro client can resolve the name and Test-NetConnection -ComputerName STUDY-NAS -Port 445 returns True. Entering \\STUDY-NAS\Media nevertheless displays a message about unauthenticated guest access.

That result narrows the investigation. Name resolution and TCP reachability worked in the test; retrying Wi-Fi, changing DNS or resetting adapters is unlikely to address the stated guest-policy problem. The NAS owner should check whether the share has been configured for guest access, create or enable a properly authenticated account, confirm the share's permissions and check firmware support for SMB signing. Then retry with the approved account. This is an illustrative diagnostic, not a claim that we tested a particular NAS or that one fix works for every model.

If the error instead says access is denied after sign-in, inspect the account and folder permissions. If the port test fails, return to host and network checks. The same initial symptom can lead to very different repairs depending on the first result.

A compact decision table for your next check

Confirm the repair without loosening other protections

Once the relevant fault is addressed, reopen the exact path from the same client. First confirm that you can browse and read a harmless file you are authorised to access. If the user needs to write, and the folder owner has approved it, create a clearly named disposable text file in the intended share, check that it appears, then delete only that disposable file. Do not overwrite a valuable file merely to prove that sharing works.

Record the host name, share name, Windows edition/build, date, full error, port-test result (including RemoteAddress) and what changed. For repeat problems, this is far more useful to a support technician than a list of security switches you tried. If the share is on a managed server or an old appliance, involve its administrator or vendor with those observations.

If all you need is to send one file once instead of leaving a folder continuously available, you may not need an SMB share at all. Jitsumi's Nearby Sharing guide covers a separate Windows hand-off method with a receiving-device confirmation step.

The practical stopping point is the same as the opening rule: establish which layer failed, change only that layer, then verify the originally failing path. A missing network drive is not permission to turn off file-sharing security.

Sources and further reading

• Microsoft Support: File sharing over a network in Windows — sharing controls, network discovery and share checks.
• Microsoft Learn: Advanced SMB troubleshooting — client, server and transport terminology.
• Microsoft Learn: Test-NetConnection — documented PowerShell TCP test and output fields.
• Microsoft Learn: SMB signing behaviour — Windows 11 24H2 edition defaults and third-party compatibility.
• Microsoft Learn: Insecure SMB guest logons — default restrictions and recommended alternatives.
• Microsoft Learn: SMB1 installation defaults — why the legacy component is absent.
• Microsoft Learn: Secure SMB traffic — segment access and avoid port 445 exposure to the internet.