0x80070035 The Network Path Was Not Found | Fix Fast

You click a shared folder, type a UNC path like \\PC-NAME\\Share, and Windows throws the same line every time. It feels vague, yet it’s a pretty specific failure. Your PC tried to reach another machine or NAS over the file-sharing stack, and something in the chain didn’t line up.

This guide walks you through a clean, repeatable path to a fix. Most fixes are safe; you can undo them. Start with quick checks that solve most cases in minutes, then move into deeper items like SMB settings, services, and credentials. You’ll end with a short checklist you can keep for the next time it pops up. It’s fixable. Stay methodical.

0x80070035 The Network Path Was Not Found On Windows Shares

Windows file sharing rides on a few building blocks. The address has to resolve to the right device, your network has to allow discovery and file sharing, the target has to be sharing something, and both sides have to agree on the SMB dialect and sign-in method.

When one link breaks, Windows can’t finish the connection. It may show error 0x80070035 even if the target device is online. Treat it like a “can’t reach the share service” message, not a single, one-cause error.

Fast Checks That Fix Most Cases

Do these in order. Each step is quick, and the results tell you where the break is. If you’re on Wi-Fi, stay on the same network as the device you’re reaching. Guest networks and “client isolation” settings can block local sharing.

If you want a fast sanity check for SMB itself, test port 445. In PowerShell, run Test-NetConnection 192.168.1.50 -Port 445. A “TcpTestSucceeded: True” result means the path is open at the network level. If it’s False, you’re dealing with a firewall rule, router isolation, or a VPN client that is hijacking local routes.

1. Confirm the path — Re-type the share path with double backslashes, and verify the share name on the host.
2. Try the IP path — Use \\192.168.1.50\\Share to see if it’s a name issue or a deeper reachability issue.
3. Ping the target — Run ping PC-NAME and ping 192.168.1.50 to confirm basic network reach.
4. Check the network profile — Set your connection to Private on both PCs so discovery rules apply.
5. Restart both devices — Reboots clear stuck services, stale sessions, and cached name entries.

If IP works and name fails, focus on name resolution and NetBIOS. If both fail, focus on sharing settings, firewall, SMB, and the target’s services. If you can browse Network but opening a share fails, focus on credentials and SMB security settings.

Fix Name Resolution And Discovery Issues

Windows can reach shares by name through DNS, LLMNR, and NetBIOS. Home networks often rely on a mix, so one device change can break the “just type the name” habit. Start by checking the basics, then move into the two settings that flip this issue most often.

Confirm you can resolve the host name

1. Run nslookup — In Command Prompt, type nslookup PC-NAME and see if it returns an IP address.
2. Flush the resolver cache — Run ipconfig /flushdns, then try the share again.
3. Check the router list — Look for the target device in your router’s client list to confirm its current IP.

Turn on Network Discovery and File Sharing

On each Windows PC, open Settings, go to Network & internet, and check that the connection is marked Private. Then open Control Panel, go to Network and Sharing Center, and open Advanced sharing settings. Turn on network discovery and file and printer sharing for the Private profile.

On the host PC, also check the share itself. Right-click the folder, open Properties, then Sharing. Use Advanced Sharing to confirm the folder is shared and that at least one account has permission to read it.

Enable NetBIOS over TCP/IP when names won’t resolve

Some networks still depend on NetBIOS name broadcasts, especially with older NAS boxes or mixed Windows versions. If name access fails but IP works, this setting can bring names back.

1. Open adapter settings — Press Win+R, type ncpa.cpl, and press Enter.
2. Edit IPv4 options — Right-click your active adapter, choose Properties, then open Internet Protocol Version 4.
3. Enable NetBIOS — Click Advanced, open the WINS tab, select Enable NetBIOS over TCP/IP, then click OK.

Match SMB Settings And Windows Sharing Features

SMB is the protocol behind Windows file sharing. Modern Windows versions use SMB 2 and SMB 3 by default. Some older devices only talk SMB 1, which is widely treated as unsafe. If you own the target device, updating its firmware or enabling SMB 2/3 there is the cleanest move.

If you can’t change the target and it truly only supports SMB 1, you may need to enable the SMB 1 client on the PC that connects. Do this only for a device you trust on a private network, and only as long as you need it.

