Debian 13 : SSHFS vs NFS — choisissez celui qui ne se fige pas (et configurez-le correctement)

La décision tranchée : utiliser NFS en production, SSHFS pour les cas exceptionnels

Si votre objectif est « ne pas se figer aléatoirement », choisissez NFS avec automount systemd pour tout ce qui ressemble à du stockage partagé en production.
SSHFS est excellent quand vous avez besoin de chiffrement sans infrastructure, ou quand vous récupérez des données d’une machine que vous ne contrôlez pas,
ou pour un montage rapide et ponctuel. Mais si vous montez SSHFS comme une dépendance centrale en attendant qu’il se comporte comme un serveur de fichiers LAN,
vous allez rencontrer la sémantique FUSE, des accrocs TCP et la mise en tampon en espace utilisateur de la manière la moins charmante possible.

NFS n’est pas magique. Il peut aussi se bloquer — surtout avec des montages hard (par défaut), parce que « ne pas renvoyer de données corrompues » est un principe respectable.
Mais la différence est que NFS vous donne de meilleurs outils, une meilleure intégration noyau, et des réglages plus clairs pour le comportement en cas d’échec.
La plupart des « blocages aléatoires » ne sont pas aléatoires ; ce sont des choix de sémantique bloquante sans issue de secours.

Voici la règle pratique :

• Utilisez NFSv4.2 pour les répertoires personnels partagés, les artefacts de build, les zones d’atterrissage de sauvegarde, et « plusieurs clients ont besoin des mêmes données ».
• Utilisez SSHFS pour l’accès ponctuel, traverser des réseaux hostiles, ou quand vous avez besoin d’authentification par utilisateur sans déployer correctement NFS.
• Ne montez jamais l’un ou l’autre de façon à bloquer le démarrage ou à ralentir des daemons critiques. Automount ou ordonnancement explicite des dépendances, toujours.

Une citation pour rester honnête. Werner Vogels (CTO d’Amazon) a une idée largement citée — paraphrasée : « Tout échoue, tout le temps. »
Si vous l’acceptez, vous arrêtez de traiter les blocages comme mystérieux et vous commencez à concevoir le mode d’échec que vous pouvez tolérer.

Faits et histoire qui comptent vraiment en 2025

Quelques points de contexte à utiliser en réunion quand quelqu’un insiste « ce n’est qu’un montage, ça ne peut pas être si dur ».

1. NFS est assez ancien pour avoir des cicatrices. Il remonte au milieu des années 1980 chez Sun, et sa conception reflète des douleurs d’entreprise réelles : fichiers UNIX partagés à l’échelle.
2. NFSv4 a été une réécriture d’esprit. Il a consolidé les protocoles, amélioré la sécurité et l’état, et tendu vers un comportement « un port ami des pare-feux ».
3. NFS aimait l’UDP autrefois. Les déploiements initiaux utilisaient couramment UDP ; la bonne pratique moderne est TCP pour la fiabilité et le contrôle de congestion.
4. SSHFS est FUSE. Cela signifie de la plomberie de système de fichiers en espace utilisateur ; excellent pour la flexibilité, pas idéal pour du stockage « toujours présent » au niveau noyau.
5. La sémantique FUSE peut vous surprendre. Contrôles de permission, cache, et propagation d’erreur se comportent différemment des systèmes de fichiers noyau — surtout en cas de défaillance.
6. Le comportement client NFS est guidé par des politiques. « Hard » vs « soft », timeouts, retransmissions et cache d’attributs façonnent la sensation de « blocage ».
7. Systemd a changé la donne. Les unités automount et les dépendances de montage vous permettent de garder démarrages et services vivants même quand le stockage est instable.
8. Le verrouillage a toujours été compliqué. Le verrouillage NFS est passé par des gestionnaires de verrous séparés ; NFSv4 a intégré le verrouillage, mais des hypothèses legacy reviennent dans les applications.
9. Le mappage d’identités est une souricière courante. NFSv4 utilise le mappage par nom sauf configuration propre ; les incohérences ressemblent à des « permissions qui ont cassé au hasard ».

Ce que « blocage aléatoire » signifie réellement (et qui est en cause)

Quand les ingénieurs disent « SSHFS a bloqué » ou « NFS a bloqué », ils veulent généralement dire l’une des quatre choses suivantes :

1) Un processus est coincé en état D (sleep non interruptible)

C’est le classique : ps affiche D, kill -9 ne sert à rien, et la seule chose qui « résout » est de restaurer le serveur distant ou de redémarrer.
C’est le plus courant avec les montages NFS hard lors d’une panne serveur ou d’une partition réseau.

2) L’appel de montage bloque indéfiniment

Démarrages bloqués, ou démarrage de service bloqué, parce que quelque chose a essayé de monter un système de fichiers distant et a attendu. C’est une erreur de configuration :
pas d’automount, pas de timeout, et une chaîne de dépendances qui laisse un partage distant tenir l’hôte en otage.

