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.

Answer 1

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
  

Answer 2

I am aware that you have tried to reinstall client for Microsoft networks but if you don't need it then do the following on each client:

1. Open 'Network Connections'.

2. On each adapter you wish to connect to the samba share:

3. Right click and choose 'Properties' Untick 'client for Microsoft networks'

4. Navigate to: Network Connections > Advanced > Advanced Settings > Adapters and bindings

5. Verify that 'client for microsoft networks' is now at the botton and is unchecked

6. Now go to the Provider order tab and ensure that 'Web Client Network is at the bottom of the list of network providers.

7. reboot the computer and try connecting to the host again.

You could also try blocking port 80 or redirecting it to port 445.

Answer 3

You should check your "TCP/IP NetBIOS Helper" service. When this service crashed and Web Client exist, it will try to access UNC Path on WebDAV( tcp port 80 ).

Restart "TCP/IP NetBIOS Helper" service , then tcp port 445 is been used for UNC Path.

Same problem at Microsoft TechNet: connecting to file share on port 80?

Answer 4

I ran into this situation (net use falling back to WebDAV instead of using SMB3), I catalogued my saga diagnosing and fixing it here: https://twitter.com/MissQuickstep/status/1413291157921087489

TL;DR; for my situation, it turned out to be an errant windows firewall rule causing SMB3 to fail (but not to be blocked -- you won't find blocked packets in the Windows Defender firewall log!).

In my case, the cause seems to potentially have been a GPO bug of unknown provenance.

If you are running into the same issue I was, you have two options (depending upon your goals/priorities):

1. Disable the Secure version of the Windows Firewall rule for SMB-Out.
2. Follow the directions here: https://support.microsoft.com/en-us/topic/preventing-smb-traffic-from-lateral-connections-and-entering-or-leaving-the-network-c0541db7-2244-0dce-18fd-14a3ddeb282a (and ensure that you get the IPSec connection working properly).

Answer 5

I am pretty sure that i had jump into the same exact problem like you. And I was lucky, because it has been solved. But I'm not quite sure which step did the trick for this issue. (Because it just solved when my pc reboot and up)

*Note: without these sections, rebooting will not solve anything And here is what I've done: - Delete all ip6 Tunnel Adapter (uninstall one by one using Device Manager) - Disable ip6 using regedit - Enable NetBIOS over TCP/IP - Uninstall - Install "Client for Microsoft Networks" - Disable ip6 in Network Adapter Properties - Turn off Firewall+AV (Both Client n Server) - Remove any network interface sharing (if configured) - Remove Microsoft Network Bridge (if any) - Disabled all Network Interface (except the one that you will use to connect) - reboot

I hope I don't miss something here, Sorry I didn't document my work back there. Need your feedback if my solution work, Thank you.