“53 Network path was not found” when trying to access \\fqdn, but \\IP works fine

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?

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.