3) Les listings de répertoire bloquent, mais certaines lectures fonctionnent

Les opérations sur les métadonnées (lookup, getattr, readdir) sont sensibles au cache et aux variations réseau.
SSHFS peut paraître pire ici car chaque opération de métadonnée fait un aller-retour via un canal SSH, plus le surcoût du protocole SFTP.
NFS peut aussi subir cela si le cache d’attributs est mal réglé ou si le serveur est surchargé.

4) « C’est lent » ressemble à « c’est bloqué »

Un arrêt de 30 secondes sur find ou du est souvent juste une amplification de latence :
des milliers de petites opérations de métadonnées multipliées par quelques millisecondes chacune égalent « mon terminal est mort ».

Blague #1 : Un système de fichiers distant, c’est comme un collègue en vacances — techniquement toujours employé, mais vous n’aurez pas de réponse avant le déjeuner.

Qui a le plus de chances de « se figer au hasard » ?

SSHFS est plus susceptible de se déconnecter ou de se bloquer de façon imprévisible sur des réseaux peu fiables, surtout si vous ne configurez pas de keepalives.
Mais quand SSHFS échoue, il échoue souvent « plus mollement » (vous obtenez des erreurs I/O, le montage disparaît, une reconnexion peut fonctionner) plutôt que d’enfermer le noyau dans des retries éternels.

NFS est plus susceptible de bloquer indéfiniment par conception avec les montages hard par défaut. Ce n’est pas aléatoire ; c’est une politique.
Si vous voulez « ne pas figer l’hôte entier », concevez le mode d’échec : automount, timeouts appropriés,
et une décision claire sur hard vs soft selon la charge de travail.

Feuille de diagnostic rapide (premier/deuxième/troisième)

C’est le flux « j’ai cinq minutes avant que ça devienne une salle de crise ». L’objectif est d’identifier si vous êtes face à
(a) atteignabilité réseau, (b) charge côté serveur ou défaillance de démon, (c) sémantique de montage côté client, ou (d) bizarrerie DNS/identité.

Premier : confirmez que ce n’est pas une atteignabilité basique

• Pouvez-vous pinguer l’IP serveur (ou au moins résoudre le nom) ?
• Le port TCP 2049 est-il accessible pour NFSv4 ? Le port TCP 22 est-il accessible pour SSHFS ?
• Y a-t-il de la perte de paquets ou une latence élevée qui transforme les métadonnées en mélasse ?

Deuxième : vérifiez si le client est bloqué en I/O noyau

• Des processus sont-ils bloqués en état D ?
• cat /proc/mounts ou mount hanguent-ils ?
• L’accès à d’autres systèmes de fichiers fonctionne-t-il normalement ?

Troisième : interrogez le chemin de protocole spécifique

• Pour NFS : nfsstat, rpcinfo (si v3), logs noyau, statut des exports du serveur, et si le serveur répond.
• Pour SSHFS : keepalives SSH, santé du sous-système SFTP, et si la connexion SSH est bloquée à cause d’une session TCP morte.

Points de décision

• Si le serveur est inatteignable : automount empêche l’enfermement total de l’hôte ; réparez le réseau ou basculez.
• Si le serveur est atteignable mais lent : vous êtes limité en capacité — CPU, disques, ou trop de clients ; ajustez et scalez.
• Si un client est bloqué mais pas les autres : suspectez DNS côté client, mappage d’identités, ou un état de montage bloqué.

Tâches pratiques : commandes, sorties, et décisions

Ce sont les actions en astreinte qui séparent « je pense que c’est NFS » de « le client est en retry hard parce que le serveur n’a plus répondu aux ops COMPOUND ».
Chaque tâche inclut : commande, ce que la sortie signifie, et ce que vous faites ensuite.

Task 1: See what’s mounted and whether you’re dealing with NFS or FUSE

cr0x@server:~$ findmnt -t nfs,nfs4,fuse.sshfs
TARGET        SOURCE                 FSTYPE     OPTIONS
/mnt/shared   nas01:/export/shared   nfs4       rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21
/mnt/adhoc    devbox:/home/builds    fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000

Signification : vous avez les deux. NFS est dans le noyau ; SSHFS est FUSE. Décision : appliquez les bons outils de debug — nfsstat pour NFS, logs SSH pour SSHFS.

Task 2: Check whether processes are stuck in uninterruptible I/O (D state)

cr0x@server:~$ ps -eo state,pid,comm,wchan:30 | awk '$1=="D"{print}'
D  18472 rsync  nfs_wait_bit_killable
D  21205 du     rpc_wait_bit_killable

Signification : ces processus sont bloqués dans des attentes noyau, typique du comportement de retry NFS hard. Décision : arrêtez d’espérer que kill -9 aide ; restaurez serveur/réseau ou démontez avec précaution.

