2

I want to access a windows PC's (192.168.44.1/24, WinXP, lets call it server ;-) ) file share from another PC (192.168.54.110/24, Win 10 Pro, lets call it client). There is also a MacBook next to the client in 192.168.54.x.

(The WinXP box's only intention is testing SMB access in this lab setup, no production use of course.)

The router/firewall inbetween acts as DNS server at 192.168.54.1.

What works as expected on the client:

ping server
ping server.fqdn
net view \\192.168.44.1

Also, I can mount "cifs:\\server.fqdn" successfully on the MacBook.

But entering \\server.fqdn in Explorer fails, and

net view \\server
net view \\server.fqdn

both fail with error "53 The network path was not found".

I rule out a DNS problem since ping works with hostname. I rule out a firewall issue because it works using the IP adress, and because it works on the MacBook.

To me it looks like a client issue.

I have disabled AV/firewall software. I tried adding server.fqdn to the hosts and LMHOSTS files on client, no success. Does the server need to be able to resolve client's name via DNS to respond properly? Do I need matching ptr records?

I do not (want to) have a Wins server. Can that be the problem?

3
  • 2
    Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that? Jan 18, 2019 at 9:12
  • Try to flush a DNS cache on the client.
    – montonero
    Jan 18, 2019 at 9:14
  • @grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
    – Philippp
    Jan 20, 2019 at 17:59

1 Answer 1

2

Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.

To disable this checking entirely, add a registry key server-side:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"DisableStrictNameChecking"=dword:00000001

(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)

This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).

It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.

1
  • 1
    That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
    – Philippp
    Jan 24, 2019 at 9:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .