1 17/04/2026 10 min

Installare Samba su Ubuntu 22.04 LTS Jammy Linux

Samba su Ubuntu 22.04 non è solo “aprire una cartella in rete”: è un servizio SMB che va trattato come un componente di produzione. La differenza la fanno i dettagli: permessi Unix coerenti, utenti Samba allineati agli utenti locali, firewall ristretto, test lato client e una configurazione che non lasci spazio a condivisioni anonime se non sono davvero volute.

Qui parto da un caso semplice e realistico: un server Ubuntu Jammy con una directory da condividere in LAN, accesso autenticato, e una configurazione minimale ma pulita. L’obiettivo è evitare i classici problemi: share visibile ma non apribile, password accettata ma permessi negati, oppure servizio attivo ma non raggiungibile da Windows, macOS o Linux.

Prima scelta: modello di accesso e livello di esposizione

Prima di installare, va deciso chi deve accedere e da dove. Se la share è per una LAN fidata, l’approccio tipico è autenticazione con utente Samba e accesso limitato a una subnet precisa. Se invece il servizio è esposto oltre la rete locale, bisogna considerare anche hardening più severo, aggiornamenti rapidi, logging e, idealmente, accesso mediato da VPN o rete privata.

Nel dubbio, evita la share guest. È comoda in laboratorio, ma in ambienti condivisi genera sempre ambiguità su permessi, auditing e responsabilità degli accessi. Meglio partire con autenticazione esplicita e poi, se serve, aggiungere una seconda condivisione solo in lettura per contenuti pubblici.

Installazione dei pacchetti necessari

Su Ubuntu 22.04 il pacchetto base è semplice. Aggiorna gli indici e installa Samba insieme agli strumenti di verifica.

sudo apt update
sudo apt install samba samba-common-bin -y

Il secondo pacchetto è utile perché include utility come testparm e smbclient, che ti servono subito per validare la configurazione e simulare un accesso client senza dover passare da una macchina Windows.

Dopo l’installazione, controlla che i servizi principali siano avviati:

systemctl status smbd --no-pager
systemctl status nmbd --no-pager

Su molte installazioni moderne nmbd non è indispensabile se non ti serve NetBIOS legacy, ma il controllo iniziale aiuta a capire cosa è effettivamente attivo nel tuo scenario.

Creare directory, gruppo e permessi in modo coerente

La parte più fragile non è Samba in sé, ma il filesystem sottostante. Se i permessi Linux non sono allineati, Samba non può “magicamente” correggerli. Conviene quindi creare una directory dedicata e un gruppo condiviso, poi assegnare tutto in modo esplicito.

sudo mkdir -p /srv/samba/condivisa
sudo groupadd smbshare
sudo chgrp -R smbshare /srv/samba/condivisa
sudo chmod 2770 /srv/samba/condivisa

Il bit 2 iniziale in 2770 imposta il setgid sulla directory: i nuovi file ereditano il gruppo della cartella, cosa utile quando più utenti devono lavorare sugli stessi dati. Se il caso d’uso è solo lettura, il modello cambia e puoi irrigidire ulteriormente i permessi.

Verifica subito l’effetto:

ls -ld /srv/samba/condivisa

L’output atteso deve mostrare il gruppo smbshare e permessi scrivibili dal gruppo solo se vuoi accesso in scrittura. Se qui sbagli, il sintomo lato client sarà quasi sempre un generico “access denied”.

Creare l’utente Linux e l’utente Samba

Samba autentica utenti locali o integrati con un backend directory, ma per una installazione base la via più semplice è un utente Linux dedicato con password Samba. È una separazione utile: l’account di sistema gestisce ownership e permessi, mentre l’account Samba gestisce l’accesso SMB.

sudo useradd -M -s /usr/sbin/nologin -G smbshare sambauser
sudo smbpasswd -a sambauser
sudo smbpasswd -e sambauser

Il flag -M evita la home directory, -s /usr/sbin/nologin impedisce login shell, e l’appartenenza a smbshare lega l’utente al gruppo della directory. Se preferisci usare un utente già esistente, il punto non cambia: deve avere il set di permessi coerente con la share.

