Windows file explorer using port 80 (webdav) instead of 445 (samba smb cifs) for UNC path

Question

I have a Windows 7 Ultimate x86_64 machine, which is failing to access a network samba server. I launch the "Run" dialog, and type in \\192.168.x.x so I am bypassing DNS and NetBIOS name resolution, and broadcast discovery, just going directly to the server IP address. I ran wireshark and found that the client is trying to connect to the server on port 80, not 445. (This of course fails because the server is not listening on 80; the server is only running samba and nmbd etc, so only port 445 and 137-139 are applicable).

I am aware of this question and I don't believe this is a duplicate, because (a) that question is over 2 years old, on Win XP, and (b) none of the answers there are helping in this case, although that other question has been marked as answered.

The error message is: Windows Cannot Access \\192.168.x.x and when I click "See Details" it says Error Code 0x800704cf The network location cannot be reached

I confirmed that Client for Microsoft Networks is present, and enabled. I even removed it (was forced to reboot) and reinstalled it. No effect.

I disabled IPv6, no effect.

I confirmed the WebClient service is not running. (It is set to Manual, and it's not Running).

I confirmed the TCP/IP NetBIOS Helper service is running. (It is set to Automatic, and it's Running.)

Of course I have rebooted and retried. (Several times and several ways).

The problem seems to exist with an old patch level, and also continues to exist after applying all Windows Updates.

Why would Windows attempt to use port 80 (webdav) instead of port 445 (samba/smb/cifs) to connect file explorer to a UNC path?

net view 192.168.x.x throws an error message on the affected client:

C:\Windows\system32>net view 192.168.x.x
System error 53 has occurred.

The network path was not found.


C:\Windows\system32>ping 192.168.x.x

Pinging 192.168.x.x with 32 bytes of data:
Reply from 192.168.x.x: bytes=32 time<1ms TTL=64
Reply from 192.168.x.x: bytes=32 time<1ms TTL=64

But works fine on another client:

C:\Users\eharvey>net view 192.168.x.x
Shared resources at 192.168.x.x

netfiles server (Samba, Ubuntu)

Share name  Type  Used as  Comment

-------------------------------------------------------------------------------
myshare     Disk           My Company data storage
The command completed successfully.

Solution

If the packet capture shows no attempt over 445 whatsoever then that would indicate the client is trying WebDav first. This could be because WebDav higher in the Network Provider Order. To check that:

• Open Network Connections
• Advanced menu
• Advanced settings...
  
• Provider Order tab
• Ensure Microsoft Windows Network is higher than Web Client Network
  

Comments

[Edward Ned Harvey]

I already reformatted the system so I cannot confirm or deny if this solved the problem for me. I can confirm I never heard of this until you answered, and I can confirm that on functional systems, the order I have is: Microsoft Windows Network before Web Client Network.

[NukaRakuForgotEmail]

Have a similar issue and could confirm that this was not the fix---the Microsoft Windows Network was already before Web Client Network.

[iSee]

This looks like a duplicate of @DC_LDN's answer.