Come configurare una condivisione NFS su Debian

Quando NFS ha senso su Debian

Una condivisione NFS su Debian è la scelta giusta quando devi esporre file a più host Linux con latenza bassa, controllo dei permessi coerente e una configurazione semplice da automatizzare. Non è un sostituto di un object storage né una soluzione “magica” per ambienti misti: NFS funziona bene se hai server e client affidabili, rete stabile e un’idea chiara di chi deve leggere o scrivere cosa.

Il punto operativo non è solo “farla montare”, ma evitare i classici errori: esportare troppo, usare opzioni permissive senza capirne l’impatto, ignorare UID/GID, dimenticare il firewall, oppure montare senza verificare che il servizio risponda davvero. Qui sotto la procedura segue un criterio da produzione: prima il server, poi il client, poi i controlli e infine il troubleshooting.

Architettura minima: server, export e client

Su Debian il server NFS espone una directory locale tramite il demone `nfs-server` e il file di configurazione `exports`. I client montano quella directory come se fosse un filesystem locale. Il comportamento dipende da tre cose: il path esportato, le opzioni di export e la corrispondenza tra identità utente sul server e sul client.

Se gli utenti non hanno gli stessi UID/GID sui nodi, NFS non “traduce” i permessi in modo intelligente: vede numeri, non nomi. Per questo motivo, prima di partire, conviene decidere se il dataset sarà accessibile con un account condiviso, con identità sincronizzate o con una politica più rigida basata su root squash e permessi ben definiti.

1. Installare il server NFS su Debian

Su Debian recente il pacchetto da installare è `nfs-kernel-server`. Dopo l’installazione conviene verificare subito che il servizio sia attivo e che i componenti necessari siano presenti, prima ancora di toccare gli export.

sudo apt update
sudo apt install nfs-kernel-server
systemctl status nfs-server

Atteso: `active (running)` per `nfs-server`. Se il servizio non parte, controlla i log con `journalctl -u nfs-server -b` e verifica che il kernel supporti il modulo NFS. In un’installazione standard Debian non serve fare tuning particolare per iniziare, ma il servizio deve essere realmente in esecuzione prima di esportare qualunque directory.

2. Preparare la directory da esportare

La directory esportata deve esistere sul server e avere permessi coerenti con l’uso previsto. Un errore comune è esportare una directory con permessi troppo larghi “per far funzionare tutto” e poi ritrovarsi con problemi di sicurezza o con applicazioni che scrivono file con proprietari inattesi.

Esempio: vuoi condividere `/srv/nfs/share` e far scrivere un gruppo applicativo specifico. Prima crea il path e imposta ownership e permessi in modo esplicito.

sudo mkdir -p /srv/nfs/share
sudo chown root:shared /srv/nfs/share
sudo chmod 2770 /srv/nfs/share

Il bit `2` sul permesso (`2770`) abilita il setgid sulla directory: i nuovi file ereditano il gruppo della directory. È una scelta pratica quando vuoi mantenere coerenza tra più utenti o servizi che devono scrivere nello stesso spazio.

Se il gruppo `shared` non esiste, crealo prima. Se devi mappare utenti applicativi, fai la verifica degli UID/GID su server e client con `getent passwd nomeutente` e `getent group nomegruppo` per evitare sorprese più avanti.

3. Configurare `/etc/exports` con criterio

Il file `/etc/exports` determina chi può montare cosa e con quali opzioni. Qui si decide il perimetro reale della condivisione. Una configurazione troppo ampia funziona subito, ma espone più del necessario; una troppo restrittiva genera errori di mount o accessi negati difficili da leggere se non guardi i log giusti.

Un export tipico, limitato a una subnet di rete interna, può essere questo:

/srv/nfs/share 192.168.10.0/24(rw,sync,no_subtree_check,root_squash)

Le opzioni principali hanno implicazioni pratiche:

• rw: consente scrittura. Usalo solo se serve davvero.
• sync: conferma le scritture in modo più sicuro. È più conservativo di `async`.
• no_subtree_check: evita controlli sul sottoalbero che spesso creano overhead e problemi inutili.
• root_squash: mappa l’utente root del client a un utente non privilegiato sul server. È la scelta consigliata nella maggior parte dei casi.

