Error 0x80070035: The Network Path Was Not Found

Error 0x80070035 appears when a Windows client tries to open an SMB share by its UNC path, for example \server\share, and cannot establish the session. The message “The network path was not found” is generated by the redirector, the component that turns a UNC path into an SMB connection. It does not mean the share permissions are wrong. It means the client never got far enough to ask the server about permissions. The path could not be resolved to an address, the address could not be reached on TCP port 445, or the server answered and then refused the protocol or the credentials offered.

The distinction matters because the repair for each layer is different. Changing NTFS permissions on a share the client cannot reach changes nothing. Taking ownership of folders changes nothing either, and it damages the machine. The sections below separate the layers, then give the fixes that belong to each.

What the error is actually reporting

A UNC path has two parts: the server name and the share name. Windows resolves the server name to an IP address, opens a TCP connection to port 445 (SMB over TCP), negotiates an SMB dialect, authenticates, and only then checks share and file permissions. Error 0x80070035 is raised before or during the first three steps. Later failures produce different codes: 0x80070005 for access denied and 0x80004005 for unspecified errors.

That ordering is why the first diagnostic is not a permissions dialog. It is a connectivity test.

Separate the layers before changing anything

Use the IP address in place of the name. If \\192.168.1.50\share opens and \\server\share does not, name resolution is the fault. If both fail, move to reachability.

Test-NetConnection -ComputerName 192.168.1.50 -Port 445

The output shows TcpTestSucceeded. True means the server is reachable on the SMB port and the problem is at the protocol or authentication layer. False means no SMB listener answered: the server is off, the service is stopped, a firewall is dropping the traffic, or the client and server are on different network segments that do not route between them.

If the port is open, ask the server what it supports.

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature

Run this on the server, not the client. EnableSMB1Protocol being False on a modern Windows 10 or 11 machine is normal; SMB1 is not installed by default. RequireSecuritySignature being True is also normal on current Windows 11 builds, which require SMB signing by default.

On the client, check which dialect was negotiated when a connection does succeed to another share:

Get-SmbConnection

The Dialect column shows values such as 3.1.1 or 2.1. A device that only offers SMB1 will not appear here at all, because the connection never completes.

Causes and the fix that belongs to each

Name resolution

If the IP address works and the name does not, the client cannot map the name to an address. Check what the client resolves:

nslookup server

A response pointing to an unexpected address, or no response, confirms the fault. In a domain, the DNS server should hold the record. In a workgroup, NetBIOS name resolution or a hosts file entry is the usual mechanism. A temporary hosts entry confirms the diagnosis; it is not a permanent fix for a network with a DNS server.

Reachability and the network profile

Windows applies different firewall rules depending on whether the network is classified as Public or Private. A machine that joined a new network and classified it as Public will block inbound File and Printer Sharing even when the rules exist. Check the profile:

Get-NetConnectionProfile

The NetworkCategory value should be Private for a trusted local network. Changing it is a deliberate act: a Public classification is correct on untrusted networks, and changing it to Private exposes the machine’s shares to that network.

If the profile is correct, confirm the firewall rules are enabled for the Private profile:

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Select-Object DisplayName, Enabled, Profile

Rules that show Enabled: False for the Private profile are the fault. Enable them with Enable-NetFirewallRule against the specific rule names, or through Windows Security. Do not disable the firewall as a diagnostic; that changes the security posture of the machine and does not tell you which rule was blocking.

On the server, confirm the SMB service is running:

Get-Service -Name LanmanServer

A stopped Server service means nothing is listening on port 445 regardless of firewall state.

Protocol refusal: SMB1 and SMB signing

Two modern defaults break older network storage, and both are deliberate.

SMB1 is not installed by default on Windows 10 and 11. A NAS or print server that only speaks SMB1 will fail to connect, and the client reports 0x80070035 because no common dialect exists. Re-enabling SMB1 on the client is the wrong repair: the protocol has known weaknesses and Microsoft has been removing it for years. The correct action is to update the device firmware so it supports SMB2 or SMB3, or replace the device. Where the device cannot be updated, isolate it on a separate network segment rather than reintroducing SMB1 to the client fleet.

SMB signing is required by default on current Windows 11 builds. A NAS that does not implement signing will fail negotiation. The fix is a firmware update on the NAS. Disabling signing on the client lowers the integrity guarantee for every SMB connection that client makes, not just the one to the old device.

Guest access

Recent Windows editions block unauthenticated guest access to SMB shares by default. A share configured to allow everyone without a password will refuse the client, which typically reports that the organisation’s security policies block unauthenticated guest access, or shows a generic error instead. The repair is to create a local account on the server, grant it share permissions and NTFS permissions, and connect with those credentials. Re-enabling insecure guest logons on the client is possible through policy but restores a configuration Microsoft disabled for a reason.

What people get wrong about this error

The natural reading of “the network path was not found” is that the path is wrong, so the first instinct is to check the share name, then the permissions. That is a reasonable inference from the wording. The message is generated before the client has any knowledge of the share’s existence, so it cannot be reporting a permissions problem. The permission dialog is a dead end because the client never reached the server’s authorization step.

The second common mistake is taking ownership of folders on the server to resolve an access problem. Ownership changes are appropriate when an account has lost access to its own files, not when a client cannot reach a share. Taking ownership of system folders such as C:\Windows or C:\Program Files replaces the trusted installer or SYSTEM as owner, and the resulting permission state can break servicing, updates, and application launches in ways that persist after the original problem is forgotten. If a share permission is genuinely wrong, the fix is to grant the correct group access through the share and NTFS dialogs, not to seize the folder.

A third mistake is disabling the firewall or re-enabling SMB1 as a first move. Both are broad changes that mask the diagnosis. The layered tests above identify which layer failed in a few commands, and the repair then applies to that layer only.

When the server is the client’s own machine

A UNC path that points to the local machine, such as \\localhost\share, can fail with 0x80070035 when the loopback connection is blocked or the Server service is stopped. The same port test applies: Test-NetConnection -ComputerName localhost -Port 445. If the port is closed locally, the Server service is the first thing to check.

Order of repair

The least destructive sequence is: test the IP, test port 445, check the network profile and firewall rules, check the Server service, check the SMB dialect and signing configuration on both ends, then check authentication. Permissions on the share come last, because they cannot be the cause of this error. Ownership changes do not belong in the sequence at all for this code.