1 24/05/2026 9 min

Quando un bind mount è la scelta giusta su AlmaLinux 9

Un bind mount serve a presentare una directory già esistente in un altro punto del filesystem, senza copiare dati e senza cambiare il contenuto reale. Su AlmaLinux 9 è la soluzione più pulita quando vuoi esporre lo stesso albero a un servizio, a un container, a un chroot o a un percorso applicativo che non puoi modificare facilmente. La regola pratica è semplice: se ti serve lo stesso contenuto in due posizioni diverse e non vuoi introdurre duplicazione, il bind mount è lo strumento giusto.

Non va confuso con un mount classico di un filesystem separato. Qui non stai agganciando un disco o una partizione, ma stai “ribaltando” un percorso già montato verso un altro punto. Questo lo rende molto utile, ma anche facile da usare male: se la directory di origine non esiste, se i permessi non sono coerenti o se ti dimentichi la persistenza al reboot, il risultato è un setup che funziona solo finché non lo tocchi o finché il sistema non si riavvia.

Su AlmaLinux 9 hai due strade operative: usare il comando mount --bind per il test immediato, e poi rendere tutto persistente con /etc/fstab o, meglio ancora quando serve un avvio ordinato tra servizi, con un’unità systemd .mount. In ambienti server io preferisco sempre fare prima una prova manuale reversibile, poi consolidare la configurazione.

Scenario tipico: stessa directory, due consumatori diversi

Immagina di avere i dati applicativi in /srv/appdata e di doverli rendere disponibili anche sotto /var/www/html/appdata perché un web server o un vecchio software si aspetta quel percorso. Copiare i dati sarebbe una pessima idea: aumenti lo spazio occupato, introduci problemi di sincronizzazione e rischi di modificare la copia sbagliata. Un bind mount evita tutto questo perché entrambi i percorsi puntano allo stesso contenuto reale.

Lo stesso approccio è comune con i container, con ambienti di test che devono vedere file del sistema host, oppure con servizi che devono leggere un path specifico per ragioni storiche. Il vantaggio non è solo tecnico: riduce la manutenzione, perché il dato resta in un solo posto e il resto è solo presentazione.

Creazione immediata con mount --bind

Prima di toccare la persistenza, verifica che le directory esistano e che il punto di destinazione sia vuoto o almeno compatibile con ciò che andrai a esporre. Se monti sopra una directory non vuota, il contenuto sottostante viene nascosto finché il mount resta attivo. Non viene cancellato, ma sparisce dalla vista, ed è una fonte classica di confusione operativa.

Supponiamo di voler esporre /srv/appdata in /var/www/html/appdata. Il primo passo è creare il mount point, se non esiste:

sudo mkdir -p /srv/appdata
sudo mkdir -p /var/www/html/appdata

Se vuoi fare un test reversibile, esegui il bind mount senza opzioni aggiuntive:

sudo mount --bind /srv/appdata /var/www/html/appdata

A questo punto il contenuto di /srv/appdata deve apparire anche sotto /var/www/html/appdata. La verifica minima è questa:

findmnt /var/www/html/appdata
mount | grep ' /var/www/html/appdata '

Il risultato atteso è che findmnt mostri come source /srv/appdata e come target /var/www/html/appdata. Se invece non vedi nulla, il mount non è riuscito o il path è stato digitato male.

Verifica pratica: non fidarti solo di mount

Il comando mount ti dice che il mount esiste, ma non ti conferma che l’applicazione lo legga davvero. Per un controllo utile, crea un file di prova nella directory sorgente e leggilo dal target. È un test banale, ma ti evita errori di percorso e problemi di permessi.

echo test | sudo tee /srv/appdata/prova.txt
cat /var/www/html/appdata/prova.txt

Se il secondo comando restituisce test, il bind mount sta funzionando davvero. Se ottieni Permission denied, il problema non è il mount in sé ma il contesto di accesso: ownership, SELinux, ACL o policy del servizio che deve leggere il path.

Persistenza al reboot con /etc/fstab

Un mount fatto a mano sparisce al riavvio. Per renderlo persistente, aggiungi una riga in /etc/fstab. La sintassi base è semplice, ma conviene scriverla con precisione perché un errore lì può rallentare il boot o lasciare il sistema in stato degradato se il punto di mount non viene trovato.

Per il caso precedente, la riga corretta è questa:

/srv/appdata /var/www/html/appdata none bind 0 0

Dopo aver salvato il file, non riavviare subito. Prima valida la sintassi con un mount di prova:

sudo mount -a

Se il comando non produce errori, il file è almeno coerente. Se vuoi una conferma più precisa, controlla di nuovo con findmnt:

findmnt /var/www/html/appdata

Qui l’attenzione va al blast radius: un errore in /etc/fstab può coinvolgere il boot o i servizi che dipendono dal mount. Il rollback è lineare: commenti la riga, esegui sudo mount -a per verificare che il sistema torni coerente, e solo dopo rivaluti la configurazione corretta.

Opzioni utili: read-only, rbind e propagazione

Il bind mount base è sufficiente in molti casi, ma ci sono tre varianti che vale la pena conoscere. La prima è il bind in sola lettura, utile quando vuoi esporre dati senza permetterne la modifica dal percorso secondario. La seconda è rbind, che replica anche eventuali mount annidati sotto la directory sorgente. La terza riguarda la propagazione, che conta soprattutto in ambienti con container o namespace montati in modo avanzato.

Per rendere il mount read-only, in genere si usa una combinazione di bind e remount. Su Linux moderno la forma pratica è questa:

sudo mount --bind /srv/appdata /var/www/html/appdata
sudo mount -o remount,bind,ro /var/www/html/appdata

La verifica non cambia: prova a scrivere nel target e assicurati che fallisca:

echo prova | sudo tee /var/www/html/appdata/nuovo.txt

Se il mount è davvero read-only, il comando deve fallire con un errore di file system in sola lettura. Se invece scrive, la tua configurazione non è stata applicata come previsto.

Per rbind, il caso classico è quando sotto la directory di origine ci sono altri mount, per esempio volumi separati o punti di aggancio applicativi. In quel caso:

sudo mount --rbind /srv/appdata /var/www/html/appdata

Se non usi rbind, i mount figli non vengono replicati e potresti vedere una struttura incompleta nel target. Questo dettaglio viene spesso ignorato e poi scoperto solo quando un servizio non trova una sotto-directory che “dovrebbe esserci”.

Persistenza più robusta con systemd mount unit

In scenari server un po’ più ordinati, soprattutto quando il bind mount deve essere disponibile prima di un servizio specifico, una mount unit systemd può essere più chiara di /etc/fstab. Il vantaggio è la gestione esplicita delle dipendenze: puoi far partire il mount prima del demone che lo usa, riducendo i casi in cui il servizio fallisce perché il path non è ancora pronto.

Il nome dell’unità deriva dal path del target. Ad esempio, /var/www/html/appdata corrisponde a una mount unit che systemd traduce secondo la sua convenzione sui path. In pratica, spesso è più comodo restare su /etc/fstab per casi semplici e passare a systemd quando il mount fa parte della catena di avvio di più componenti.

Se vuoi controllare che systemd veda correttamente il mount, i comandi utili sono questi:

systemctl daemon-reload
systemctl status local-fs.target
findmnt /var/www/html/appdata

La scelta tra fstab e unità systemd non è ideologica. Se devi solo mantenere un mount stabile e leggibile da chiunque amministri il server, /etc/fstab resta perfetto. Se invece il mount è parte della sequenza di bootstrap del servizio, systemd ti dà più controllo e meno ambiguità.

Permessi, SELinux e il classico errore che sembra un problema di mount

Su AlmaLinux 9 SELinux è quasi sempre parte del quadro. Un bind mount può essere tecnicamente corretto e comunque risultare inutilizzabile da Apache, Nginx o da un demone confinato, perché il contesto di sicurezza non consente l’accesso. Questo è uno dei punti dove molti operatori perdono tempo: vedono il mount, ma non il motivo per cui il servizio non legge i file.

Il primo controllo è capire il contesto del file e del processo. Per il file system usa:

ls -Zd /srv/appdata /var/www/html/appdata

Se il servizio gira in un contesto che richiede un tipo SELinux specifico, puoi dover applicare una label coerente al path sorgente oppure usare le regole corrette per il tipo di contenuto. Non esiste una correzione universale: dipende dal servizio e dalla policy attiva. La verifica giusta è sempre guardare i log AVC, tipicamente con ausearch o journalctl, invece di disattivare SELinux per comodità.

Per esempio, se un web server non riesce a leggere il contenuto dopo il bind mount, il controllo minimo è questo:

sudo ausearch -m avc -ts recent
sudo journalctl -xe | grep -i denied

Se trovi denials coerenti con il percorso, il problema non è il bind mount ma la policy. La soluzione corretta è riallineare i contesti, non aggirare il controllo di sicurezza.

Smontare senza lasciare residui

Quando devi rimuovere un bind mount, il comando è semplice, ma l’ordine conta. Prima verifica che nessun processo stia usando quel percorso, altrimenti lo smontaggio può fallire o lasciare sessioni che puntano a un path non più disponibile.

sudo umount /var/www/html/appdata
findmnt /var/www/html/appdata

Il risultato atteso dopo lo smontaggio è che findmnt non restituisca più nulla per quel target. Se il mount è persistente in /etc/fstab, ricordati di rimuovere o commentare anche la riga corrispondente, altrimenti tornerà al reboot o con mount -a.

Se umount fallisce perché il target è occupato, la diagnostica corretta è vedere chi lo usa con lsof o fuser. In ambiente di produzione, però, la rimozione forzata va valutata con attenzione perché puoi interrompere processi attivi. Il rollback, in questo caso, è il remount immediato del percorso o la ripristinata della riga in fstab, se avevi già rimosso la configurazione.

Checklist operativa che evita gli errori più comuni

La parte difficile non è il comando, ma la disciplina operativa. Prima di dichiarare chiuso il lavoro, controlla sempre questi punti: la directory sorgente esiste, il target esiste, il mount è visibile con findmnt, il contenuto è leggibile dal processo che lo deve usare, la persistenza è stata testata con mount -a o con il riavvio del servizio, e SELinux non sta bloccando l’accesso.

In un change controllato, il flusso corretto è: prova manuale, verifica, persistenza, verifica dopo reboot o reload del servizio. Se tocchi un sistema in produzione, fai prima uno snapshot o almeno conserva una copia della riga di configurazione originale. Un bind mount è reversibile, ma la fretta è il vero fattore di rischio.

Se vuoi un criterio sintetico: usa bind mount quando vuoi riutilizzare gli stessi dati in più punti senza duplicarli; usa un filesystem separato quando vuoi isolamento reale, quote, lifecycle indipendente o controllo di capacità. Il bind mount è un ottimo strumento operativo, ma non sostituisce un design di storage pensato bene.