Se devi consentire solo lettura, sostituisci `rw` con `ro`. Se devi autorizzare più subnet o host singoli, aggiungi righe separate invece di allargare una rete intera senza motivo. Nella pratica operativa, l’errore più costoso è autorizzare “temporaneamente” una subnet grande e poi dimenticarsene.

Dopo aver salvato il file, ricarica gli export e verifica cosa il server sta pubblicando davvero.

sudo exportfs -ra
sudo exportfs -v

Atteso: la directory compare nell’output con le opzioni previste. Se non appare, il problema è quasi sempre sintattico nel file o un path inesistente. In caso di dubbio, controlla anche `sudo exportfs -s` per vedere gli export attivi in formato sintetico.

4. Aprire il firewall solo dove serve

NFS non è solo `nfs-server`: in molti scenari servono anche il demone RPC e servizi correlati. Su reti con firewall stretto devi verificare quali porte sono effettivamente in ascolto e consentire solo quelle necessarie. Su Debian moderno, con NFSv4, la situazione è più semplice rispetto a vecchie configurazioni con molte porte dinamiche, ma non va data per scontata.

Controlla i listener e i servizi RPC attivi:

sudo ss -tulpn | grep -E '(:2049|rpcbind)'
systemctl status rpcbind

Se usi `ufw`, una regola tipica per NFSv4 in una LAN fidata può essere limitata alla subnet interna. Il principio resta lo stesso anche con `nftables`: consenti solo i client che devono davvero montare la share.

Attenzione a non esporre NFS su reti pubbliche. NFS è pensato per ambienti fidati; se lo metti su Internet stai allargando troppo la superficie d’attacco e stai complicando il modello di autenticazione senza un guadagno reale.

5. Installare e montare il client NFS

Sul client Debian installa `nfs-common`, che fornisce gli strumenti necessari per il mount e la gestione lato client. Anche qui, prima di rendere persistente il mount, conviene fare una prova manuale.

sudo apt update
sudo apt install nfs-common
sudo mkdir -p /mnt/share
sudo mount -t nfs4 server.example.local:/srv/nfs/share /mnt/share

Se il mount riesce, verifica subito con `mount | grep /mnt/share` e prova una scrittura con un file temporaneo, sempre in base ai permessi previsti.

touch /mnt/share/test-nfs
ls -l /mnt/share/test-nfs

Se il file viene creato ma ha proprietario inatteso, il problema non è il mount: è quasi sempre un tema di UID/GID o di policy sugli export. Se invece il mount fallisce con timeout o “access denied”, torna a `exportfs -v`, firewall e connettività di rete.

6. Rendere il mount persistente con `/etc/fstab`

Quando la prova manuale è andata a buon fine, puoi rendere la condivisione persistente in `/etc/fstab`. È il punto in cui molti ambienti si rompono al reboot, perché si aggiunge la riga senza testarla o senza prevedere cosa succede se il server NFS non è ancora disponibile al boot.

Esempio di riga per NFSv4 con opzioni pragmatiche:

server.example.local:/srv/nfs/share /mnt/share nfs4 defaults,_netdev,noatime 0 0

`_netdev` segnala che il filesystem dipende dalla rete; questo aiuta il boot order. `noatime` riduce scritture inutili in alcuni casi d’uso. Se vuoi un comportamento più robusto al boot, valuta anche `x-systemd.automount`, utile quando preferisci montare al primo accesso invece che bloccare l’avvio del nodo se il server è lento o non raggiungibile.

Dopo aver aggiornato `fstab`, testa la sintassi senza riavviare il sistema.

sudo mount -a
findmnt /mnt/share

Atteso: nessun errore da `mount -a` e la riga visibile in `findmnt`. Se vuoi evitare di toccare il boot in caso di errore, il test con `mount -a` è il minimo sindacale prima di chiudere il change.

7. Gestire permessi, ACL e coerenza degli utenti

La parte più sottovalutata di NFS è la gestione delle identità. Se la share serve a un’applicazione o a più amministratori, devi decidere in anticipo se affidarti ai permessi Unix classici, alle ACL o a una combinazione delle due. Le ACL sono utili quando i gruppi non bastano, ma aumentano la complessità operativa: documentale bene o diventa impossibile capire chi può fare cosa dopo qualche mese.

Per verificare le ACL disponibili su Debian, usa `getfacl` e `setfacl` solo se hai un motivo preciso. Esempio:

