NFS sous Linux, le guide clair pour partager des fichiers sans piège

Un partage NFS paraît simple quand on le résume à une commande de montage. En production, il devient vite un sujet d’architecture : qui accède au dossier, depuis quelle machine, avec quels droits, sur quel réseau et avec quel comportement si le serveur ne répond plus.

Pour une PME qui modernise son infrastructure Linux ou Unix, NFS reste un outil très utile. Il permet de centraliser des fichiers, d’exposer un répertoire à plusieurs serveurs ou de relier un NAS à des machines Linux. Mais il doit être pensé comme un service réseau, pas comme un simple raccourci vers un dossier distant, car une panne de partage peut immobiliser scripts, applications internes ou sauvegardes au mauvais moment.

À quoi sert NFS concrètement ?

NFS, pour Network File System, sert à rendre un répertoire distant accessible depuis une autre machine. Le client monte ce répertoire dans son arborescence locale, par exemple sous /mnt/projets, puis les applications lisent et écrivent comme si les fichiers étaient présents sur le disque local. Pour l’utilisateur, le geste ressemble à un accès classique ; pour l’administrateur, chaque opération dépend du serveur, du réseau, des permissions et du stockage réel.

La promesse est pratique : un serveur garde les données, plusieurs clients y accèdent. Dans un atelier Linux, cela peut servir à partager des scripts, des fichiers de travail, des sauvegardes internes, des images ISO, des dépôts applicatifs ou un espace commun pour des traitements automatisés. Le poste client n’a pas besoin de copier les fichiers à chaque fois, ce qui réduit les doublons et simplifie la maintenance des versions.

Cette transparence a une contrepartie. Si le réseau ralentit, si le serveur tombe, si les droits changent ou si le montage est mal déclaré, les applications peuvent se bloquer ou produire des erreurs difficiles à lire. C’est pour cela que la conception du partage compte autant que la commande de montage.

Le bon usage commence donc par une question simple : quel problème voulez-vous résoudre ? La réponse décide du reste.

Comprendre le modèle serveur, export et client

La logique NFS se comprend en trois pièces. Le serveur possède un dossier réel, par exemple /srv/nfs/projets. Il l’exporte vers une liste de clients autorisés. Chaque client monte ensuite cet export sur un point local, par exemple /mnt/projets. Cette séparation évite beaucoup de confusions, notamment quand une application fonctionne sur le serveur mais échoue depuis une autre machine, parce que le problème peut venir de l’export, du client, du réseau ou des identités.

Le fichier d’export côté serveur décrit qui a le droit de monter quoi. On y trouve le chemin du dossier, l’adresse ou le sous-réseau client, puis les options d’accès. Ce n’est pas un détail administratif : une ligne trop large peut exposer des données à des machines qui n’en ont pas besoin, et une ligne trop vague complique la revue de sécurité.

Côté client, le montage indique le serveur, le chemin exporté et les options locales. Il peut être lancé à la main pour tester, puis déclaré dans la configuration du système si le montage doit revenir après redémarrage. Là encore, la simplicité est trompeuse : un montage automatique mal pensé peut ralentir le démarrage si le serveur est indisponible, surtout si aucune option de temporisation ou dépendance réseau n’a été prévue dans le système.

Une bonne documentation interne doit reprendre ces quatre lignes. Elle doit aussi préciser le propriétaire fonctionnel du dossier, le niveau de criticité, la sauvegarde associée et les applications dépendantes. Si personne ne sait quel serveur exporte quel chemin, quels clients sont autorisés et pourquoi l’option a été choisie, le dépannage deviendra lent. NFS est stable quand la cartographie des partages reste simple, tenue à jour et compréhensible par une autre personne que l’administrateur initial.

Configurer un partage NFS sans brûler les étapes

Avant d’installer les paquets, définissez le besoin. Quel dossier partager ? Quels clients doivent y accéder ? Lecture seule ou lecture-écriture ? Fichiers critiques ou données temporaires ? Cette préparation évite de finir avec un export universel qui fonctionne vite, mais qui contredit la politique d’accès et devient difficile à restreindre après adoption par les équipes, surtout si plusieurs services commencent à dépendre du même chemin.

Le déroulé de base reste simple sur une distribution Linux classique. Gardez-le volontairement séquentiel pour éviter les oublis :

Pour approfondir ce point, consultez zip unzip linux, qui traite plus précisément de compresser et extraire des fichiers zip sous linux sans casser vos archives.

1. installer les paquets serveur NFS adaptés à la distribution ;
2. créer ou choisir le dossier à partager ;
3. régler propriétaire, groupe et permissions POSIX ;
4. déclarer l’export avec clients autorisés et options ;
5. recharger ou redémarrer le service NFS ;
6. tester le montage depuis un client ;
7. documenter le montage automatique si nécessaire.

Un exemple de logique d’export peut ressembler à ceci, à adapter à votre distribution et à votre réseau :

/srv/nfs/projets 192.168.10.0/24(rw,sync,root_squash)

