Learn Samba - Testing & Troubleshooting

#Introduction

So far you've built, secured, and protected. Episode 16 is the "life as an administrator" episode: when nothing works. Samba's complexity — files, authentication, DNS, permissions, SELinux — produces baffling errors when handled without a method. Here you get a diagnostic toolkit and a debug sequence that leads from symptom to root cause, instead of guessing.

#Diagnostic Toolkit

#testparm: Configuration Validation

This is the first step in any incident. A mis-syntactical configuration makes every other symptom misleading:

Validate and show the effective configuration

testparm -s | less

testparm -s prints the configuration that's actually used (not the one you think you wrote). The difference between the file and the output shows which parts are affected by defaults or which lines are wrong — the classic "why is it different?" source.

#smbclient -L: Connectivity and Visibility Test

smbclient is the quick tester for whether the server is reachable and shares are published:

List shares from a client

smbclient -L //fileserver -U arman -m SMB3

-m SMB3 forces a specific dialect — if the connection fails only with SMB3, there's a protocol negotiation problem; try without -m to see the agreed dialect (revealing a wrong server min/max protocol).

#smbstatus: Inspecting Active Connections

When clients complain "slow" or "can't open a file", look at the server side:

View connections, open files, and locks

smbstatus
smbstatus -L   # share yang sedang diakses
smbstatus -b   # detail sesi

smbstatus shows who's connected, which files are open, and which locks are held — an instant answer to "which user has this file locked?".

#net ads testjoin: Verifying Domain Trust

For a domain member (episode 10), the machine's trust with the DC can silently break:

Test domain membership

net ads testjoin

Success means the trust is valid; NT_STATUS_* means there's a problem — usually the computer password (machine account) is out of sync or DNS is wrong. Fix by re-running net ads join or net ads reset-account.

#samba-tool domain info: Checking the DC and Domain Level

For AD environments, check connectivity and domain health from the DC side:

Domain info from the DC

sudo samba-tool domain info 127.0.0.1
sudo samba-tool domain level show

domain info shows the domain name, forest, and functional levels — the first sign that the samba DC daemon is alive and the internal DNS works.

#Debugging: log level

#Finding Answers in Logs

Symptoms give direction; logs give answers. Raise verbosity for the relevant categories:

/etc/samba/smb.conf [global] — debug log

[global]
   log level = 3
   log file = /var/log/samba/log.%m
   max log size = 1024

log level = 3 shows connection details, dialect negotiation, and auth decisions. Default level 1 is errors only; level 10 floods. Test with a connection from one client, then read that client's dedicated log:

Read a per-client log

sudo tail -100 /var/log/samba/log.budi-laptop

Tip

The golden troubleshooting rule: change one variable, test, read the log. Turning on log level = 10 and changing many configurations at once means you won't know which one solved the problem. Raise the level, reproduce the problem, lower the level, fix the config — methodical, not panicked.

#Common Cases and Solutions

#1. DNS

Symptoms: net ads join fails, Windows clients get "Path not found", the DC isn't found. The cause is almost always DNS — AD SRV records are missing or clients use the wrong DNS. Diagnose:

Check AD SRV records

host -t SRV _ldap._tcp.lab.local
dig +short SRV _kerberos._udp.lab.local

Fix: point clients at the correct DNS (the DC for AD, or a forwarder that points to the DC). On standalone, make sure fileserver resolves to the right IP in /etc/hosts or LAN DNS.

#2. Time Skew

Symptoms: domain login fails with KDC has no support for encryption type or Clock skew too great. Kerberos rejects a connection when the clock difference exceeds the tolerance (usually 5 minutes). Check:

Check the time difference

date; ssh fileserver date
timedatectl

Fix: enable NTP/chrony on all hosts (episode 0). Even a few seconds of drift can be enough to trigger an error — don't underestimate it.

#3. Permissions

Symptoms: "Access denied" even though the configuration looks correct. Remember the two permission layers (episode 4). Test directly at the filesystem:

Test filesystem access as a user

sudo -u arman touch /srv/data/test
getfacl /srv/data

If sudo -u arman touch fails → the problem is the filesystem (mode, owner, ACL), not Samba. If it succeeds but the client is still denied → the problem is share options (valid users, write list).

#4. SELinux/AppArmor

Symptoms: smbd runs but shares are inaccessible, or a Permission denied appears in the kernel log even though filesystem permissions are correct. Distributions with SELinux (RHEL family) and AppArmor (Ubuntu/Debian) lock down Samba with their own policies. Check and fix:

SELinux — contexts and booleans

sudo ausearch -m avc -ts recent | grep smbd
sudo setsebool -P samba_enable_home_dirs on
sudo restorecon -Rv /srv/data

AppArmor — smbd profile

sudo aa-status | grep smbd
sudo journalctl | grep -i "apparmor.*smbd"

If the policy blocks access to your share directory, add permissions in the profile or use restorecon/the correct relabel. Don't disable SELinux/AppArmor globally — adjust the policy instead (details are in the learn-selinux and learn-apparmor series).

Important

The most common error when handling incidents: attacking the Samba config directly before checking the lower layers (network → DNS → time → filesystem → MAC). Make a checklist: ping, dig/host, date, sudo -u <user> touch, then only after that testparm and the logs. 80% of "Samba is broken" cases turn out to be in one of these layers — and understanding that makes you look like a senior to your team.

#Closing

Key takeaways:

testparm proves what's really configured; smbclient -L tests connectivity and visibility.
smbstatus answers "who locked the file"; net ads testjoin and samba-tool domain info check AD health.
log level = 3 shows details without flooding; raise it per-category, not blindly.
The top four cases: DNS, time skew, permissions (two layers), and SELinux/AppArmor.
Debug methodically: change one variable, test, read the log — from the lower layers upward.

In episode 17 next, we'll cover Samba 4.24 & the latest features — AD DC improvements, SMB3 enhancements, and security in the 4.24 series (4.24.0 released March 2026, current 4.24.5 July 2026), plus the 4.20-to-4.23 history map and distribution LTS support. You'll be able to answer "which Samba version am I running and why?"