Task 3: Confirm network path quickly (latency and loss)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.0.0.50) 56(84) bytes of data.
64 bytes from 10.0.0.50: icmp_seq=1 ttl=63 time=0.453 ms
64 bytes from 10.0.0.50: icmp_seq=2 ttl=63 time=0.482 ms
64 bytes from 10.0.0.50: icmp_seq=3 ttl=63 time=12.103 ms
64 bytes from 10.0.0.50: icmp_seq=4 ttl=63 time=0.469 ms
64 bytes from 10.0.0.50: icmp_seq=5 ttl=63 time=0.476 ms

--- nas01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4093ms
rtt min/avg/max/mdev = 0.453/2.797/12.103/4.650 ms

Signification : un pic. Cela peut suffire à rendre les charges axées métadonnées « figées ». Décision : si les pics corrèlent avec les blocages, cherchez congestion, bufferbloat ou problèmes NIC.

Task 4: For NFSv4, check port reachability (2049)

cr0x@server:~$ nc -vz -w2 nas01 2049
Connection to nas01 (10.0.0.50) 2049 port [tcp/nfs] succeeded!

Signification : la connectivité basique est OK. Décision : arrêtez de blâmer le pare-feu ; regardez la charge serveur, la santé du démon NFS, ou la sémantique de montage client.

Task 5: For SSHFS, confirm SSH transport health and authentication speed

cr0x@server:~$ ssh -o BatchMode=yes -o ConnectTimeout=5 build@devbox 'echo ok'
ok

Signification : SSH répond. Décision : si SSH est OK mais SSHFS bloque, concentrez-vous sur le sous-système SFTP, les keepalives et le comportement FUSE sous charge.

Task 6: Inspect kernel logs for NFS timeouts and server not responding

cr0x@server:~$ sudo journalctl -k -n 20
Aug 12 14:03:19 app01 kernel: nfs: server nas01 not responding, still trying
Aug 12 14:03:50 app01 kernel: nfs: server nas01 not responding, still trying
Aug 12 14:04:23 app01 kernel: nfs: server nas01 OK

Signification : le « blocage » est le client qui fait exactement ce que vous lui avez demandé : continuer d’essayer. Décision : si cela bloque la production, ajoutez automount et envisagez soft seulement pour des lectures non critiques.

Task 7: See per-mount NFS stats (retransmits are the smoke)

cr0x@server:~$ nfsstat -m
/mnt/shared from nas01:/export/shared
 Flags:	rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21
 Stats:	age: 00:43:11  ops/s: 127
	xprt:	tcp  90632  211  0  0  0
	per-op statistics
	READ: 42.1%  WRITE: 11.7%  GETATTR: 20.4%  LOOKUP: 14.2%  ACCESS: 7.6%

Signification : la ligne transport montre des retransmissions (le deuxième nombre après les appels). Si les retrans augmentent, vous perdez des réponses. Décision : investiguez perte réseau, saturation serveur, ou timeouts trop agressifs.

Task 8: Identify whether DNS is causing stalls (reverse lookups can hurt)

cr0x@server:~$ getent hosts nas01
10.0.0.50       nas01

Signification : le nom résout rapidement. Décision : si ceci bloque ou renvoie des adresses inattendues, corrigez le DNS avant de toucher aux montages.

Task 9: Check server-side exports (from server)

cr0x@nas01:~$ sudo exportfs -v
/export/shared  10.0.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)

Signification : l’export existe ; root squashed ; sync activé. Décision : si les clients ont besoin des sémantiques de propriété root, ne « corrigez » pas avec des hacks all_squash — utilisez un mappage UID/GID approprié ou un compte de service.

Task 10: Confirm NFS server services are up (server)

cr0x@nas01:~$ systemctl status nfs-server --no-pager
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2025-08-12 13:01:21 UTC; 3h 2min ago
       Docs: man:nfsd(8)

Signification : service « active (exited) » ce qui est normal pour certaines unités serveur NFS une fois que les threads noyau sont démarrés. Décision : s’il est en échec, ne debuggez pas les clients — réparez d’abord le serveur.

Task 11: Detect a mount that will hang your shell (try a timed stat)

cr0x@server:~$ timeout 3 stat /mnt/shared || echo "stat timed out"
stat timed out

Signification : l’appel métadonnée a bloqué plus de 3 secondes. Décision : votre application qui fait des appels système de fichiers va aussi bloquer ; contournez en basculant, démontant, ou en isolant la dépendance.

Task 12: Safely attempt a lazy unmount (when the remote is gone)

cr0x@server:~$ sudo umount -l /mnt/shared

Signification : pas de sortie signifie généralement succès. Le lazy unmount détache le point de montage maintenant et nettoie quand les références disparaissent. Décision : utilisez-le quand vous avez besoin de rendre la machine utilisable ; puis corrigez la panne sous-jacente.

Task 13: Force a clean remount with systemd (client)

cr0x@server:~$ sudo systemctl restart mnt-shared.mount

