Windows can't find '\' network path error fix

You're sitting at a Windows 10 or 11 machine, trying to connect to a shared folder on another PC. You type \\ServerName\Share into File Explorer's address bar. After a long pause, you get: "Windows cannot access \\ServerName. Check the spelling of the name. Error code: 0x80070035. The network path was not found."

I see this at least once a month, usually in small offices where someone set up a new PC or updated Windows. It's rarely a hardware issue. The network cable's fine, the switch is blinking, both machines can ping each other's IPs – but the name lookup fails. Had a client last month whose entire print queue died because of this – the printer shared from a Windows 10 box wouldn't show up on a newer Windows 11 laptop. Same error.

Root cause in plain English

The error 0x80070035 means Windows tried to resolve the computer name to an IP address, but couldn't find it. Or it found the IP, but the SMB protocol version didn't match. Modern Windows (10 and 11) defaults to SMB 3.0. Older machines, or some NAS devices, only speak SMB 1.0 or 2.0. Microsoft turned off SMB 1.0 by default after the WannaCry ransomware attack in 2017 – good security move, but it breaks connections to legacy devices.

The second big reason? DNS. Windows uses DNS to resolve computer names on your local network. If the DNS server (usually your router) doesn't have the machine's hostname, or if the client isn't using the right DNS suffix, name resolution fails. NetBIOS over TCP/IP can sometimes step in, but it's flaky on modern networks.

Fix: step-by-step

Try these in order. Don't skip steps – I've seen people waste hours on registry tweaks that didn't fix the real problem.

Step 1: Check basic connectivity

Open Command Prompt as admin. Run:

ping ServerName

If it resolves to an IP and you get replies, skip to Step 2. If it says "Ping request could not find host", run:

ping 192.168.1.100

Replace the IP with the target machine's actual IP. If that works, you have a name resolution problem – go straight to Step 3. If it doesn't work, check the physical network: cables, switch ports, firewall settings on both machines. Turn off Windows Defender Firewall temporarily to test – if it works then, you need to set up file and printer sharing exceptions.

Step 2: Enable SMB 1.0 (only if absolutely necessary)

This is the nuclear option. Only do it if the target machine is ancient – like Windows 7 or an old NAS that refuses to update. It's a security risk, so turn it off after you're done.

1. Open Control Panel > Programs > Turn Windows features on or off.
2. Check SMB 1.0/CIFS File Sharing Support.
3. Click OK and restart.

Try the network path again. If it works, you have a legacy device problem. If not, uncheck it – security risk isn't worth it.

Step 3: Force DNS resolution with a hosts file entry

This is the quickest fix for name resolution issues. Edit the hosts file on the client machine:

1. Open Notepad as administrator.
2. Go to C:\Windows\System32\drivers\etc\hosts.
3. Add a line at the bottom: 192.168.1.100   ServerName
4. Save and close.

Now try \\ServerName\Share again. This forces Windows to map the name to that IP, bypassing DNS entirely. Had a client with a QNAP NAS that kept dropping its DNS registration – this fixed it instantly.

Step 4: Enable Network Discovery and turn off password-protected sharing

This is common on new Windows installs. Network Discovery is off by default on public networks.

1. Open Control Panel > Network and Sharing Center > Advanced sharing settings.
2. Select Private profile.
3. Turn on Network discovery and File and printer sharing.
4. Scroll to All Networks and turn off Password protected sharing (unless you need it).

Restart the client machine. Try the network path again.

Step 5: Check the target machine's firewall

On the machine hosting the shared folder, open Windows Defender Firewall with Advanced Security. Look for inbound rules for File and Printer Sharing (SMB-In). Make sure it's enabled for Private profiles. If it's missing, create a new rule: Port 445 TCP.

What to check if it still fails

If none of that works, you're looking at deeper issues:

• Workgroup mismatch: Both machines must be in the same workgroup (default is WORKGROUP). Check in System Properties.
• User credentials: The user account on the client must have permissions on the target machine. Try using \\IP\Share instead of name – if that works, it's still a name resolution problem even after the hosts file.
• Router settings: Some routers block NetBIOS or mDNS. Check if WINS or LLMNR is enabled. On the target machine, run ipconfig /all and look for Node Type – it should be Hybrid or Broadcast, not P2P.
• Windows 11 specific: Microsoft changed network behavior with Win11 22H2. Turn off Network List Manager Policies in Group Policy if you're on a domain. For home users, try disabling IPv6 – I've seen it interfere with name resolution on home routers.

One last thing: if the shared folder is on a NAS or a Linux box, check that SMB 2.0 or 3.0 is enabled. Some old Linux Samba configs default to SMB 1.0. You'll get this error even if everything else is perfect. Upgrade Samba to version 4.15 or later, and set server min protocol = SMB2_02 in smb.conf.