Un montage NFS peut se bloquer lors du basculement d’un routeur domestique, car les requêtes NFS existantes continuent d’être retentées sur un chemin dont la passerelle, l’adresse source ou l’état TCP a changé.
Sur un serveur domestique ZimaSpace, le partage peut se trouver sur un NAS tandis que les applications, les services multimédias ou les tâches de sauvegarde le montent depuis un autre nœud. Le basculement du routeur peut préserver l’accès Internet de base tout en laissant une session NFS existante sans chemin valide. Le test utile consiste à comparer l’état des routes, le comportement des tentatives NFS et l’ancien chemin avec le nouveau, sans redémarrer immédiatement le NAS.
Distinguer une panne NFS d’une panne générale du routeur
Vérifiez que le NAS reste accessible par IP et qu’une nouvelle connexion TCP peut être établie alors que le montage existant est bloqué.
Un article ciblé sur le dépannage de NFS consacré aux problèmes de réseau et de pare-feu aide à isoler cette branche, car il traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Si les nouvelles connexions échouent également, réparez d’abord le chemin réseau. Si seul le montage existant se bloque, examinez les tentatives NFS et l’état obsolète du transport.
Comprendre pourquoi un montage persistant continue d’attendre
Vérifiez si le partage est monté en mode persistant et si l’application reste bloquée pendant que NFS retente la même requête.
Un article indépendant ciblé sur les bonnes pratiques NFS consacré au fait de laisser les applications en attente lorsque le serveur disparaît aide à isoler cette branche, car il traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Pour les données importantes, ne passez pas à des montages non persistants simplement pour masquer un problème de basculement. Corrigez l’accessibilité et utilisez l’automontage pour les partages non critiques.
Rechercher un ancien état TCP après le changement de passerelle
Capturez les retransmissions du client NFS et comparez le prochain saut avant et après le basculement.
Une étude de cas ciblée sur le dépannage au niveau des paquets consacrée aux retransmissions TCP qui se poursuivent jusqu’à la réinitialisation de la session aide à isoler cette branche, car elle traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Si les paquets suivent la nouvelle route mais que l’ancienne connexion ne se rétablit jamais, testez un nouveau montage après avoir libéré en toute sécurité l’état bloqué du client.
Vérifier les différences de route et de transport après le basculement
Comparez l’adresse IP source, la passerelle, l’interface et le MTU du chemin avant et après la transition du routeur.
Un guide pratique ciblé sur le dépannage de NFS consacré aux problèmes d’accessibilité du serveur et de transport aide à isoler cette branche, car il traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Un basculement qui modifie le sous-réseau source ou le MTU peut nécessiter des ajustements du pare-feu et des exports, même si le tableau de bord du NAS reste accessible.
Libérer un montage bloqué sans redémarrer le serveur domestique
Arrêtez les applications qui utilisent le montage, identifiez les processus bloqués et utilisez un démontage différé ou forcé de manière contrôlée uniquement lorsqu’un démontage normal ne peut pas aboutir.
Un article ciblé sur le dépannage Linux consacré à la libération des montages NFS bloqués sans redémarrage aide à isoler cette branche, car il traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Ne tuez pas le NAS et ne supprimez pas les répertoires de montage en première intention. Conservez les journaux indiquant quelle requête s’est bloquée.
Utiliser l’automontage pour les partages distants non critiques
Pour les chemins multimédias ou les sauvegardes secondaires, envisagez un montage à la demande afin qu’un chemin routeur défaillant ne bloque pas le démarrage d’éléments sans rapport ni celui des services.
Un tutoriel Linux pratique consacré à x-systemd.automount, qui peut monter NFS au premier accès aide à isoler cette branche, car il traite le même micro-problème au lieu de se limiter à définir le protocole sous-jacent.
Effectuez un nouveau test après deux cycles de basculement. Le résultat attendu est soit une récupération propre de la session, soit un remontage limité dans le temps, et non un blocage généralisé du système.
Retester le chemin exact du serveur domestique
Après avoir modifié une seule variable, répétez le même flux de travail sur le NAS ou dans l’environnement auto-hébergé depuis le même client, au lieu de passer à un autre test susceptible d’utiliser un chemin différent.
Le guide ZimaSpace associé consacré à ce chemin réseau adjacent du serveur domestique aide à maintenir la vérification finale dans le même environnement auto-hébergé.
La correction n’est terminée que lorsque le symptôme initial reste résolu après la reconnexion, le redémarrage du service et un second transfert ou une seconde requête contrôlée.
Assistance et conseils
Plus à lire

Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...

Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...

Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...