Signification : systemd réévalue l’unité de montage. Décision : si le redémarrage bloque, passez à l’automount pour que le montage se fasse à la demande et puisse expirer sans bloquer le démarrage/le démarrage de services.

Task 14: For SSHFS, check for dead TCP sessions and keepalive behavior

cr0x@server:~$ ss -tpn '( sport = :ssh or dport = :ssh )'
ESTAB 0 0 10.0.0.21:52418 10.0.0.60:22 users:(("ssh",pid=29102,fd=3))

Signification : une connexion SSH existe. Décision : si elle est ESTAB mais l’I/O est bloqué, vous avez probablement un chemin semi-mort (middlebox avec état, NAT, Wi‑Fi en veille). Ajoutez des keepalives et ServerAliveInterval pour SSHFS.

NFS qui ne vous embarrasse pas : configs serveur + client Debian 13

La réputation de NFS est étrange : soit « très stable », soit « hanté ». En production, tout dépend de si vous le traitez comme un composant système
(avec identité, exports et automount) ou comme une ligne de montage copiée d’un wiki datant de 2009.

Serveur : installer et exporter proprement

Sur le serveur NFS (Debian 13), vous voulez un export simple, TCP, et des permissions prévisibles. Si vous avez besoin d’une sécurité forte sur des réseaux non fiables,
utilisez Kerberos ; pour les LAN de confiance, sec=sys est courant et acceptable si le réseau est réellement digne de confiance.

cr0x@nas01:~$ sudo apt update
Hit:1 ... InRelease
Reading package lists... Done

cr0x@nas01:~$ sudo apt install -y nfs-kernel-server
Reading package lists... Done
...
Setting up nfs-kernel-server ...

Créez un export. Les options importent :
sync échange un peu de performance contre l’intégrité ; pour de nombreuses charges métier, c’est le bon compromis.
no_subtree_check évite des vérifications basées sur le chemin (et des surprises lors de renommages).
Limitez l’accès : un sous-réseau ou un ensemble d’hôtes.

cr0x@nas01:~$ sudo mkdir -p /export/shared
cr0x@nas01:~$ sudo chown -R root:root /export
cr0x@nas01:~$ sudo chmod 755 /export /export/shared

cr0x@nas01:~$ sudo tee /etc/exports >/dev/null <<'EOF'
/export/shared 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
EOF
cr0x@nas01:~$ sudo exportfs -ra
cr0x@nas01:~$ sudo exportfs -v
/export/shared  10.0.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)

Client : monter avec NFSv4.2 et choisir vos sémantiques d’échec

Le choix clé est hard vs soft :

• hard : retry indéfiniment. Plus sûr pour la correction des données. C’est aussi la source classique du « l’hôte semble figé ».
• soft : renvoie une erreur après des retries. Mieux pour clients interactifs et lectures non critiques. Dangereux pour certaines applis qui ne gèrent pas les échecs partiels.

En production, je pars par défaut sur hard + automount. Ainsi vous évitez la corruption des workflows, sans bloquer le boot.
Pour des outils non critiques (comme une machine de développeur listant un partage média), soft peut être acceptable.

cr0x@server:~$ sudo apt install -y nfs-common
Reading package lists... Done
...
Setting up nfs-common ...

Testez un montage manuel pour valider les bases.

cr0x@server:~$ sudo mkdir -p /mnt/shared
cr0x@server:~$ sudo mount -t nfs4 -o vers=4.2,proto=tcp,hard,timeo=600,retrans=2 nas01:/export/shared /mnt/shared
cr0x@server:~$ mount | grep /mnt/shared
nas01:/export/shared on /mnt/shared type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21)

Ce que signifient ces options en pratique :

• proto=tcp : vous voulez TCP sauf si vous aimez déboguer la perte de paquets « ça marche sur mon poste ».
• timeo=600 : pour TCP, c’est en dixièmes de seconde. 600 → 60 s par timeout RPC. C’est conservateur.
• retrans=2 : nombre de retries avant d’escalader la logique de timeout. Ce n’est pas le « nombre total de retries » pour les montages hard ; les montages hard peuvent continuer d’essayer.
• rsize/wsize : des tailles élevées aident le débit, mais ne résolvent pas la latence des métadonnées. Ce n’est pas un remède pour « find est lent ».

Permissions et identité : rendez-le ennuyeux

NFS n’est pas un système de permissions ; il transmet l’identité. Si UID/GID ne correspondent pas entre machines, vous obtenez des « accès refusés » apparemment aléatoires.
Corrigez-le à la source : UID/GID cohérents pour comptes de service et utilisateurs partagés.

SSHFS qui se comporte : keepalives, systemd, et cache raisonnable

SSHFS séduit parce que c’est juste SSH. Pas d’exports, pas de nostalgie rpcbind, pas de réunions pare-feu spéciales.
Mais SSHFS vit en espace utilisateur, parle SFTP, et dépend d’une session SSH stable. C’est un système de fichiers très poli : il demande la permission pour tout,
une question à la fois, sur un tunnel chiffré. Cette politesse a un coût.

