SMB — Can't Connect, Wrong Password, or Silent Refusal

SMB — Can’t Connect, Wrong Password, or Silent Refusal

Search terms: samba can’t connect · NT_STATUS_LOGON_FAILURE · NT_STATUS_INVALID_NETWORK_RESPONSE · hosts allow · smbclient · password keeps failing · works locally not remotely · usershare · smb:// won’t open · net usershare

Solved 2026-08-09. Symptom: a share the server was clearly publishing refused every connection from another machine, with the correct password. Cause was hosts allow pointing at a subnet that stopped existing when the router was replaced.

Diagnostic ladder

Work down. Each rung eliminates a layer, and the rung that fails tells you where to look.

# 1. Network reachable at all?
ping -c2 <server>

# 2. Are the SMB ports even open?
for p in 139 445; do timeout 3 bash -c "echo >/dev/tcp/<server>/$p" 2>/dev/null \
  && echo "$p OPEN" || echo "$p closed"; done

# 3. Is smbd listening on the LAN, or only loopback?     [ON THE SERVER]
sudo ss -tlnp | grep -E ":(139|445)"     # want 0.0.0.0:445, not 127.0.0.1:445

# 4. Does it work FROM the server itself?                [ON THE SERVER]
smbclient //localhost/<share> -U <user> -c 'ls'

# 5. Does it work from the client?                       [ON THE CLIENT]
smbclient //<server>/<share> -U <user> -c 'ls'

Steps 4 and 5 are the important pair. Local works but remote fails = the problem is access control, not credentials and not the share.

The trap: smbclient -L is not a connection test

smbclient -L <server> -U <user>     # lists shares
smbclient //<server>/<share> -U <user> -c 'ls'   # actually OPENS one

These have different requirements. Listing talks to IPC$; opening talks to the share. A server can happily list shares for you and then refuse every one of them.

Real sequence from the 2026-08-09 incident, same machine, same user, minutes apart:

smbclient -L localhost -U aztechguy          -> lists plex1, plex2   (worked)
smbclient //localhost/plex1 -U aztechguy     -> NT_STATUS_LOGON_FAILURE

That looked like proof the password was right. It wasn’t proof of anything.

Check whether a listing really authenticated by deliberately using a wrong password:

smbclient -L <server> -U <user>%definitelyWrong123

If it still lists shares, the listing was anonymous and tells you nothing about credentials. If it fails, listing does authenticate on this server — and a successful listing is meaningful. Test it rather than assuming; it goes both ways depending on config.

Error decoder

Error Means Look at
NT_STATUS_LOGON_FAILURE Credentials rejected Samba password (separate from the Linux one)
NT_STATUS_INVALID_NETWORK_RESPONSE Handshake failed before auth hosts allow, firewall, protocol mismatch
NT_STATUS_BAD_NETWORK_NAME Share doesn’t exist Share name, testparm, usershares
NT_STATUS_ACCESS_DENIED Authenticated, then refused Filesystem perms, valid users, share ACL
Host is down / Server abruptly closed Connection dropped Wrong host, or a server mounting itself

The distinction that matters most: LOGON_FAILURE happens after credentials are offered. INVALID_NETWORK_RESPONSE happens before. If you see the second one, stop testing passwords.

The actual cause: hosts allow on a dead subnet

testparm -sv 2>/dev/null | grep -iE "hosts allow|hosts deny|interfaces|bind interfaces only"

hosts allow = 192.168.1.0/24        <- the LAN is 10.0.0.x

Samba silently drops connections from anywhere else — before authentication, which is why the client saw a protocol error and not a password error. Loopback is implicitly permitted, so everything looked healthy from the server itself.

This was set years earlier while hardening the box, and became wrong the day the mesh router was replaced and the LAN moved from 192.168.1.x to 10.0.0.x. The NAS mounts broke visibly and got fixed; hosts allow broke invisibly and didn’t.

Fix — replace the whole line, no backreference:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak-$(date +%F)
sudo sed -i 's|^[[:space:]]*hosts allow[[:space:]]*=.*|   hosts allow = 10.0.0.0/24 127.0.0.1|' /etc/samba/smb.conf
testparm -s 2>/dev/null | grep -i "hosts allow"
sudo systemctl restart smbd

Avoid sed 's|...|\1<digits>|'. A backreference immediately followed by a digit — \110.0.0.0/24 — is genuinely ambiguous to read and can be parsed as backreference 11. It happens to work in GNU sed, but a command you can’t verify at a glance shouldn’t run as root. Replace the whole line with literal text instead.

Shares that don’t appear in smb.conf

testparm showed only [printers], [print$] and [plex2] — but smbclient -L also listed plex1. Both were real.

plex1 was a usershare — created through a file manager’s “Share this folder”, stored outside smb.conf entirely:

net usershare info --long
ls -la /var/lib/samba/usershares/
sudo cat /var/lib/samba/usershares/*

[plex1]
path=/media/4ce8b8b4-...
usershare_acl=S-1-1-0:F      # S-1-1-0 = "Everyone"
guest_ok=n

usershare owner only = Yes (the default) means the share is only honoured while the path is still owned by whoever created it. A usershare made years ago can stop working after an ownership change with no config edit and no log entry.

So: testparm alone does not tell you what a server is sharing. Check usershares too.

Samba passwords are a separate database

A Linux account existing in /etc/passwd does not mean Samba can authenticate it.

sudo pdbedit -L          # which users Samba actually knows
sudo smbpasswd -a <user> # set/reset the Samba password

They start out identical if you set them together, and drift the moment either changes. Years later “the password is definitely right” is true of the Linux one and false of the Samba one.

Don’t mount a server’s own share back onto itself

mount error: Server abruptly closed the connection.
mount error(112): Host is down

Running mount -t cifs //<its-own-ip>/share on the machine running smbd is both pointless — the path is already local — and a known deadlock risk between the kernel CIFS client and smbd on the same host. If you see that error, check which machine you’re actually on first.

When juggling three machines, label every command with its target before running it.