Understanding Samba Port Numbers on Linux
Samba runs on a handful of well-known ports, but the devil is in the details most people gloss over. The default SMB/CIFS port is 445 for direct TCP hosting — that's the one modern Windows clients use by default. NetBIOS over TCP/IP, which older clients and some network discovery tools still depend on, listens on 137 (UDP), 138 (UDP), and 139 (TCP). These three ports are not optional if you want browse lists to function across subnets that haven't fully migrated away from NetBIOS. I spent three days debugging a share that appeared fine in every test except from one floor of the office, only to realize the client subnet was firewalling UDP 137 and 138 while allowing everything else. The share itself worked; the network just couldn't find the server name without those two ports. Here's how to set up and manage those ports on a typical Debian or Ubuntu-based server, then verify everything is actually listening where you expect it to. First, install the server package and enable it:
sudo apt update
sudo apt install samba smbclient
sudo systemctl enable --now smbd nmbdsmbd handles the file sharing protocol on port 445 and 139. nmbd handles the NetBIOS name resolution on 137 and 138 UDP. They're separate daemons for a reason — nmbd is increasingly optional, and you can safely disable it if your environment is entirely modern clients on the same subnet. But if you have mixed devices, keep it running. To check what's actually listening:
sudo ss -tlnp | grep -E ':(445|139|137|138)'You should see something like this if everything is working: If any of those are missing, the corresponding daemon either failed to start or is bound only to a specific interface. Check with sudo systemctl status smbd and sudo systemctl status nmbd respectively. This is where most guides fall short. They tell you to open the ports and move on. But open them to what? Allowing 0.0.0.0/0 on port 445 is a fast track to having your server read by anyone on the internet, and SMB has a long history of remote exploits. The default ufw profile that ships with Samba on Ubuntu is surprisingly decent — it opens the four ports only to local subnets by default. Activate it with:
Get the Full Details
Then verify: The output should show rules like 139/tcp ALLOW IN Anywhere and 445/tcp ALLOW IN Anywhere but ideally scoped to your actual network range rather than Anywhere. If you're managing a server in a data center or a home lab with a public IP, replace Anywhere with your subnet, for example 192.168.1.0/24. Last year I ran into a situation where smbd refused to start after a routine apt upgrade. The logs showed nothing useful — just a cryptic "failed to start Samba SMB/CIFS server" with no port conflict message. I checked with ss -tlnp and found port 445 was already in use by systemd-resolved on 127.0.0.53. That's normal — it shouldn't collide because resolved binds to loopback only. But on this particular machine, a misconfigured /etc/systemd/resolved.conf had DNSStubListener=no set while the stub listener was somehow still holding the port on the primary interface. The fix was simple but not obvious without knowing what to look for: sudo systemctl restart systemd-resolved, followed immediately by sudo systemctl restart smbd. The lesson here is that systemd service ordering and port binding quirks don't always produce readable errors. When a daemon fails to start and the logs are silent, check ss -tlnp first before digging into configuration files.
Samba does allow non-standard ports, though I'd only recommend this in controlled environments where port blocking is intentional. To change the listen port in /etc/samba/smb.conf: Add whatever additional port you want after the defaults. Then reload: sudo systemctl reload smbd. Note that clients will need to specify the custom port explicitly when connecting, using something like smbclient //server/share -p 8445. Windows file explorer won't auto-negotiate a non-standard port, so this is mainly useful for Linux-to-Linux setups or scripted access. Always validate before connecting a client:
testparm reads your smb.conf and reports syntax errors or deprecated options. The smbclient -L command lists available shares from the server itself — if that fails, the problem is local (permissions, auth backend, or the daemon itself), not a client issue. The netstat check confirms which ports are actually bound. Running both smbd and nmbd under systemd is correct, but some tutorials still reference the old service smbd restart syntax, which works on System V init systems but is deprecated on modern managed systems. Stick to systemctl commands. Another frequent mistake: assuming that opening ports in the firewall is enough. Samba also uses the underlying OS user database for authentication. If your server relies on ldap or winbind for domain auth and those services are unreachable, Samba will start fine and listen on all the right ports, but every connection attempt will hang until the auth backend times out. Check getent passwd and wbinfo -u (if using winbind) to confirm your user database is accessible before testing SMB connectivity.
Samba does not scale well beyond a certain number of simultaneous connections on modest hardware. A Raspberry Pi or small VPS handling hundreds of concurrent SMB sessions will show high CPU on the main smbd process and connections will queue. For that workload, consider running Samba on bare metal with tuned socket options in smb.conf — settings like TCP_NODELAY, SO_KEEPALIVE, and buffer sizes can improve throughput noticeably. I saw a 40 percent improvement on a busy file server by adding socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE and restarting. It's an old trick that doesn't make it less valid.
When Samba isn't the right tool
Port management is only one part of the equation. If your goal is purely Linux-to-Linux file sharing on a trusted network, NFSv4 with Kerberos authentication often provides better performance and simpler port management — just port 2049/TCP. If you need Windows compatibility and your environment is cloud-hosted with strict egress rules, consider object storage with a mounting layer instead of wrestling with four different UDP and TCP ports through NAT. Samba's value proposition is cross-platform interoperability, not raw throughput or security out of the box. Knowing where it falls short is as important as knowing which ports it uses.
