Come installare e configurare NFS su Ubuntu 24.04

NFS su Ubuntu 24.04: quando ha senso usarlo

NFS resta una scelta solida quando devi condividere filesystem tra più server Linux con latenza bassa e requisiti semplici: home directory, directory di lavoro per applicazioni, repository interni, upload condivisi, ambienti di test. Su Ubuntu 24.04 il pacchetto server è maturo e l’integrazione con systemd è lineare, ma la parte che fa la differenza non è il comando di installazione: è la disciplina su permessi, rete e controllo degli accessi.

Il punto da chiarire subito è questo: NFS non è un sostituto di uno storage distribuito ad alta resilienza. È un protocollo di condivisione file. Se il server cade, i client si fermano; se la rete degrada, le applicazioni lo sentono; se i permessi sono sbagliati, il problema si vede subito. Per questo conviene trattarlo come un servizio infrastrutturale, non come una semplice cartella condivisa.

Scenario minimo: server Ubuntu 24.04 e client Linux

In questa guida assumo un server con IP privato, ad esempio 192.168.10.10, e uno o più client nella stessa rete o in una rete raggiunta in modo affidabile. Se stai esponendo NFS oltre un perimetro fidato, fermati e rivaluta il disegno: in quel caso servono segmentazione, firewall rigoroso e una valutazione precisa del rischio operativo.

L’obiettivo è arrivare a una configurazione che funzioni, sia verificabile con test semplici, e che si possa correggere senza fare danni collaterali. Ogni modifica rilevante va quindi fatta con un backup del file di configurazione e con un controllo immediato lato client.

Installazione dei pacchetti necessari

Su Ubuntu 24.04 il pacchetto da installare sul server è nfs-kernel-server. Sul client basta nfs-common. Se vuoi usare una macchina anche come client e server, puoi installarli entrambi.

sudo apt update
sudo apt install nfs-kernel-server

Dal lato client:

sudo apt update
sudo apt install nfs-common

Dopo l’installazione verifica che il servizio sul server sia attivo:

systemctl status nfs-server

Atteso: stato active (exited) o comunque servizio abilitato e componenti RPC avviati. Se è in errore, il primo posto da guardare è il journal:

journalctl -u nfs-server -b --no-pager

Preparare la directory da esportare

Conviene creare una directory dedicata, non esportare percorsi generici o troppo ampi. Un errore classico è dare in condivisione una directory già usata da altro software senza verificare owner, permessi e contenuto. Meglio un mount point chiaro, ad esempio /srv/nfs/share.

sudo mkdir -p /srv/nfs/share
sudo chown -R nobody:nogroup /srv/nfs/share
sudo chmod 2775 /srv/nfs/share

Il set di permessi qui sopra è un esempio prudente per una share generica. Se devi servire utenti reali con UID/GID specifici, il modello va adattato. NFS non “traduce” i permessi in modo magico: se i numeri non tornano tra server e client, i problemi arrivano subito. Per ambienti multiutente seri, pianifica gli UID in modo coerente o usa directory specifiche con ownership controllata.

Configurare gli export su Ubuntu 24.04

La configurazione principale sta in /etc/exports. Qui dichiari quale directory esportare e verso quali host o subnet. È il punto più delicato della procedura: un export troppo largo equivale a dare accesso a chi non dovrebbe averlo.

Esempio per consentire l’accesso alla subnet 192.168.10.0/24 in sola lettura/scrittura, con alcune opzioni ragionevoli per una LAN interna:

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

Le opzioni contano più di quanto sembri. sync riduce il rischio di inconsistenze a costo di un po’ di performance; in uno scenario normale è la scelta giusta. no_subtree_check evita controlli inutili su sottoalberi esportati e in genere riduce problemi pratici. Se ti serve una postura più restrittiva, puoi aggiungere root_squash, che è anche il comportamento consigliato nella maggior parte dei casi.

Se vuoi limitare l’accesso a un solo client, specifica il suo IP invece della subnet. È la scelta più pulita quando hai pochi host noti e vuoi ridurre la superficie esposta.

Dopo ogni modifica, ricarica la tabella degli export senza riavviare tutto il servizio:

sudo exportfs -ra
sudo exportfs -v

Il secondo comando ti mostra la configurazione effettiva pubblicata dal server. Se non vedi la directory attesa, non andare avanti: prima correggi /etc/exports.

Firewall e porte: il dettaglio che spesso blocca tutto

NFS non è un singolo servizio su una singola porta. C’è di mezzo RPC, il mount daemon e altri componenti. In una LAN semplice puoi vivere bene con la configurazione standard, ma il firewall deve consentire il traffico necessario. Se hai un controllo stretto della rete, verifica prima quali porte sono effettivamente in ascolto.

sudo ss -tulpn | grep -E 'nfs|rpc|mountd|statd'

Se usi UFW, in un contesto interno puoi consentire l’accesso alla subnet del client sul servizio NFS e poi rifinire se necessario. Esempio minimale:

sudo ufw allow from 192.168.10.0/24 to any port 2049 proto tcp

Questo può bastare in molti casi, ma non è una formula universale. Se il mount fallisce con errori RPC, controlla anche il resto del percorso: firewall, DNS, reachability dell’host e log di sistema. Non dare per scontato che sia un problema di NFS puro.

Montare la share sul client

Dal client, crea il punto di mount e prova il mount manuale prima di scrivere in /etc/fstab. È il modo più veloce per distinguere un problema temporaneo da una configurazione persistente sbagliata.

