1 28/10/2026 11 min

Su AlmaLinux 9 Samba è la soluzione più lineare quando devi esporre una condivisione file verso client Linux, Windows o macOS senza complicarti la vita con servizi più pesanti del necessario. La parte delicata non è l’installazione in sé, ma la combinazione corretta di pacchetti, firewall, SELinux e permessi sul filesystem: se uno di questi pezzi resta fuori posto, il servizio sembra “su” ma la condivisione non è realmente utilizzabile.

Qui sotto trovi una procedura completa, pensata per un server AlmaLinux 9 in produzione o quasi-produzione, con una condivisione semplice ma ben chiusa, testabile e reversibile. L’obiettivo è arrivare a un’installazione pulita, una share funzionante e una base solida da cui poi eventualmente estendere autenticazione, audit e policy più articolate.

Installazione dei pacchetti Samba su AlmaLinux 9

Su AlmaLinux 9 i pacchetti essenziali sono pochi. In genere bastano il demone Samba e gli strumenti client per verificare la configurazione dal server stesso. Se il sistema è minimale, conviene installare anche utilità di diagnosi di base, così non devi rincorrere strumenti mancanti nel momento in cui qualcosa non torna.

Prima di cambiare stato al servizio, conviene aggiornare l’indice dei repository e installare i pacchetti necessari:

sudo dnf update -y
sudo dnf install -y samba samba-client samba-common policycoreutils-python-utils

Perché questi pacchetti: samba fornisce i servizi principali, samba-client ti dà gli strumenti di test come smbclient, samba-common contiene componenti condivisi, mentre policycoreutils-python-utils serve per gestire SELinux con strumenti come semanage.

Dopo l’installazione, verifica subito che i pacchetti risultino presenti e che il servizio esista:

rpm -q samba samba-client samba-common policycoreutils-python-utils
systemctl list-unit-files | grep samba

Se il secondo comando mostra le unità smb.service e nmb.service, il sistema è pronto per la configurazione. Su AlmaLinux 9 il nome del servizio da gestire operativamente è in genere smb; nmb non sempre è necessario per scenari moderni, ma può essere utile in reti legacy o quando vuoi supportare ancora la risoluzione NetBIOS.

Struttura della condivisione e permessi sul filesystem

La prima decisione da prendere non è Samba, ma il punto di mount o la directory da esportare. Conviene usare un path dedicato, leggibile e facilmente riconoscibile, ad esempio /srv/samba/share. Evita di esportare directory troppo generiche o usate da altri servizi, perché poi i permessi diventano più difficili da mantenere e il blast radius di un errore aumenta.

Creiamo una directory dedicata e un gruppo di accesso. Questo approccio è semplice, leggibile e facile da manutenere.

sudo mkdir -p /srv/samba/share
sudo groupadd sambausers
sudo chgrp sambausers /srv/samba/share
sudo chmod 2770 /srv/samba/share

Il bit 2 su 2770 imposta il setgid sulla directory: i nuovi file ereditano il gruppo della directory, cosa molto utile in una share multiutente. Il risultato atteso è che solo root e gli utenti del gruppo sambausers possano leggere e scrivere, mentre gli altri utenti restano esclusi.

Controlla subito che la directory abbia davvero proprietario e permessi coerenti:

ls -ld /srv/samba/share

L’output atteso è simile a drwxrws--- con gruppo sambausers. Se non è così, correggi prima di procedere: Samba non compensa permessi filesystem sbagliati.

Configurazione di base di Samba in /etc/samba/smb.conf

Il file centrale è /etc/samba/smb.conf. Prima di toccarlo, conviene salvarne una copia di backup. È una modifica piccola, ma su un server la disciplina del rollback conta più della velocità.

sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.bak

Una configurazione essenziale ma robusta può essere questa:

[global] workgroup = WORKGROUP server string = Samba Server on AlmaLinux 9 security = user map to guest = never passdb backend = tdbsam load printers = no printing = bsd disable spoolss = yes log file = /var/log/samba/%m.log max log size = 1000 logging = file [share] path = /srv/samba/share browseable = yes writable = yes valid users = @sambausers force group = sambausers create mask = 0660 directory mask = 2770 guest ok = no

Questa configurazione privilegia l’accesso autenticato. security = user è la scelta standard in quasi tutti gli scenari moderni. valid users = @sambausers limita l’accesso ai membri del gruppo, mentre force group e le maschere di creazione evitano file con permessi incoerenti. Il logging per macchina client, con %m, aiuta molto quando devi capire chi sta fallendo e da dove.

