Monter des partages NFS de façon robuste : hard ou soft, timeo, et ce qui se passe quand le serveur disparaît

Objectif

Monter un export NFS de manière à ce qu'il résiste à un serveur qui ne répond plus ainsi qu'à un redémarrage normal, et savoir quel paquet et quelle version utiliser sous RHEL et sous Debian/Ubuntu.

Prérequis

• Les droits root pour monter le partage. Paquets client : nfs-utils sur RHEL/Fedora, nfs-common sur Debian/Ubuntu.
• Le chemin de l'export et l'adresse du serveur ; showmount -e <server> liste les exports du serveur (nécessite que mountd/rpcbind soit joignable, ce qui concerne surtout NFSv3).

Étapes

1. Vérifier ce que le serveur propose : showmount -e nfsserver. showmount dépend de mountd/rpcbind et peut n'afficher aucun résultat face à un serveur NFSv4 uniquement, alors même que les montages fonctionnent. NFSv4 présente les exports dans un seul pseudo-système de fichiers et n'a pas besoin de rpcbind ; NFSv3 a besoin de rpcbind, et le client ne se rabat sur NFSv3 que si le serveur n'offre pas NFSv4 ou si vers=3 est défini.
2. Effectuer d'abord un montage manuel pour tester : mount -t nfs -o vers=4.2 nfsserver:/export /mnt/data (sans vers=/nfsvers=, mount -t nfs négocie la version la plus élevée prise en charge des deux côtés ; vers=4.2 échoue si le serveur n'offre pas la version 4.2).
3. Choisir délibérément le comportement en cas de panne dans /etc/fstab :
   • hard (valeur par défaut) : les E/S sur le montage se bloquent et sont retentées indéfiniment si le serveur cesse de répondre ; un processus coincé dans un appel NFS dans cet état ne se termine généralement qu'avec SIGKILL (l'ancienne option intr est ignorée depuis le noyau 2.6.25). Ce mode protège contre une perte de données silencieuse lors d'une panne passagère.
   • soft : les E/S abandonnent après retrans= retransmissions (chacune après une attente de timeo= dixièmes de seconde, avec un backoff linéaire sur TCP) et renvoient une erreur à l'application. À réserver aux cas où l'application gère déjà correctement les erreurs d'E/S, car soft peut corrompre silencieusement un état qui supposait que les écritures avaient réussi.
   • Sur TCP, les valeurs par défaut sont déjà timeo=600 (60 secondes) et retrans=2 ; augmenter retrans= pour élargir la fenêtre avant qu'un montage soft n'abandonne sur des liaisons instables.
4. Ordre de démarrage par rapport au réseau : systemd reconnaît déjà nfs/nfs4 comme des systèmes de fichiers réseau et les ordonne après le réseau ; _netdev n'est nécessaire que lorsque cette détection échoue (par exemple pour des systèmes de fichiers reposant sur iSCSI) et ne gêne pas sur une ligne NFS.
5. Pour éviter que le démarrage ne se bloque lorsque le serveur NFS est hors service, ajouter x-systemd.automount,x-systemd.mount-timeout=30 aux options de l'entrée : le montage n'est déclenché qu'au premier accès, avec un délai d'attente borné, au lieu de bloquer la séquence de démarrage (nofail seul empêche aussi le démarrage d'attendre ce montage). Après modification de fstab, exécuter systemctl daemon-reload.
6. Monter tout le contenu de fstab et vérifier : mount -a, puis mount | grep nfs et nfsstat --client pour les statistiques RPC côté client (des retransmissions à cet endroit signalent un chemin réseau instable, même si le montage semble opérationnel).

Résultat attendu

Le partage est accessible, mount -a se termine sans se bloquer, et l'arrêt volontaire du serveur NFS produit le comportement choisi (nouvelles tentatives indéfinies avec hard, erreur après un délai borné avec soft) plutôt qu'un blocage imprévu au démarrage.

Limites et base de vérification

Options vérifiées d'après nfs(5), mount.nfs(8) et systemd.mount(5) (_netdev, x-systemd.automount). Pour annuler : commenter ou supprimer la ligne de fstab, puis exécuter umount /mnt/data ; démonter n'affecte aucune donnée côté client.