Cette ligne n’est pas une recette universelle. Elle montre seulement trois décisions : le chemin exporté, le réseau client et quelques options. Le paramètre root_squash, par exemple, évite qu’un utilisateur root côté client soit traité comme root côté serveur. Pour un premier partage, cette prudence vaut mieux qu’un export trop permissif qui sera ensuite difficile à justifier.

Le test doit ensuite vérifier plus que le montage. Créez un fichier, modifiez-le, contrôlez son propriétaire, redémarrez le client, puis observez ce qui se passe si le serveur NFS est coupé temporairement. Cette séquence courte révèle souvent les vrais problèmes avant qu’ils touchent les utilisateurs.

Ne passez pas en production sur un seul test réussi. Un montage visible ne prouve pas encore un service robuste.

Choisir entre NFSv3 et NFSv4

Pour un nouvel environnement, NFSv4 est généralement le meilleur point de départ. Il simplifie plusieurs aspects, passe par un modèle plus moderne et évite certaines dépendances historiques des versions plus anciennes. NFSv3 reste présent dans des parcs existants, des appliances ou des contraintes de compatibilité ; il ne faut donc pas l’écarter sans inventaire, mais il ne doit pas être choisi par simple habitude lorsque le parc sait déjà travailler proprement en v4.

Le choix ne doit pas être théorique. Regardez les clients réels, la distribution serveur, le NAS, l’hyperviseur, les options de sécurité attendues et la supervision disponible. Si un équipement ne supporte correctement qu’une version donnée, la compatibilité terrain prime sur la préférence générale. Cette vérification évite les migrations qui semblent propres dans un inventaire, mais cassent un outil métier parce qu’un client ancien ne gère pas le même comportement.

Il faut aussi éviter le faux confort des migrations silencieuses. Changer de version peut modifier des détails de montage, de verrouillage, de ports, de noms de domaine, d’identités ou de chemins pseudo-root. Une migration NFS se teste avec les applications qui utilisent les fichiers, pas seulement avec une commande mount réussie sur une machine d’administration isolée.

Dans une PME, la bonne décision est souvent pragmatique : utiliser la version la plus récente correctement supportée par tous les composants. Un protocole plus moderne mal maîtrisé ne vaut pas mieux qu’un protocole ancien bien isolé, documenté et surveillé. La priorité reste la preuve de compatibilité : système serveur, client, NAS, hyperviseur, pare-feu, supervision et procédures d’exploitation doivent parler le même langage avant la bascule.

Droits, UID/GID et sécurité réseau

NFS ne suffit pas à lui seul à “gérer les droits”. Il s’appuie fortement sur les identités Unix/Linux, donc sur les UID, les GID, les groupes et les permissions du système de fichiers. Si l’utilisateur 1001 ne représente pas la même personne sur deux machines, les accès peuvent devenir incohérents, même si les noms affichés semblent rassurants dans l’interface ou dans les commandes habituelles.

Ce point surprend beaucoup de débutants. Le montage peut être parfait, le serveur joignable, le chemin visible, et pourtant l’écriture échoue. Dans ce cas, le problème se trouve souvent dans le propriétaire du dossier, le groupe, le masque de création, l’option d’export ou une correspondance d’identités mal alignée. Pour une PME, la solution passe souvent par un annuaire ou une convention d’UID/GID, pas par une multiplication d’exceptions locales que personne ne saura maintenir.

La sécurité commence donc par un périmètre clair. N’exportez pas vers “tout le réseau” par confort. Limitez les clients, segmentez si nécessaire, filtrez le port NFS et évitez d’exposer un partage NFS sur Internet. Ce protocole est fait pour un environnement maîtrisé, pas pour compenser une absence de cloisonnement.

1. root_squash : limite les risques liés au compte root côté client ;
2. ro ou rw : choisit lecture seule ou lecture-écriture selon le besoin réel ;
3. sync : privilégie une écriture plus prudente, au prix possible de performances ;
4. subtree_check ou no_subtree_check : à choisir selon la structure exportée et la distribution ;
5. sec : à regarder si vous mettez en place des mécanismes d’authentification plus avancés.

Le bon réflexe est de commencer restrictif, puis d’ouvrir uniquement ce qui manque. Un export trop large “pour que ça marche” finit souvent par rester en place. C’est précisément ce type de dette qui complique les audits et les migrations Linux quelques mois plus tard.

Deux moments où NFS révèle ses faiblesses

Les incidents apparaissent rarement dans la commande elle-même : ils viennent du contexte autour du montage.

Mise en production

Un partage qui fonctionne en test peut bloquer si le pare-feu, les noms DNS ou les droits UID/GID diffèrent.

Dépannage

Quand le montage semble correct mais que l’accès échoue, il faut lire export, réseau, service et journaux dans le bon ordre.

Les erreurs de débutant qui coûtent du temps

La première erreur est de confondre partage de fichiers et sauvegarde. NFS donne accès à des fichiers distants, mais si un utilisateur supprime un dossier, chiffre des données ou écrase un fichier, le partage ne protège pas automatiquement l’historique. Il faut une vraie sauvegarde, testée séparément.