Installer et faire un montage basique

cr0x@server:~$ sudo apt install -y sshfs
Reading package lists... Done
...
Setting up sshfs ...

cr0x@server:~$ mkdir -p /mnt/adhoc
cr0x@server:~$ sshfs build@devbox:/home/builds /mnt/adhoc -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,Compression=no
cr0x@server:~$ findmnt /mnt/adhoc
TARGET     SOURCE              FSTYPE     OPTIONS
/mnt/adhoc build@devbox:/home/builds fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000

Les options de keepalive sont non négociables s’il y a du NAT, du Wi‑Fi, ou un « appliance de sécurité » entre vous et le serveur :
ServerAliveInterval envoie des ping au niveau SSH ; reconnect tente de rétablir la session.

Blague #2 : SSHFS, c’est comme passer un classeur au contrôle de sécurité de l’aéroport — tout est inspecté, et vous payez pour le privilège.

Modes de blocage fréquents avec SSHFS

• Sessions TCP mi-ouvertes : votre portable a dormi, le NAT a expiré, la connexion semble ESTAB mais aucun paquet ne circule. Les keepalives réduisent le temps de détection.
• Problème du sous-système SFTP : sftp-server distant lent, à court de ressources, ou contraint par des commandes forcées.
• Contention des threads FUSE : des appels système de fichiers parallèles lourds peuvent goulotter le démon en espace utilisateur ; des pics CPU côté client ressemblent à un « montage figé ».

Options de montage SSHFS qui réduisent la douleur

• reconnect : essayer de se reconnecter si la connexion tombe.
• ServerAliveInterval=15 et ServerAliveCountMax=3 : détecter rapidement les sessions mortes.
• workaround=rename (parfois) : aide avec les applis qui font des rename atomiques et heurtent des cas limites.
• cache=yes ou kernel_cache : peut aider le débit mais nuire à la cohérence. À utiliser avec prudence si plusieurs écrivains existent.
• Compression=no sur LAN rapide : économise le CPU et améliore souvent la latence.

Si plusieurs clients écrivent les mêmes fichiers et que vous tenez à la cohérence, le caching SSHFS est un piège.
NFS a sa propre histoire de cache/cohérence, mais elle est conçue pour l’accès multi-client partagé. SSHFS est conçu pour l’accès, pas pour la coordination.

Arrêtez de faire ramer votre démarrage : modèles d’automount systemd

Le blocage le plus évitable est celui qui arrive au démarrage parce que /etc/fstab a dit à l’hôte d’attendre qu’une machine distante réponde.
Ne faites pas ça. Utilisez systemd automount pour que le montage ait lieu au premier accès, et pour que les timeouts ne bloquent pas la machine entière.

NFS avec /etc/fstab et automount systemd

Mettez ceci dans /etc/fstab sur le client. Le montage se fait à la demande, pas au démarrage :

cr0x@server:~$ sudo tee -a /etc/fstab >/dev/null <<'EOF'
nas01:/export/shared /mnt/shared nfs4 nofail,x-systemd.automount,x-systemd.device-timeout=10s,x-systemd.mount-timeout=10s,_netdev,vers=4.2,proto=tcp,hard,timeo=600,retrans=2 0 0
EOF

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart remote-fs.target
cr0x@server:~$ systemctl status mnt-shared.automount --no-pager
● mnt-shared.automount - /mnt/shared
     Loaded: loaded (/etc/fstab; generated)
     Active: active (waiting) since Tue 2025-08-12 14:10:12 UTC; 2s ago

Signification : l’automount est armé et en attente. Décision : cette machine peut démarrer même si nas01 est down ; le premier accès déclenche une tentative de montage avec timeouts.

SSHFS avec systemd (préféré à fstab pour les montages utilisateur)

SSHFS fonctionne souvent mieux comme service utilisateur ou avec des unités systemd explicites, car c’est un processus en espace utilisateur et vous voulez une gestion propre de son cycle de vie.
Voici un exemple d’unité système si vous voulez le monter pour un compte de service (ajustez user/chemins au besoin).

cr0x@server:~$ sudo tee /etc/systemd/system/mnt-adhoc.mount >/dev/null <<'EOF'
[Unit]
Description=SSHFS mount for /mnt/adhoc
After=network-online.target
Wants=network-online.target

[Mount]
What=build@devbox:/home/builds
Where=/mnt/adhoc
Type=fuse.sshfs
Options=_netdev,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,Compression=no,IdentityFile=/home/build/.ssh/id_ed25519

[Install]
WantedBy=multi-user.target
EOF
cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now mnt-adhoc.mount
Created symlink /etc/systemd/system/multi-user.target.wants/mnt-adhoc.mount → /etc/systemd/system/mnt-adhoc.mount.

