A particularly stubborn case of "0x80070035 Network path not found"

Question

I too must hang down my head in shame and admit defeat in the face of the "0x80070035 Network path not found"... the one from most of these 63 related posts...

So, I have a LAN segment with two PCs, PC-A and PC-B connected via Ethernet over RJ-45 cables, through a switch. Addresses are both in 192.168.0.0/24.

Both PCs:

• Run Windows 10, recently updated.
• Have File Sharing enabled for private networks.
• Have the connection marked as private/trusted.
• Have password-based sharing disable.
• Have some shared folders.
• Have the Windows Defender Firewall on.
• Can see each other's names in the "Network" pane of Windows Explorer.
• Have The inbound rule for File and Printer Sharing (SMB-In) enabled.

However, PC-1 may have had all sorts of settings changes made to it in the past, while PC-2 has just been installed with Windows 10.

The symptom: From PC-1, I can click PC-2's icon and see its shares (and their contents); from PC-2, when I click PC-1's icon, I get an error dialog saying Windows cannot access \PC-1 , with the details saying 0x80070035 Network path not found.

I've tried following most of the advice in the answers to the highest-voted related question:

Shares not accessible by other computers if Windows 10 firewall is ON

• Manually added a rule to the firewall to open TCP port 445 to anyone.
• Explicitly added the relevant IPv4 address range to the "File and Printer Sharing (SMB-In)" firewall rule
• Expanded the scope of the NB-Name-In and NB-Session-In to packets from any machine.
• Verified the connection is set to private.
• Did not try the sc.exe config command because I have no idea what that would do, and a comment asking what that does was not answered.
• Restored all firewall settings to default and re-enabled File & Printer Sharing.

... and these actions did not resolve the problem. What else can I try in order to resolve this issue?

Answer 1

I also had the 0x80070035 error. After three days of searching, I found the solution in the following registry keys:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]

You should see:

“Auth132″=”IISSUBA”
“NtlmMinClientSec”=dword:00000000
“NtlmMinServerSec”=dword:00000000
“RestrictReceivingNTLMTraffic”=dword:00000002
“RestrictSendingNTLMTraffic”=dword:00000002

Delete these last 2 entries:

“RestrictReceivingNTLMTraffic”=dword:00000002
“RestrictSendingNTLMTraffic”=dword:00000002

Answer 2

If you are not averse to trying SMB 1.0, consider turning it on. It has fixed this issue for me in the past.

1. In Control Panel, select Programs, and then Programs and Features.
2. Click "Turn Windows features on or off" to open the Windows Features box.
3. In the Windows Features box, scroll down the list, and expand the checkbox for SMB 1.0/CIFS File Sharing Support.
4. Check the boxes for Client and Server settings here.
5. Click OK.

Be forewarned that SMB 1.0 has been superseded by newer versions that improve its security, but if you are in a safe LAN with a router that you've already hardened, you might feel more safe to turn it on.

I was then able to use the following command on a CMD prompt to establish a drive letter to my second computer network file share (in my case, a Public folder):

net use V: \\192.168.1.24\Public /PERSISTENT:YES

Note the use of my computer's static IPv4 address as opposed to its Windows hostname. That will avert the dreaded, "System error 64 has occurred."