Dopo aver salvato il file, valida la sintassi prima di avviare o riavviare il servizio:

testparm

Se la configurazione è coerente, testparm restituisce un riepilogo senza errori di parsing. Se segnala problemi, correggi il file prima di andare oltre: riavviare Samba con una configurazione rotta è il modo più rapido per trasformare un cambio controllato in un incidente evitabile.

Creazione degli utenti Samba e associazione al gruppo

Samba non usa automaticamente gli account di sistema come credenziali di accesso SMB: devi creare l’utente Linux, inserirlo nel gruppo giusto e poi abilitarlo nel database di Samba. Questo punto viene spesso sottovalutato, ma è proprio qui che molte installazioni “sembrano corrette” e poi falliscono al login.

Supponiamo di voler abilitare l’utente mario. Se l’utente non esiste già, crealo; altrimenti passa direttamente al gruppo.

sudo useradd -m mario
sudo passwd mario
sudo usermod -aG sambausers mario

Ora imposta la password Samba per lo stesso utente:

sudo smbpasswd -a mario
sudo smbpasswd -e mario

Il primo comando aggiunge l’utente al database di Samba; il secondo lo abilita. Il controllo minimo è verificare che l’account risulti attivo nel database locale di Samba e che l’utente faccia parte del gruppo previsto:

id mario
sudo pdbedit -L | grep '^mario:'

Se id mario non mostra sambausers, il login SMB fallirà anche se la password è corretta. Se pdbedit -L non restituisce l’utente, Samba non lo sta ancora riconoscendo.

Avvio del servizio e abilitazione all’avvio automatico

A questo punto puoi avviare il servizio e renderlo persistente al boot. Su un server vero, non limitarti a farlo partire manualmente: se il nodo riavvia e il servizio non torna online da solo, hai solo rimandato il problema.

sudo systemctl enable --now smb
sudo systemctl status smb --no-pager

Se hai bisogno anche di NetBIOS, puoi abilitare nmb:

sudo systemctl enable --now nmb
sudo systemctl status nmb --no-pager

Lo stato atteso è active (running). Se il servizio non parte, il passo successivo non è riavviare a caso: guarda i log del journal e la sintassi della configurazione.

journalctl -u smb -b --no-pager

Questo comando è spesso più utile di qualunque supposizione: se c’è un errore di configurazione, un problema SELinux o una porta già occupata, lì dentro di solito compare subito.

Firewall: apertura delle porte necessarie

Su AlmaLinux 9, con firewalld attivo, Samba non è accessibile finché non apri il servizio nel firewall. È un passaggio banale solo in apparenza: se lo salti, il server è raggiungibile localmente ma invisibile dalla rete.

Per la maggior parte degli scenari basta aprire il servizio Samba predefinito:

sudo firewall-cmd --permanent --add-service=samba
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Il risultato atteso è la presenza di samba nell’elenco dei servizi autorizzati. Se stai lavorando in un ambiente segmentato, verifica anche che non esistano regole esterne o ACL di rete che bloccano SMB a monte del server: il firewall locale non è l’unico layer possibile.

SELinux: etichette corrette per la directory condivisa

Su AlmaLinux 9 SELinux è attivo di default nella maggior parte delle installazioni sane. Se la share non funziona ma tutto il resto sembra corretto, qui c’è spesso la causa. Non conviene disabilitare SELinux: è una scorciatoia che elimina un controllo di sicurezza utile e ti lascia con una configurazione meno robusta di quella che avevi prima.

La via corretta è etichettare la directory con il contesto adatto a Samba:

sudo semanage fcontext -a -t samba_share_t '/srv/samba/share(/.*)?'
sudo restorecon -Rv /srv/samba/share

Se vuoi consentire scrittura e lettura alla share, questa etichetta è la base giusta. Il controllo minimo è verificare il contesto con ls -Zd:

ls -Zd /srv/samba/share

L’output atteso deve mostrare qualcosa di compatibile con samba_share_t. Se invece vedi un contesto generico di tipo default_t o simile, Samba può rispondere ma non riuscire a servire correttamente i file.

Verifica della condivisione dal server

Prima di coinvolgere un client Windows o un altro host in rete, prova la share localmente dal server. Così separi i problemi di Samba da quelli di rete, DNS o autenticazione remota.