Se vuoi verificare che l’account Samba sia registrato correttamente, puoi usare:

sudo pdbedit -L -v | grep -A3 sambauser

Non è un comando obbligatorio, ma è utile quando devi capire se l’utente è stato creato, abilitato e associato al backend previsto.

Configurare smb.conf senza appoggiarsi a opzioni inutili

Il file principale è /etc/samba/smb.conf. Prima di modificarlo, conviene fare una copia di sicurezza, anche banale, perché Samba è uno di quei servizi in cui un errore di sintassi sembra una disfunzione di rete.

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak.$(date +%F)

Una configurazione base, pulita e leggibile può essere questa:

[global]
   workgroup = WORKGROUP
   server role = standalone server
   security = user
   map to guest = never
   server min protocol = SMB2
   disable netbios = yes
   smb ports = 445
   logging = file
   log file = /var/log/samba/log.%m
   max log size = 1000

[condivisa]
   path = /srv/samba/condivisa
   browseable = yes
   read only = no
   valid users = sambauser
   force group = smbshare
   create mask = 0660
   directory mask = 2770

Ci sono scelte precise qui. server min protocol = SMB2 evita SMB1, che non ha senso tenere acceso in un’installazione moderna. disable netbios = yes riduce la dipendenza dal vecchio strato NetBIOS e forza l’uso della porta 445. map to guest = never impedisce fallback silenziosi a guest, che sono una fonte classica di debug confuso.

Le direttive create mask e directory mask servono a mantenere coerenti i permessi dei nuovi oggetti creati via SMB. Se le lasci troppo permissive, la share funziona ma diventa più aperta del necessario; se sono troppo restrittive, l’utente vede la share ma non riesce a scrivere.

Dopo la modifica, valida sempre la sintassi:

testparm

L’output atteso è Loaded services file OK senza errori. Se compaiono warning su parametri obsoleti o sconosciuti, fermati lì: meglio correggere subito che inseguire un servizio apparentemente avviato ma con comportamento incoerente.

Ricaricare Samba e aprire il firewall solo dove serve

Una volta validata la configurazione, riavvia i demoni interessati. In genere basta smbd, ma se stai usando anche la parte di naming legacy puoi avere altri componenti attivi.

sudo systemctl restart smbd
sudo systemctl enable smbd

Se il server ha UFW attivo, consenti solo ciò che ti serve. Per una share SMB moderna, la porta importante è la 445/TCP. Se usi davvero funzioni legacy, il discorso cambia, ma non è il caso base.

sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp
sudo ufw status numbered

La regola con subnet è preferibile a un’apertura generica. Se devi esporre il servizio a più reti, aggiungi regole specifiche invece di aprire la porta a tutto il mondo.

Verificare la share dal server prima del client finale

Prima di passare da Windows o da un file manager grafico, fai il test da shell. È il modo più rapido per distinguere un problema di Samba da un problema del client.

smbclient -L localhost -U sambauser
smbclient //localhost/condivisa -U sambauser

Il primo comando deve elencare le share disponibili; il secondo deve aprire una sessione interattiva sulla condivisione. Se il login fallisce, il problema è quasi sempre credenziali, utente Samba disabilitato o mismatch tra permessi locali e directory.

Se il login riesce ma la navigazione fallisce, controlla i log del servizio. Su Ubuntu li trovi spesso in /var/log/samba/, con file separati per client o per evento. Un controllo rapido utile è:

sudo tail -n 50 /var/log/samba/log.smbd
sudo tail -n 50 /var/log/samba/log.*

Il pattern da cercare è semplice: autenticazione ok ma accesso negato al path, oppure errore di protocollo, oppure tentativo di connessione da host non autorizzato. Queste tre famiglie di errore coprono la maggior parte dei casi reali.

Accesso da Windows, macOS e Linux

Dal lato client, il formato del percorso è sempre SMB. Su Windows puoi usare \\server\condivisa; su macOS e su molti file manager Linux puoi usare smb://server/condivisa. Se il nome host non risolve, passa direttamente all’IP per isolare il problema DNS dalla disponibilità del servizio.