Décision : si vous voyez ce montage parfois se coincer, ajoutez une unité .automount accompagnante et montez à la demande — même principe qu’avec NFS.

Trois mini-histoires d’entreprise du pays du « ça aurait dû marcher »

Incident causé par une fausse hypothèse : « Les montages hard ne peuvent pas nous nuire »

Une entreprise moyenne faisait tourner des serveurs d’applications Debian qui récupéraient des assets statiques et quelques fragments de configuration depuis un partage NFS.
L’hypothèse était simple : les montages hard empêchent les lectures corrompues, donc ils sont « plus sûrs ». Quelqu’un a même soutenu qu’un blocage vaut mieux que de mauvaises données,
ce qui est vrai en théorie et faux en plein milieu d’un incident client-facing.

Lors d’une fenêtre de maintenance, l’équipe de stockage a redémarré le serveur NFS. Le redémarrage a pris plus de temps que prévu à cause d’un fsck.
Pendant ce temps, les serveurs applicatifs ont continué de tourner, jusqu’à ce qu’un déploiement lance un script qui a fait un find récursif sur le chemin monté.
Soudain, tous les agents de déploiement étaient bloqués. Puis l’agent de monitoring a tenté de lire un fichier sous ce chemin. Puis un hook de logrotate a fait de même.

La « mauvaise hypothèse » était de croire qu’un blocage de montage hard est localisé. Il ne l’était pas. Le point de montage faisait partie de trop de chemins d’exécution.
Le résultat n’a pas été un seul job bloqué ; c’est une flotte entière accumulant des processus bloqués et une charge due aux tempêtes de retry.
Certains nœuds se sont suffisamment dégradés pour que l’orchestrateur commence à faire flapping des services.

La correction n’a pas été « utiliser soft partout ». Ce fut automount plus une refonte : arrêter de mettre des dépendances d’exécution cruciales sur un système de fichiers distant
à moins que l’application tolère explicitement que la dépendance soit lente ou indisponible. Les montages hard sont restés pour les données qui en avaient vraiment besoin,
mais l’accès est devenu piloté par la demande et borné par le temps au niveau systemd.

Optimisation qui a échoué : « On augmente le caching et rsize/wsize »

Un autre atelier avait une ferme de build lisant de gros artefacts depuis un magasin partagé. Quelqu’un a eu la bonne idée d’augmenter rsize/wsize à 1 MiB,
d’activer un cache client agressif, et de déclarer victoire après un benchmark qui copiait quelques fichiers multi-gig rapidement.
Le tableau de bord s’est amélioré. Les gens ont applaudi. Le changement a été déployé.

Puis les bizarreries ont commencé. Les builds échouaient de façon intermittente avec « fichier introuvable » pendant des étapes qui s’attendaient à ce qu’un fichier apparaisse immédiatement
après qu’un autre job l’ait uploadé. Parfois le fichier était là mais avec un timestamp plus ancien. Parfois le listing de répertoire ne l’incluait pas pendant des secondes.
Ça ressemblait à de la cohérence éventuelle, un terme que vous ne voulez pas associer à un système de fichiers de type POSIX.

Le retour de bâton est venu du mélange de workloads : le même partage servait des lectures séquentielles volumineuses et de la coordination sensible aux métadonnées.
Le caching optimisé pour le débit a rendu la visibilité des métadonnées lente. Le système ne « bloquait » pas ; il mentait poliment pendant un instant.
C’est pire qu’un blocage parce que ça crée des bugs fantômes.

Ils se sont remis en séparant les workloads : un export NFS optimisé pour les gros artefacts, un autre pour la coordination avec une sémantique de cache plus stricte,
et un passage vers le versioning explicite des artefacts afin que les lecteurs ne dépendent jamais de « dernier fichier du répertoire » qui doit apparaître instantanément.
Leçon : le tuning de performance n’est pas universel ; il dépend de la charge, et les charges mixtes punissent l’optimisme.

Pratique ennuyeuse mais correcte qui a sauvé la mise : automount + dépendances protégées

Une organisation financière (du genre qui a des fenêtres de changement et de la paperasse pour la paperasse) faisait tourner des serveurs batch Debian
qui tiraient périodiquement des fichiers depuis un partage distant. Le partage était important, mais les serveurs avaient d’autres tâches aussi.
Des années plus tôt, un ingénieur prudent avait insisté sur deux choses : automount systemd pour tous les fichiers réseau, et timeouts explicites sur les tentatives de montage.
Personne n’aimait ça. Ce n’était pas du « travail de performance ». Ça n’apparaissait pas dans les démos de fonctionnalités.

Une nuit, le backend de stockage a eu une panne partielle — la moitié des nœuds NFS étaient joignables mais surchargés,
renvoyant des réponses suffisamment lentes pour déclencher des retransmissions côté client. Les clients sans automount auraient bloqué au démarrage après un reboot,
et tout redémarrage de service serait devenu un pari.