sudo mkdir -p /mnt/nfs-share
sudo mount -t nfs 192.168.10.10:/srv/nfs/share /mnt/nfs-share

Verifica il risultato con un test concreto:

mount | grep nfs
ls -la /mnt/nfs-share
touch /mnt/nfs-share/test-nfs.txt

Se il file viene creato, il flusso base funziona. Se il mount fallisce, i casi più frequenti sono: export non visibile, firewall che blocca RPC, mismatch di permessi, o server non raggiungibile. In quel caso non fare tuning alla cieca: torna ai log e alla reachability.

Persistenza al reboot con /etc/fstab

Quando il mount manuale è stabile, puoi renderlo persistente. In /etc/fstab conviene usare opzioni che riducano i blocchi al boot se il server non è disponibile. Per ambienti standard, una riga semplice è spesso sufficiente:

192.168.10.10:/srv/nfs/share /mnt/nfs-share nfs defaults,_netdev 0 0

L’opzione _netdev aiuta systemd a trattare il mount come dipendente dalla rete. In ambienti più sensibili puoi aggiungere parametri di timeout e automount, ma solo se hai capito il comportamento atteso: un mount bloccante su un file server instabile può rallentare l’avvio dei servizi dipendenti.

Prima di riavviare, testa la sintassi:

sudo mount -a

Se non produce errori e il mount appare correttamente, puoi considerare la parte base completata.

Permessi, UID/GID e il classico errore dei file “invisibili”

Il problema più frequente dopo un mount riuscito è trovare file che esistono ma non sono scrivibili o leggibili come previsto. Con NFS il server valuta i permessi in base agli UID e GID numerici, non ai nomi utente “umani”. Se sul server l’utente www-data ha UID 33 e sul client quello stesso UID è usato da altro, il risultato può essere disastroso.

Per verificare, confronta gli identificativi numerici:

id www-data
stat -c '%u %g %n' /srv/nfs/share

Se serve una condivisione usata da servizi web, database o job scheduler, la strategia migliore è definire in anticipo chi deve scrivere, con quali UID/GID, e mantenere coerenza tra host. Evita di risolvere tutto con permessi 777: funziona come sintomo, non come soluzione.

Hardening essenziale senza complicarsi la vita

Su una rete interna affidabile, il minimo da fare è restringere gli export agli host necessari, usare root_squash salvo casi specifici e tenere il mount esposto solo dove serve. Se la share contiene dati operativi, aggiungi anche controllo di backup e monitoraggio dello spazio disco. Un filesystem NFS pieno si comporta come un collo di bottiglia molto rumoroso: applicazioni in scrittura si bloccano o degradano rapidamente.

Un export più prudente potrebbe essere:

/srv/nfs/share 192.168.10.20(rw,sync,root_squash,no_subtree_check)

Qui la scelta è chiara: un solo client, scrittura consentita, root non privilegiato lato export. È una configurazione che riduce la probabilità di errori grossolani e rende più prevedibile il comportamento.

Per il controllo minimo di sicurezza e salute del servizio, tieni d’occhio almeno questi elementi: stato del servizio, export effettivi, spazio disco, reachability del server e log di mount lato client. Se qualcosa cambia, lo vedi prima lì che nell’applicazione.

Test operativi da fare prima di considerarlo pronto

Un setup NFS non è pronto finché non ha superato una piccola batteria di test realistici. Il primo è banale: scrittura e lettura di un file. Il secondo è meno banale: un riavvio del client. Il terzo è la verifica che il server non esponga più del necessario.

1. Dal client crea un file, leggilo e cancellalo: touch, cat, rm.
2. Controlla che il mount sia presente dopo un reboot del client con mount | grep nfs.
3. Dal server esegui exportfs -v e conferma che la subnet o l’host siano quelli previsti.
4. Guarda i log in caso di anomalie: journalctl -u nfs-server -b sul server e i messaggi del kernel o del mount sul client.

Se uno di questi passaggi fallisce, non andare avanti con l’automazione. Prima identifica la causa, poi rendi persistente la configurazione.

Problemi tipici e come leggerli senza perdere tempo

Se il client vede access denied by server, di solito c’è un problema nell’export, nell’IP del client o nel reverse path della rete. Se il mount resta in attesa e poi scade, il sospetto va su firewall, RPC o raggiungibilità del server. Se il mount funziona ma i file risultano pieni di permessi negati, guarda UID/GID e opzioni di export. Se il servizio sul server non parte, il journal ti dirà quasi sempre più del tentativo di cambiare configurazione a caso.

Un controllo sintetico utile lato server è questo:

showmount -e localhost
rpcinfo -p localhost

Il primo mostra gli export pubblicati; il secondo elenca i servizi RPC disponibili. Se uno dei due non torna, hai già ristretto molto il campo.

Quando NFS è la scelta giusta e quando no

NFS è adatto quando ti serve condivisione file semplice, controllata, con clienti Linux e gestione amministrativa sobria. Non è invece la prima scelta se vuoi replica geografica trasparente, alta disponibilità senza interruzioni percepibili, o isolamento forte tra tenant. In quei casi devi guardare a storage più evoluti, a un layer di sincronizzazione diverso o a una strategia applicativa che tolga il file sharing dal centro del problema.

Su Ubuntu 24.04 la configurazione base è rapida, ma il vero lavoro sta nell’operatività: tenere coerenti i permessi, limitare gli export, verificare il comportamento al boot e monitorare spazio e log. Se fai bene questi quattro punti, NFS resta uno strumento semplice e affidabile. Se li trascuri, diventa uno di quei servizi che sembrano banali finché non si rompono nel momento meno comodo.