La deuxième erreur est de copier une ligne d’export sans comprendre ses options. Un exemple trouvé en ligne peut être utile pour apprendre, mais il ne connaît ni votre réseau, ni vos utilisateurs, ni vos contraintes de sécurité. Les options doivent être justifiées dans la documentation interne.

La troisième erreur est de tester uniquement depuis le serveur. Le test utile part du client, avec l’utilisateur ou le service qui écrira réellement. C’est là que les problèmes de droits, de groupes, de pare-feu ou de montage automatique apparaissent.

La quatrième erreur consiste à oublier le comportement en cas de panne. Si le serveur NFS disparaît, que font les applications ? Attendent-elles indéfiniment ? Produisent-elles des erreurs propres ? Peuvent-elles redémarrer sans intervention manuelle ? Pour une application métier, le scénario de coupure doit être testé avant que les utilisateurs découvrent eux-mêmes la réponse.

Dépanner un montage NFS méthodiquement

Quand un montage NFS échoue, évitez de modifier trois paramètres en même temps. Travaillez par couches : réseau, service serveur, export, client, droits. Cette méthode paraît lente, mais elle évite de créer une panne secondaire pendant que vous cherchez la première. Elle permet aussi de transmettre le diagnostic à un collègue sans dépendre d’une intuition ou d’un historique de commandes incomplet.

Commencez par vérifier que le serveur répond et que le service NFS est actif. Contrôlez ensuite que le client est bien autorisé dans l’export. Puis testez le montage manuellement avec une commande simple avant de corriger la configuration permanente. Ce déroulé donne une preuve à chaque étape.

Si le montage réussit mais que l’accès échoue, concentrez-vous sur les droits. Regardez le propriétaire du dossier côté serveur, les groupes, les UID/GID, les options d’export et le compte utilisé par l’application. Beaucoup de tickets NFS “réseau” sont en réalité des tickets de permissions.

Si les performances sont mauvaises, la lecture change. Il faut regarder la latence, le débit, la taille des fichiers, les options de montage, la charge serveur, le stockage sous-jacent et les pics d’usage. Un petit fichier modifié très souvent ne crée pas le même profil qu’un gros flux séquentiel.

Performances et exploitation au quotidien

Les performances NFS ne dépendent pas uniquement du protocole. Elles viennent du stockage serveur, du réseau, de la taille des fichiers, du nombre de clients, des options de montage et du comportement des applications. Un partage rapide pour des archives peut devenir médiocre pour une application qui ouvre, verrouille et modifie de nombreux petits fichiers.

Mesurez avant d’accuser NFS. Le protocole n’est qu’une couche dans la chaîne, pas toute l’infrastructure.

Dans un environnement PME, l’objectif n’est pas de chercher le réglage parfait dès le premier jour. Il faut d’abord obtenir une base stable : réseau fiable, serveur dimensionné, sauvegarde testée, droits cohérents et journaux exploitables. Ensuite seulement, vous pouvez ajuster les options de montage, le cache, la taille des lectures/écritures ou la stratégie de redémarrage automatique, en gardant une trace de chaque changement pour pouvoir revenir en arrière.

La supervision doit rester simple mais réelle. Surveillez l’espace disque, l’état du service NFS, les erreurs de montage côté client et les variations de latence. Ajoutez aussi un contrôle humain dans la procédure : qui est alerté, qui peut démonter/remonter un partage, qui sait revenir à une configuration précédente ? Sans ce minimum, un incident de stockage devient vite un incident applicatif.

La performance se pilote avec des preuves, pas avec des impressions. C’est aussi une discipline d’exploitation quotidienne, même sur un partage interne.

Quand NFS est un bon choix pour une PME

NFS est un bon choix quand le périmètre est clair : serveurs Linux, réseau interne maîtrisé, besoin de fichiers partagés, droits Unix cohérents et supervision minimale. Il devient particulièrement intéressant pour des scripts communs, des exports NAS vers Linux, des environnements de calcul, des dépôts applicatifs ou certains usages de virtualisation, à condition que les dépendances soient connues et que le partage ne devienne pas un point unique de panne ignoré.

Il est moins adapté quand les utilisateurs travaillent surtout depuis Windows, quand les droits doivent suivre finement les groupes Active Directory sans intégration réfléchie, ou quand les postes doivent travailler hors ligne. Dans ces cas, SMB, une synchronisation de fichiers ou une solution applicative peuvent être plus cohérents.

La bonne approche consiste à commencer petit : un partage, quelques clients, des droits documentés, un test de panne et une sauvegarde vérifiée. Ensuite seulement, vous pouvez généraliser. NFS récompense les architectures sobres ; il punit les exports improvisés.

Pour une DSI en transition Linux, la prochaine action est simple : inventorier les partages existants, identifier les clients, puis choisir un premier cas peu critique pour valider le modèle. Une fois ce socle propre, NFS devient un outil fiable plutôt qu’une boîte noire.

Sources et vérifications