smbclient -L localhost -U mario

Se la richiesta di lista condivide correttamente, dovresti vedere la share share nell’elenco. Poi prova l’accesso diretto:

smbclient //localhost/share -U mario

Una volta dentro, puoi testare creazione e lettura di un file di prova con i comandi interni di smbclient. Se vuoi fare un test rapido, usa put su un file locale generato al volo oppure verifica che l’elenco directory risponda senza errori di permesso.

Se il test locale funziona ma il client remoto no, il problema è quasi sempre nel firewall, nel routing, nel nome host o in un filtro di rete esterno. Se invece il test locale fallisce, il problema è dentro il server: configurazione, permessi o SELinux.

Accesso da Windows e mappatura della share

Da un client Windows puoi accedere inserendo nella barra dell’Esplora file il percorso UNC, per esempio \\IP_DEL_SERVER\share. Se il server è raggiungibile e le credenziali sono corrette, Windows chiederà username e password SMB.

Se il nome host non risolve, usa l’IP del server per isolare subito un eventuale problema DNS. È un test semplice ma molto efficace: se con l’IP funziona e con il nome no, non hai un problema Samba ma di risoluzione nome o di dominio di ricerca.

Una volta verificato l’accesso, puoi mappare l’unità di rete da Windows usando le opzioni grafiche di “Connetti unità di rete”. In ambienti misti, è utile mantenere una convenzione chiara sui nomi delle share: evita etichette troppo generiche come data o files se il server ospita più servizi o più reparti.

Log, diagnosi e problemi tipici

Quando Samba non si comporta come previsto, i tre punti da controllare per primi sono sintassi, permessi e SELinux. In pratica: testparm per la configurazione, ls -ld per i permessi, ls -Z o ls -Zd per il contesto SELinux. Sono verifiche veloci e ti evitano di inseguire falsi positivi.

Se il servizio parte ma i client non vedono la share, controlla i log locali in /var/log/samba/ e il journal di sistema. Un file log per client può fare la differenza quando devi capire se il problema è autenticazione, autorizzazione o accesso al filesystem.

sudo ls -l /var/log/samba/
sudo tail -n 100 /var/log/samba/*.log

Tra gli errori più comuni ci sono credenziali sbagliate, utente non presente nel database Samba, directory con contesto SELinux errato e maschere di file troppo restrittive. In un ambiente in cui la share deve essere scrivibile da più utenti, è importante anche verificare che non esistano ACL filesystem in conflitto con i permessi di gruppo.

Rafforzamento minimo consigliato in un server reale

Se la share non è solo temporanea, vale la pena aggiungere alcune buone pratiche. La prima è limitare gli utenti autorizzati a un gruppo dedicato, come già fatto. La seconda è separare le directory di lavoro da quelle esposte via Samba. La terza è non usare account amministrativi per l’accesso ordinario: meglio un utente normale con permessi mirati che un superuser usato per comodità.

Se il server è esposto su reti non fidate o attraversa segmenti misti, considera anche policy di rete più restrittive sul firewall e, se necessario, l’accesso solo da specifiche subnet. Samba non dovrebbe mai essere lasciato aperto in modo indiscriminato su reti che non controlli bene.

Un ultimo punto riguarda i backup: se la share ospita dati utente, il backup va pensato prima del go-live, non dopo il primo problema. Samba è solo il canale di accesso; il valore vero sta nei dati che ci passano dentro.

Procedura rapida di controllo finale

Se vuoi una checklist sintetica, l’ordine corretto è questo: pacchetti presenti, directory pronta, configurazione validata, utente Samba creato, servizio attivo, firewall aperto, SELinux etichettato, test locale riuscito, test da client riuscito. Saltare uno di questi passaggi di solito sposta solo il problema più avanti.

  1. Verifica i pacchetti con rpm -q samba samba-client samba-common.
  2. Controlla la configurazione con testparm.
  3. Conferma stato e avvio automatico con systemctl status smb e systemctl is-enabled smb.
  4. Apri il firewall con firewall-cmd --add-service=samba.
  5. Applica il contesto SELinux con semanage fcontext e restorecon.
  6. Prova l’accesso locale con smbclient -L localhost -U mario.
  7. Prova l’accesso remoto con il percorso UNC dal client.

Assunzione operativa: il server è un’AlmaLinux 9 standard con firewalld e SELinux attivi, e la condivisione deve essere accessibile con autenticazione utente, non come guest.