Fix "The Network Path Was Not Found" (Error 0x80070035) in Windows

By Stackvora Team · 2026-08-26 · 9 min read

Error 0x80070035 — "The network path was not found" is one of the most reported Windows file-sharing failures, and it almost never has a single cause. It is a generic SMB connection failure: Windows could not reach the share over TCP 445, could not resolve the name, or was refused by the remote host. This guide walks the same order a support engineer would.

1. Confirm what actually fails

Before changing settings, separate name resolution from connectivity. From the client, run:

ping fileserver
nslookup fileserver
Test-NetConnection fileserver -Port 445

Interpret the result:

Name does not resolve → DNS or WINS problem, not SMB. Try \\192.168.1.20\share by IP. If the IP works and the name does not, fix DNS.
Ping works, port 445 fails → firewall, network ACL, or the Server service is stopped on the host.
Both succeed but the share still fails → authentication, SMB protocol version, or share permissions.

2. Make sure the host is actually sharing

On the server or the PC hosting the folder, confirm the Server service is running and shares are published:

Get-Service LanmanServer
Get-SmbShare
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

If LanmanServer is stopped, no share works no matter what the client does. Start it and set it to Automatic.

3. The SMBv1 trap

Modern Windows builds ship with SMBv1 disabled for security. NAS boxes, old Linux Samba builds and legacy appliances that only speak SMBv1 will now return 0x80070035. The correct fix is to upgrade the device or its firmware to support SMB 2/3 — not to re-enable SMBv1, which is exploitable and used by ransomware families like WannaCry. If you must enable it temporarily on an isolated segment:

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Treat that as a migration window, not a solution, and document a removal date.

4. Firewall rules

File and Printer Sharing must be allowed on the profile the network is currently using. A machine that flips from Domain to Public profile — common after a VPN reconnect — silently blocks SMB.

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

Also check third-party endpoint protection. Several EDR suites add their own SMB blocking rules that do not appear in the Windows Firewall list.

5. Network discovery and the browser stack

If the share works by IP but not by hostname, and DNS is healthy, the problem is often NetBIOS/WSD discovery. Enable these services on both ends: Function Discovery Provider Host, Function Discovery Resource Publication, SSDP Discovery and UPnP Device Host. On the client, turn on Network Discovery for the current profile in Advanced sharing settings.

6. Credentials and NTLM policy

Hardened environments frequently block guest and legacy authentication. Two policies cause most surprises:

Insecure guest logons — disabled by default since Windows 10 1709. NAS shares configured for guest access will fail. Give the NAS a real user account instead.
LAN Manager authentication level — if the server requires NTLMv2 and the client offers LM/NTLM, the session is refused.

Clear stale cached credentials before retesting: cmdkey /list then cmdkey /delete:fileserver. Stale tickets survive password changes and produce misleading errors.

7. Reset the client network stack

When a client works fine on one network and fails on another, corrupt stack state is likely. From an elevated prompt:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /registerdns

Reboot afterwards. This resolves a surprising share of 0x80070035 reports on laptops that roam between offices and VPN.

Quick reference table

Symptom	Most likely cause	First action
IP works, name fails	DNS / NetBIOS	Flush DNS, check A record
Port 445 blocked	Firewall or ACL	Enable File and Printer Sharing group
Only old NAS fails	SMBv1 removed	Update NAS firmware to SMB2+
Prompted repeatedly for password	Cached creds / NTLM policy	`cmdkey /delete`, re-auth
Everything fails on one PC	Corrupt stack	`netsh winsock reset`

Key takeaways

Test by IP first — it splits the problem into "name" versus "network" in ten seconds.
Never leave SMBv1 enabled as a permanent fix.
Profile changes (Domain → Public) silently break sharing after VPN sessions.

Work through the layers in order and 0x80070035 stops being mysterious. Paste your Test-NetConnection and Get-SmbServerConfiguration output into Stackvora AI for an environment-specific read, and browse the knowledge base for domain-joined edge cases.