À la place, les serveurs batch sont restés vivants. Les jobs qui avaient besoin du partage ont échoué rapidement avec des erreurs claires et ont réessayé plus tard.
Le monitoring a continué de tourner. L’accès SSH est resté réactif. L’incident est resté contenu au « pipeline batch retardé », pas au « on ne peut plus se connecter ».

Le postmortem était ennuyeux. C’était la victoire. Les pratiques ennuyeuses ne montent pas dans les slides,
mais elles empêchent le reste de votre infra de participer à la panne d’un autre.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: boot hangs or takes minutes when the NAS is down

Cause racine : montages bloquants dans /etc/fstab sans nofail, automount, ou timeouts.

Correction : ajoutez x-systemd.automount, nofail, et des timeouts ; ou convertissez en unités systemd explicites.

2) Symptom: ls in the mount point never returns; processes stuck in D state

Cause racine : montage NFS hard + serveur non répondant ; retries noyau indéfinies.

Correction : restaurez serveur/réseau ; si vous devez récupérer l’hôte, utilisez umount -l et refondez avec automount pour éviter le blocage global.

3) Symptom: “Permission denied” on NFS, but the same path works on another client

Cause racine : mismatch UID/GID entre hôtes (ou incohérences de mappage d’id NFSv4).

Correction : standardisez les identités ; assurez des UID/GID cohérents ; évitez de « corriger » avec des options d’export dangereuses.

4) Symptom: SSHFS mount stalls after laptop sleep or Wi‑Fi roaming

Cause racine : session SSH mi-ouverte ; le dispositif NAT/état a expiré le flux.

Correction : ajoutez ServerAliveInterval/ServerAliveCountMax et reconnect ; envisagez l’automount pour un usage à la demande.

5) Symptom: SSHFS is “fine” for big files but terrible for find or small-file workloads

Cause racine : surcharge des opérations SFTP par opération ; latence métadonnée amplifiée.

Correction : n’utilisez pas SSHFS pour des workloads sensibles aux métadonnées ; utilisez NFS ou une synchronisation locale (rsync, fetch d’artefacts) selon le cas.

6) Symptom: NFS feels hung only during peak hours

Cause racine : surcharge serveur (CPU, latence disque, contention de verrous) ou congestion réseau causant des retransmissions.

Correction : confirmez avec nfsstat et métriques serveur ; scalez le serveur, déplacez les données chaudes, ou séparez les exports ; ne « tunez » pas les timeouts à la place de la capacité.

7) Symptom: mounts work by IP but not by hostname

Cause racine : problèmes DNS, délais de reverse lookup, ou enregistrements incohérents.

Correction : corrigez le DNS ; pinnez des noms stables ; ne verrouillez pas les IP dans les configs de flotte sauf si vous acceptez la dette opérationnelle.

8) Symptom: unmount hangs

Cause racine : montage occupé avec processus bloqués tenant des références ; retry NFS hard ; démon FUSE bloqué.

Correction : identifiez les détenteurs (lsof/fuser si ils répondent), utilisez umount -l ; pour FUSE, pensez à arrêter le process sshfs puis faire un lazy unmount.

Listes de contrôle / plan pas-à-pas

Step-by-step: choose the protocol (production reality edition)

1. Si plusieurs clients ont besoin des mêmes données en écriture : choisissez NFSv4.2.
2. Si c’est un accès ad-hoc sur des réseaux semi-hostiles : choisissez SSHFS.
3. Si vous avez besoin de « stockage partagé » mais que l’appli ne tolère pas la sémantique FS : n’utilisez ni l’un ni l’autre — utilisez du stockage objet, fetch HTTP d’artefacts, ou répliquez localement.
4. Décidez votre mode d’échec :
   • Préférez hard + automount pour la correction sans bloquer le boot.
   • Utilisez soft seulement quand l’appli tolère proprement les erreurs I/O.

Step-by-step: implement NFS correctly on Debian 13

1. Serveur : installez nfs-kernel-server.
2. Serveur : créez un chemin d’export dédié ; définissez l’ownership délibérément.
3. Serveur : configurez /etc/exports avec sync et no_subtree_check ; limitez les clients.
4. Client : installez nfs-common.
5. Client : testez un montage manuel avec vers=4.2,proto=tcp.
6. Client : passez à /etc/fstab avec x-systemd.automount, nofail, et des timeouts.
7. Validez : simulez une indisponibilité serveur et confirmez que l’hôte reste utilisable et démarre normalement.

Step-by-step: implement SSHFS without self-sabotage

1. Installez sshfs.
2. Confirmez que SSH non interactif marche rapidement (BatchMode).
3. Montez avec reconnect et keepalives SSH.
4. Si c’est autre chose qu’éphémère : gérez avec des unités systemd ; ajoutez automount si nécessaire.
5. Soyez prudent avec le caching quand plusieurs écrivains existent.