Se Windows chiede credenziali ma poi rifiuta l’accesso, non dare per scontato che Samba sia il problema. Verifica che l’utente inserito sia proprio sambauser, che non ci siano credenziali memorizzate vecchie nel gestore credenziali del sistema, e che il server stia accettando SMB2 o superiore. Un client con cache di credenziali sbagliata può far perdere più tempo del server stesso.

Hardening minimo sensato per non lasciare buchi inutili

Per una installazione pratica, il livello minimo di sicurezza non è complicato. Tieni SMB1 disattivato, limita le sorgenti nel firewall, usa utenti specifici, non concedere guest se non serve, e conserva i log abbastanza a lungo da ricostruire i problemi. Se la share contiene dati sensibili, valuta anche backup separati e snapshot del filesystem, perché Samba non è un sostituto del versioning.

Un punto spesso trascurato è il principio del privilegio minimo sul filesystem. Se dai a Samba il controllo di una directory troppo ampia, il rischio non è solo l’errore umano: basta una sincronizzazione sbagliata o un client compromesso per propagare modifiche indesiderate a più dati del previsto.

Se vuoi un controllo più fine, puoi separare share in lettura e in scrittura, ciascuna con utenti o gruppi diversi. È una scelta più pulita rispetto a una share unica con permessi larghi e speranza che gli utenti si comportino bene.

Diagnostica rapida quando la share non si vede

Quando qualcosa non torna, conviene seguire una sequenza fissa: servizio, porta, sintassi, permessi, log. In pratica:

  1. Controlla che smbd sia attivo con systemctl status smbd.
  2. Verifica la sintassi con testparm.
  3. Controlla l’ascolto sulla porta 445 con ss -tlnp | grep :445.
  4. Testa l’accesso con smbclient verso localhost.
  5. Leggi i log in /var/log/samba/ per l’errore preciso.

Questa sequenza riduce gli errori di interpretazione. Molti operatori partono dal client finale e finiscono per cambiare dieci cose insieme; invece il modo corretto è isolare il layer in cui il problema nasce.

Esempio completo di configurazione minima

Se vuoi un riferimento compatto, questo è un set coerente di file e comandi da cui partire. Non è una configurazione “universale”, ma è una base pulita per un server Ubuntu 22.04 in LAN.

sudo apt update
sudo apt install samba samba-common-bin -y
sudo mkdir -p /srv/samba/condivisa
sudo groupadd smbshare
sudo useradd -M -s /usr/sbin/nologin -G smbshare sambauser
sudo smbpasswd -a sambauser
sudo smbpasswd -e sambauser
sudo chgrp -R smbshare /srv/samba/condivisa
sudo chmod 2770 /srv/samba/condivisa

Nel file /etc/samba/smb.conf:

[global]
   workgroup = WORKGROUP
   server role = standalone server
   security = user
   map to guest = never
   server min protocol = SMB2
   disable netbios = yes
   smb ports = 445

[condivisa]
   path = /srv/samba/condivisa
   browseable = yes
   read only = no
   valid users = sambauser
   force group = smbshare
   create mask = 0660
   directory mask = 2770

Dopo il salvataggio, valida con testparm, poi riavvia smbd e fai il test con smbclient. Se tutto è coerente, il server è pronto per l’uso operativo.

Rollback pratico se qualcosa si rompe

Se dopo una modifica la share smette di funzionare, il rollback deve essere immediato e leggibile. Ripristina prima /etc/samba/smb.conf dal backup, poi riavvia il servizio e verifica di nuovo con testparm. Se il problema riguarda i permessi, annulla le ultime modifiche su ownership e mode solo sulla directory interessata, non sull’intero filesystem.

sudo cp /etc/samba/smb.conf.bak.YYYY-MM-DD /etc/samba/smb.conf
sudo systemctl restart smbd
sudo testparm

In una macchina di produzione, tieni sempre traccia della versione precedente del file di configurazione e della data dell’ultimo cambio. Samba è stabile, ma quando qualcosa si spezza il problema è quasi sempre una variazione locale: una direttiva nuova, un permesso cambiato, o un firewall che non lascia passare la porta giusta.