getfacl /srv/nfs/share
sudo setfacl -m g:shared:rwx /srv/nfs/share

Se applichi ACL, verifica che il filesystem sottostante le supporti e che il backup le preservi. È un dettaglio che spesso emerge solo durante un restore, quando ti accorgi che i permessi “sembrano uguali” ma il comportamento è diverso.

8. Troubleshooting rapido quando il mount non funziona

Se la share non monta, non partire dal file `fstab` a occhi chiusi. Risali per layer: rete, servizio, export, permessi, client. La diagnosi più veloce è quasi sempre quella che separa il problema di trasporto da quello di autorizzazione.

1. Verifica connettività e nome host: `ping server.example.local` e `getent hosts server.example.local`.
2. Controlla il servizio server: `systemctl status nfs-server` e `journalctl -u nfs-server -b`.
3. Controlla gli export visibili: `sudo exportfs -v` sul server.
4. Testa il mount manuale con `mount -t nfs4` e osserva il messaggio preciso di errore.
5. Se ricevi “access denied”, confronta subnet autorizzata, UID/GID e opzioni di export.

Se il client vede timeout, spesso il problema è firewall o routing. Se vedi `stale file handle`, di solito è cambiato il path esportato o la directory è stata sostituita in modo non coerente. Se l’applicazione scrive ma poi i file spariscono o cambiano proprietario, controlla il setgid della directory e l’account con cui gira il servizio.

Un comando utile per osservare cosa il server sta esportando e quali opzioni stanno realmente passando al client è:

showmount -e server.example.local

Nota però che `showmount` non sostituisce `exportfs -v`: il primo è utile come verifica rapida, il secondo come fonte più affidabile sul server locale.

9. Scelte che fanno differenza in produzione

In produzione conviene preferire configurazioni piccole e leggibili. Un export per una singola subnet è meglio di un export globale con cento eccezioni. Un mount testato manualmente è meglio di un `fstab` scritto e mai provato. Un gruppo condiviso ben definito è meglio di una directory aperta a tutti “per velocizzare”.

Se la share serve a un servizio web o a un backend, tieni separati i ruoli: directory per dati, directory per upload, directory per log. In questo modo puoi applicare permessi e backup diversi. Ad esempio, i log potrebbero essere solo scrivibili dal servizio, mentre i dati applicativi potrebbero richiedere lettura a più processi ma scrittura a uno solo.

Dal punto di vista della sicurezza, minimizza l’esposizione: limita gli host autorizzati, usa `root_squash`, evita `no_root_squash` salvo casi davvero giustificati e documentati, e non pubblicare NFS fuori rete fidata. Se vuoi una protezione più robusta, il salto non è “aprire meno porte”, ma ripensare il modello di accesso e, se necessario, usare un meccanismo diverso per scenari non fidati.

10. Esempio completo di configurazione

Qui sotto un esempio sintetico ma realistico per una LAN Debian. Adatta subnet, hostname e permessi al tuo ambiente.

/etc/exports
/srv/nfs/share 192.168.10.0/24(rw,sync,no_subtree_check,root_squash)

sudo exportfs -ra
sudo systemctl restart nfs-server
sudo exportfs -v

server.example.local:/srv/nfs/share /mnt/share nfs4 defaults,_netdev,x-systemd.automount 0 0

Se usi `x-systemd.automount`, il mount si attiva al primo accesso. È spesso comodo per workstation e nodi che non devono dipendere strettamente dalla disponibilità immediata del server al boot. In ambienti server critici, invece, valuta il comportamento applicativo prima di introdurre automount: non tutte le applicazioni gradiscono un filesystem che appare solo al primo accesso.

Verifica finale e manutenzione

Una share NFS ben fatta non si misura solo dal fatto che monta. Devi verificare che i permessi siano corretti dopo reboot, che il servizio sia sempre attivo, che il firewall non si sia allargato e che i client montino davvero la risorsa attesa. La manutenzione minima consiste nel controllare periodicamente `exportfs -v`, lo stato del servizio e i log di sistema quando cambiano kernel, policy di rete o configurazioni di storage sottostante.

Se il tuo obiettivo è una condivisione stabile per ambienti Linux interni, Debian con NFS resta una soluzione solida e prevedibile. La differenza tra un setup affidabile e uno fragile non sta nel protocollo, ma nella disciplina con cui gestisci export, permessi, rete e test di montaggio.