Operational checklist: “this share should never take the host down”

• L’automount est activé pour tous les montages réseau.
• Les timeouts de montage sont définis (device timeout et mount timeout).
• Les services critiques ne dépendent pas durement d’un montage distant sauf si conçu pour cela.
• La cohérence UID/GID est appliquée sur les clients.
• Vous avez une procédure documentée « comment détacher un montage bloqué ».
• Vous testez périodiquement les pannes : reboot serveur, coupure réseau, échec DNS.

FAQ

1) Which one is less likely to hang: SSHFS or NFS?

SSHFS a moins de chances d’enfermer le noyau dans des retries indéfinies comme un montage NFS hard, mais il a plus de chances de se bloquer ou se déconnecter sur des réseaux instables.
Pour « ne pas faire tomber l’hôte », le gagnant est NFS avec automount systemd et timeouts.

2) Should I use NFS hard or soft mounts?

Par défaut, préférez hard pour la cohérence, mais associez-le à automount afin que les pannes n’immobilisent pas le démarrage ou le lancement de services.
Utilisez soft seulement quand l’application peut tolérer des erreurs I/O et que vous préférez échouer vite que d’attendre.

3) Why does kill -9 not kill a hung process on NFS?

Parce qu’il est bloqué en sommeil non interruptible dans le noyau en attendant la fin d’un I/O. Le signal est noté mais non délivré tant que l’appel système ne retourne pas.
La correction est de restaurer le serveur/réseau ou de détacher le montage (lazy unmount) pour que le processus puisse se dénouer.

4) Why is SSHFS so slow on directories with many small files?

Les opérations métadonnées nécessitent beaucoup d’aller-retours, et SSHFS ajoute un surcoût espace utilisateur et SFTP à chacun.
Pour les workloads de petits fichiers et répertoires partagés, NFS est en général un meilleur choix.

5) Does NFSv4 require rpcbind?

NFSv4 est conçu pour être plus simple et utilise typiquement le port 2049 sans la dépendance ancienne au portmapper qu’exigeait NFSv3.
En pratique, votre environnement peut encore exécuter des services RPC associés, mais l’histoire côté pare-feu de NFSv4 est plus propre.

6) What mount options are the most important to avoid “random hangs”?

Pour les deux : les plus importantes sont l’automount systemd et les timeouts.
Pour SSHFS spécifiquement : ServerAliveInterval, ServerAliveCountMax, et reconnect.
Pour NFS : vers=4.2 explicite, proto=tcp, et choisir intentionnellement hard vs soft.

7) How do I unstick a host where anything touching the mount hangs?

D’abord, arrêtez d’y toucher. Ensuite restaurez serveur/réseau si possible. Si vous avez besoin du host immédiatement, utilisez umount -l sur le point de montage.
Si SSHFS est impliqué, arrêtez le processus sshfs (unité systemd) puis faites un lazy unmount.

8) Is SSHFS “secure enough” compared to NFS?

SSHFS s’appuie sur SSH, donc il est chiffré et authentifié par défaut. NFS peut aussi être sécurisé, mais il faut le configurer — souvent avec Kerberos pour une authentification forte.
Pour des réseaux non fiables, SSHFS est opérationnellement plus simple. Pour du stockage LAN de production fiable, NFS est en général l’outil le plus stable.

9) Should I use /etc/fstab or systemd units?

Pour NFS, /etc/fstab avec x-systemd.automount est parfaitement acceptable et facile à gérer à l’échelle.
Pour SSHFS, les unités systemd sont souvent plus propres parce que c’est un démon en espace utilisateur avec des besoins de cycle de vie.

10) What about file locking and correctness for build systems?

Si votre système de build dépend du verrouillage et de la cohérence entre écrivains multiples, NFSv4 vous donne en général une meilleure chance de correction que SSHFS.
Mais la vraie réponse est architecturale : évitez d’utiliser un système de fichiers partagé comme base de coordination si vous le pouvez.

Prochaines étapes que vous pouvez faire aujourd’hui

Si vous ne faites que trois choses, faites celles-ci :

1. Convertissez les montages réseau en automount systemd avec des timeouts explicites. Ça évite à lui seul les blocages les plus humiliants.
2. Choisissez la sémantique d’échec consciemment : NFS hard pour la correction, soft uniquement là où les erreurs sont acceptables. Arrêtez d’hériter des valeurs par défaut comme politique.
3. Exécutez les tâches de diagnostic pendant les heures calmes : capturez une baseline nfsstat -m, confirmez DNS, confirmez la reachabilité des ports, et testez une panne simulée.

Ensuite soyez un peu impitoyable : si une application ne tolère pas les bizarreries d’un système de fichiers distant, ne lui imposez pas cette dépendance.
Remplacez « répertoire partagé comme couche d’intégration » par publication d’artefacts, cache local, ou un service adapté. Votre futur vous en astreinte vous remerciera.