Generatore NFS
Crea mount resilienti10.20.0.15:/srv/shared /mnt/shared nfs rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2 0 0
- ✓hard previene la corruzione silenziosa dei dati durante le interruzioni del server.
- ✓_netdev e l'automount systemd evitano errori di mount all'avvio.
Introduzione
Il generatore NFS produce una riga fstab per una condivisione NFS con opzioni che rendono il mount resiliente: hard invece di soft, _netdev affinché l'avvio attenda la rete, nofail affinché una condivisione mancante non blocchi l'avvio, e x-systemd.automount per il mount on-demand.
I mount hard ripetono le richieste finché il server risponde; quelli soft possono restituire errori che le applicazioni interpretano come veri guasti I/O, motivo per cui hard è la scelta consigliata per la maggior parte dei carichi.
Obiettivo
- Generare una riga fstab corretta e completa da server, export, punto di mount e versione NFS.
- Applicare impostazioni orientate alla produzione: hard, _netdev, nofail, automount, timeo e retrans.
- Avvisare quando si sceglie NFSv3, che richiede rpcbind e regole firewall aggiuntive.
Input
- Hostname o IP del server NFS.
- Percorso export sul server (ad esempio /srv/shared).
- Punto di mount locale (ad esempio /mnt/shared).
- Versione NFS: 4.2, 4.1, 4 o 3.
Come funziona
Lo strumento assembla i sei campi fstab: server:export come dispositivo, il punto di mount, il tipo di filesystem nfs, l'elenco opzioni, 0 per dump e 0 per fsck pass.
L'elenco opzioni viene costruito dagli input: rw, hard, _netdev, nofail, x-systemd.automount, nfsvers=<versione>, timeo=600 e retrans=2. timeo e retrans regolano quanto a lungo il client attende e quante volte riprova prima di rinunciare.
Se viene selezionato NFSv3, viene aggiunto un avviso perché NFSv3 dipende da rpcbind e apre porte aggiuntive nel firewall del server; NFSv4 è preferibile quando il server lo supporta.
Esempio testabile
Prova — l'analisi gira localmente nel tuo browser.
Esempio
Server: 10.20.0.15 Export: /srv/shared Mount: /mnt/shared Versione: 4.2
Output atteso
10.20.0.15:/srv/shared /mnt/shared nfs rw,hard,_netdev,nofail,x-systemd.automount,nfsvers=4.2,timeo=600,retrans=2 0 0 Risultato: nessun problema critico rilevato.
Leggere l'output
- La riga generata può essere aggiunta a /etc/fstab così com'è e poi montata con sudo mount -a.
- I risultati buoni confermano la presenza di hard e _netdev — queste due opzioni prevengono le due modalità di guasto NFS più comuni.
- Se appare un avviso su NFSv3, verifica che il server supporti NFSv4 prima di accettarlo.
Rischi
- I mount hard non si arrendono mai: se il server scompare definitivamente, i processi possono bloccarsi finché il server non torna o il mount non viene smontato.
- L'automount posticipa il mount al primo accesso, cambiando il comportamento per i servizi che si aspettano il percorso all'avvio.
- Incollare una riga generata in /etc/fstab senza test può rompere l'avvio di un server di produzione.
Limiti
- Lo strumento non testa connettività, export o autenticazione (ad esempio NFSv4 Kerberos).
- Le opzioni sono una base ragionevole, non una best practice universale: carichi ad alta latenza o speciali possono richiedere valori timeo/retrans diversi.
- Non genera le voci /etc/exports lato server.
Riferimenti ufficiali
FAQ
Perché hard invece di soft?
Un mount soft può restituire un errore dopo un timeout anche quando il server è solo lento, e le applicazioni spesso lo trattano come un vero guasto I/O. I mount hard continuano a riprovare, più sicuri per l'integrità dei dati nella maggior parte dei casi.
Cosa fa nofail?
nofail dice al sistema di continuare l'avvio anche se questo mount fallisce, invece di entrare in modalità di emergenza. È essenziale per le condivisioni opzionali.
Cos'è x-systemd.automount?
Fa sì che systemd monti la condivisione al primo accesso invece che all'avvio, così un server lento o irraggiungibile non ritarda il boot. Il punto di mount esiste subito; il mount vero avviene in modo lazy.