Belajar Samba - Testing & Troubleshooting

#Pendahuluan

Sejauh ini kalian membangun, mengamankan, dan melindungi. Episode 16 adalah episode "hidup sebagai administrator": saat semuanya tidak bekerja. Samba yang kompleks — file, autentikasi, DNS, permission, SELinux — menghasilkan error yang membingungkan bila ditangani tanpa metode. Di sini kalian mendapat toolkit diagnostik dan urutan debug yang menuntun dari gejala ke akar masalah, bukan menebak-nebak.

#Toolkit Diagnostik

#testparm: Validasi Konfigurasi

Ini langkah pertama dalam setiap insiden. Konfigurasi yang salah syntax membuat semua gejala lainnya menyesatkan:

testparm -s | less

testparm -s mencetak konfigurasi yang benar-benar dipakai (bukan yang kalian pikir kalian tulis). Perbedaan antara file dan output adalah bagian yang dipengaruhi default atau baris yang salah — sumber klasik "kok beda?"

#smbclient -L: Uji Konektivitas dan Visibilitas

smbclient adalah penguji cepat apakah server bisa dijangkau dan share terpublikasi:

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

-m SMB3 memaksa dialek tertentu — kalau koneksi gagal hanya dengan SMB3, ada masalah protocol negotiation; coba tanpa -m untuk melihat dialek yang disepakati (menyingkap server min/max protocol yang salah).

#smbstatus: Inspeksi Koneksi Aktif

Saat klien mengeluh "lambat" atau "tidak bisa buka file", lihat sisi server:

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

smbstatus menampilkan siapa yang terhubung, file apa yang terbuka, dan lock apa yang dipegang — jawaban instan untuk "file terkunci oleh siapa?".

#net ads testjoin: Verifikasi Kepercayaan Domain

Untuk member domain (episode 10), kepercayaan mesin ke DC bisa rusak diam-diam:

net ads testjoin

Success berarti kepercayaan valid; NT_STATUS_* berarti ada masalah — biasanya password komputer (machine account) tidak sinkron atau DNS salah. Perbaiki dengan net ads join ulang atau net ads reset-account.

#samba-tool domain info: Cek DC dan Level Domain

Untuk environment AD, cek koneksi dan kesehatan domain dari sisi DC:

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

domain info menampilkan nama domain, forest, dan level fungsional — tanda pertama bahwa daemon samba DC hidup dan DNS internal berfungsi.

#Debug: log level

#Menemukan Jawaban di Log

Gejala memberi arah, log memberi jawaban. Naikkan verbositas untuk kategori yang relevan:

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

log level = 3 menampilkan detail koneksi, negosiasi dialek, dan keputusan auth. Level 1 default hanya error; level 10 membanjiri. Uji dengan koneksi dari satu klien lalu baca log khusus klien itu:

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

#Kasus Umum dan Solusinya

#1. DNS

Gejala: net ads join gagal, klien Windows "Path not found", DC tidak ditemukan. Penyebab hampir selalu DNS — SRV record AD hilang atau klien memakai DNS salah. Diagnosa:

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

Perbaikan: arahkan klien ke DNS yang benar (DC untuk AD, atau forwarder yang menunjuk DC). Pada standalone, pastikan fileserver ter-resolve ke IP yang benar di /etc/hosts atau DNS LAN.

#2. Time Skew

Gejala: login domain gagal dengan KDC has no support for encryption type atau Clock skew too great. Kerberos menolak koneksi bila selisih jam melebihi toleransi (umumnya 5 menit). Cek:

date; ssh fileserver date
timedatectl

Perbaikan: aktifkan NTP/chrony di semua host (episode 0). Waktu yang melenceng beberapa detik pun kadang cukup untuk memicu error — jangan disepelekan.

#3. Permission

Gejala: "Access denied" padahal konfigurasi terlihat benar. Ingat dua lapisan permission (episode 4). Uji langsung di filesystem:

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

Jika sudo -u arman touch gagal → masalah filesystem (mode, owner, ACL), bukan Samba. Jika berhasil tapi klien masih ditolak → masalah share options (valid users, write list).

#4. SELinux/AppArmor

Gejala: smbd berjalan tapi share tidak bisa diakses, atau muncul Permission denied di log kernel meski permission filesystem benar. Distribusi dengan SELinux (RHEL family) dan AppArmor (Ubuntu/Debian) mengunci Samba dengan kebijakan sendiri. Cek dan perbaiki:

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

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

Bila kebijakan memblokir akses ke direktori share kalian, tambahkan izin di profil atau gunakan restorecon/relabel yang benar. Jangan matikan SELinux/AppArmor secara global — sesuaikan kebijakannya (ini detail di series learn-selinux dan learn-apparmor).

#Penutup

Inti yang harus dibawa pulang:

• testparm membuktikan apa yang benar-benar dikonfigurasi; smbclient -L menguji koneksi dan visibilitas.
• smbstatus menjawab "siapa yang mengunci file"; net ads testjoin dan samba-tool domain info memeriksa kesehatan AD.
• log level = 3 menampilkan detail tanpa membanjiri; naikkan per-kategori, bukan membabi buta.
• Empat kasus teratas: DNS, time skew, permission (dua lapis), dan SELinux/AppArmor.
• Debug secara metodis: ubah satu variabel, uji, baca log — dari lapisan bawah ke atas.

Di episode 17 selanjutnya kita akan membahas Samba 4.24 & fitur terbaru — perbaikan AD DC, enhancement SMB3, dan keamanan pada series 4.24 (rilis 4.24.0 Maret 2026, current 4.24.5 Juli 2026), plus peta riwayat 4.20 sampai 4.23 dan dukungan LTS distribusi. Kalian akan bisa menjawab "Samba versi berapa yang saya pakai dan mengapa?"