1. Check SMB on the target — On NAS devices, look for “SMB” or “Windows file service” settings and enable SMB 2/3.
2. Verify Windows features — Open Windows Features and confirm SMB Direct is present, and that SMB 1 is off unless required.
3. Enable SMB 1 client if forced — In Windows Features, tick SMB 1.0/CIFS Client, restart, then test the share.

If enabling SMB 1 fixes it, treat that as a clue that the other device is outdated. Plan a safer fix by updating the device or switching it to SMB 2/3. Keeping SMB 1 on long term raises risk on a network that connects to the internet.

Fix Sign-In, Guest Access, And Stored Credentials

Many “path not found” cases are really sign-in failures that get reported poorly. Recent Windows builds often refuse guest fallback for SMB shares. That means a share that used to open with no username can stop working after a Windows update or a device reset.

If you see a username prompt, treat it as progress. You reached the target. Now you need the right account and a clean credential state on the client.

1. Create a matching user — On the host, make a local user with a password, then give that user share and NTFS permissions.
2. Clear saved passwords — Open Credential Manager, remove saved entries for the host name and IP, then try again.
3. Map with explicit credentials — Use Map network drive and check “Connect using different credentials,” then sign in with HOST\\username.
4. Test with run — Press Win+R and enter \\\\HOST\\Share to force a fresh connection attempt.

Permissions come in two layers. Share permissions control the network entry, and NTFS permissions control the folder once you’re in. If one allows access and the other blocks it, you may see odd failures or empty folders. For quick testing, grant the user Read on both, then tighten later.

Include the host name in the username when needed. Some systems accept username, others want HOST\\username. If the host is a NAS, it may want the NAS user name exactly as created in its admin page.

Once it works, keep the setup simple. Avoid anonymous shares on mixed devices. A basic local account with a strong password is often the smoothest option.

Firewall, Services, And The Stuff That Quietly Breaks Sharing

File sharing needs a few Windows services running and a few firewall rules allowed. Third-party security suites can also block SMB traffic even when Windows settings look fine. This section is the “nothing else worked” set, and it fixes a lot of stubborn cases.

Allow File And Printer Sharing through the firewall

1. Open firewall settings — Search for Windows Defender Firewall, then open Allow an app through firewall.
2. Enable sharing rules — Ensure File and Printer Sharing is allowed on Private networks.
3. Pause third-party security — Temporarily disable the suite, test the share, then turn it back on.

Check the services that SMB depends on

1. Open Services — Press Win+R, type services.msc, and press Enter.
2. Start Workstation — Ensure Workstation is Running and set to Automatic.
3. Start Server — Ensure Server is Running on the host PC and set to Automatic.
4. Start Function Discovery — On both PCs, start Function Discovery Provider Host and Function Discovery Resource Publication.

Reset the network stack when things feel “stuck”

If pings work but SMB fails, a reset can clear a corrupted stack or a broken binding. It’s safe, but it will drop and rebuild network adapters, so plan to reconnect to Wi-Fi after.

1. Run network reset — Settings > Network & internet > Advanced network settings > Network reset, then restart.
2. Reset TCP/IP — In an admin Command Prompt, run netsh int ip reset, restart, then test.
3. Reset Winsock — Run netsh winsock reset, restart, then test the share again.

Print-This Checklist For Next Time

When you see 0x80070035 the network path was not found, run this list from top to bottom. Stop when it works. The order is tuned to catch the high-frequency causes first without sending you into long settings hunts.

1. Re-check the UNC path — Confirm the share name and try \\\\IP\\Share once.
2. Confirm Private profile — Set both PCs to Private, then turn on discovery and file sharing.
3. Ping both ways — Ping host name and IP from the client, then ping the client from the host.
4. Clear cached credentials — Remove entries in Credential Manager for the host and try again.
5. Use a real account — Create a user with a password on the host or NAS, then map the drive with it.
6. Check SMB compatibility — Prefer SMB 2/3; enable SMB 1 client only if you have no other path.
7. Verify services and firewall — Start Workstation/Server and allow File and Printer Sharing on Private.
8. Reset network stack — Use Network reset, then netsh resets if the failure still repeats.

If the share still won’t open after the checklist, test from a second client device. If the second device can reach it, the issue is local to the first PC. If no device can reach it, the issue is on the host or the network gear.

Once you get access back, write down what fixed it. Even a short note like “needed credentials” or “NetBIOS was off” saves time the next time 0x80070035 the network path was not found shows up during a busy moment.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback