Empty Network Browse List After Disabling NetBIOS
A small accounting firm runs a standalone Samba 4.19 file server, fs01, on Debian 12. The smb.conf sets workgroup = OFFICE, security = user, passdb backend = tdbsam, disable netbios = yes, and server min protocol = SMB2_10. DNS resolves fs01.office.example to 192.168.50.10; there is no WINS server. Windows 11 23H2 clients can open //fs01.office.example/accounts and authenticate with local Samba accounts, and smbclient -L fs01 -U alice lists the shares. However, File Explorer's Network view shows no FS01 icon. A legacy Windows 10 1809 laptop also cannot browse the workgroup, although its UNC path works. smbd and nmbd are both running; the firewall allows TCP 445 and 139 plus UDP 137-138. Users want the server visible in Network without mapping a drive. The administrator prefers not to re-enable SMB1.
1. Why can the clients reach the share by UNC path while the Network browse list is empty? Identify the protocols and services involved and explain why smbclient -L still works.
Read the worked answer
UNC access uses SMB over TCP 445 (or 139) and DNS name resolution; it does not require a browse list. The Network view depends on discovery: modern Windows primarily uses WS-Discovery (multicast UDP 3702 and HTTP metadata), while older Windows and workgroup browsing rely on the NetBIOS browse list maintained by nmbd. With disable netbios = yes, nmbd cannot provide a NetBIOS browse list, so the legacy laptop sees an empty workgroup. smbclient -L is not a browse-list query; it opens an SMB session to the server and enumerates shares via the IPC$ service, so it works whenever SMB and authentication work. The running nmbd process does not prove browsing is functional if NetBIOS is disabled in smb.conf.
2. What checks would you run to confirm the cause before changing the configuration?
Read the worked answer
Confirm effective parameters with testparm -sv | egrep 'disable netbios|server min protocol|workgroup|local master|preferred master'. Check whether nmbd is actually bound: ss -lunp | grep ':137' and systemctl status nmbd. Capture discovery traffic while opening Network: tcpdump -ni any 'udp port 137 or udp port 138 or udp port 3702'. If you see no 3702 and no 137/138, discovery is absent. Check firewall rules for UDP 137-138 and 3702, and check whether a WSD daemon such as wsdd is installed and listening. Test direct name resolution with getent hosts fs01.office.example and smbclient -L fs01 -U alice. Also verify no WINS server is configured on the clients. These checks separate a name-resolution failure from a discovery-protocol failure.
3. Recommend a fix that restores visibility with the least security risk, and state the trade-offs.
Read the worked answer
Keep SMB2_10 minimum and NetBIOS disabled, and add a WS-Discovery responder such as wsdd or wsdd2 on fs01, configured for workgroup OFFICE. Allow UDP 3702 and the WSD HTTP port, typically TCP 5357, only from the local client VLAN. Modern Windows 11 will then discover fs01 without SMB1. Trade-offs: WSD adds a daemon and multicast traffic, and some very old clients that rely only on NetBIOS browse lists still will not see the server; for those, use a DNS name or a mapped drive. Re-enabling NetBIOS with disable netbios = no, starting nmbd, and allowing UDP 137-138 is the alternative, but it restores legacy discovery and a larger attack surface, and it may still not satisfy clients expecting SMB1 browsing. A documented DNS alias and drive mapping is often the most reliable fallback.