NFS-Freigaben robust einbinden: hard oder soft, timeo und was passiert, wenn der Server ausfällt

Ziel

Einen NFS-Export so einbinden, dass er einen nicht antwortenden Server und einen normalen Neustart übersteht, und wissen, welches Paket und welche Version unter RHEL beziehungsweise Debian/Ubuntu zu verwenden ist.

Voraussetzungen

• Root-Rechte zum Einbinden. Client-Pakete: nfs-utils unter RHEL/Fedora, nfs-common unter Debian/Ubuntu.
• Exportpfad und Serveradresse; showmount -e <server> listet die Exports des Servers auf (setzt voraus, dass mountd/rpcbind erreichbar sind, relevant vor allem für NFSv3).

Schritte

1. Prüfen, was der Server anbietet: showmount -e nfsserver. showmount hängt von mountd/rpcbind ab und zeigt bei einem reinen NFSv4-Server unter Umständen nichts an, obwohl das Einbinden funktioniert. NFSv4 stellt die Exports in einem einzigen Pseudo-Dateisystem bereit und braucht kein rpcbind; NFSv3 benötigt rpcbind, und der Client greift nur darauf zurück, wenn der Server kein NFSv4 anbietet oder vers=3 gesetzt ist.
2. Zum Test einmal manuell einbinden: mount -t nfs -o vers=4.2 nfsserver:/export /mnt/data (ohne vers=/nfsvers= handelt mount -t nfs die höchste Version aus, die beide Seiten unterstützen; vers=4.2 schlägt fehl, wenn der Server 4.2 nicht anbietet).
3. Das Verhalten im Fehlerfall bewusst in /etc/fstab festlegen:
   • hard (Standard): E/A auf dem Mount blockiert und wird endlos wiederholt, wenn der Server nicht mehr antwortet; ein Prozess, der in diesem Zustand in einem NFS-Aufruf hängt, lässt sich in der Regel nur mit SIGKILL beenden (die veraltete Option intr wird seit Kernel 2.6.25 ignoriert). Das schützt bei einem kurzzeitigen Ausfall vor stillem Datenverlust.
   • soft: E/A gibt nach retrans= Wiederholungen auf (jede wartet timeo= Dezisekunden, bei TCP mit linearem Backoff) und meldet der Anwendung einen Fehler. Das ist nur dort angebracht, wo die Anwendung E/A-Fehler bereits korrekt behandelt, da soft einen Zustand stillschweigend beschädigen kann, der von erfolgreichen Schreibvorgängen ausging.
   • Über TCP gelten bereits die Standardwerte timeo=600 (60 Sekunden) und retrans=2; retrans= lässt sich erhöhen, um bei instabilen Verbindungen das Zeitfenster zu vergrössern, bevor ein soft-Mount aufgibt.
4. Reihenfolge beim Netzwerk: systemd erkennt nfs/nfs4 bereits als Netzwerk-Dateisysteme und ordnet sie nach dem Netzwerk ein; _netdev ist nur nötig, wenn diese Erkennung versagt (z. B. bei iSCSI-basierten Dateisystemen), und schadet in einer NFS-Zeile nicht.
5. Damit der Boot nicht hängt, wenn der NFS-Server ausgefallen ist, x-systemd.automount,x-systemd.mount-timeout=30 zu den Optionen des Eintrags hinzufügen: Der Mount wird erst beim ersten Zugriff und mit begrenztem Timeout ausgelöst, statt den Bootvorgang zu blockieren (auch nofail allein sorgt dafür, dass der Boot nicht darauf wartet). Nach dem Bearbeiten von fstab systemctl daemon-reload ausführen.
6. Alles aus fstab einbinden und prüfen: mount -a, anschliessend mount | grep nfs und nfsstat --client für clientseitige RPC-Statistiken (Wiederholungen weisen hier auf einen instabilen Pfad hin, selbst wenn der Mount intakt aussieht).

Erwartetes Ergebnis

Die Freigabe ist erreichbar, mount -a läuft ohne Hängen durch, und ein absichtlich gestoppter NFS-Server führt zum gewählten Verhalten (endlose Wiederholung bei hard, ein begrenzter Fehler bei soft) statt zu einem ungeplanten Boot-Hänger.

Grenzen und Prüfbasis

Optionen geprüft anhand von nfs(5), mount.nfs(8) und systemd.mount(5) (_netdev, x-systemd.automount). Rückgängig machen: die fstab-Zeile auskommentieren oder entfernen und umount /mnt/data ausführen; das Aushängen betrifft keine Daten auf dem Client.