The scenario: a simple home network. At its core it consists of:
- an ADSL 4port wireless router. Acting as a DHCP server. (running dd-wrt)
- An Ubuntu server, running Samba, as a NAS.
- a mix of other linux based or windows based clients.
My biggest problem is, I don't really understand how Windows (and Linux) boxes do name resolution for SMB shares on an TCP/IP network anymore.
As near as I can tell, the only name resolution service I really have going here is DNSMasq – provided with the wireless routers DHCP service – which lets all my dhcp registered devices resolve each other using dns queries.
This is not ideal as, if the dhcp server reboots it looses its DNSMasq entries until the various hosts dhcp reservations expire and they re-query.
I tried to setup things a bit more robustly, added a .local domain suffix to the dhcp server, and turned on a WINS server on the NAS box, but the NAS box promptly disappeared from any SMB/workgroup enumerations. I can still ping it, and ssh to it, but trying to browse to it, or navigate directly to it (smb://server or smb://server.local) all error out.
How does SMB name resolution actually work? Such that I can decouple it from my DHCP/DNSMasq experiments.
Best Answer
SMB is a network file sharing protocol so there isn't a name resolution mechanism that is specific to SMB/CIFS shares. Name resolution for SMB/CIFS is dependent on the client and it's configured name resolution mechanisms (DNS, WINS, broadcast, etc) and order and is dependent on whether you're using an FQDN or a single-label name.
In the absence of a DNS or WINS server, Windows clients will use NetBIOS broadcasts (if NetBT over TCP is enabled) to attempt to resolve names. Windows Vista, 7, and W2K8 clients will also use LLMNR for local name resolution.
Without getting in to all the gory details about how and in what order Windows clients resolve host names, I might suggest you implement a more robust DNS server internally, such as Windows DNS.