Utiliser NFS sur Linux

NFS (Network File System) permet de partager des répertoires entre plusieurs serveurs Linux, comme s'ils étaient locaux. Vous montez un dossier distant avec une simple commande mount et vos applications y accèdent de façon transparente. Ce guide vous accompagne de l'installation d'un serveur NFSv4.2 sur Ubuntu 24.04 jusqu'au montage côté client, avec les options de performance, la sécurité Kerberos et le dépannage, toutes les commandes ont été testées en lab.

Ce que vous allez apprendre

• Fonctionnement de NFS : protocole, versions, architecture client-serveur
• Installation : nfs-kernel-server (serveur) et nfs-common (client)
• Configuration des exports : /etc/exports, options rw, ro, sync
• Montage côté client : commande mount, /etc/fstab, négociation NFSv4.2
• Permissions : root_squash, all_squash, idmapd
• Performances : rsize, wsize, nconnect, benchmarks
• Sécurité Kerberos : krb5, krb5i, krb5p
• Dépannage : erreurs fréquentes et résolutions testées

Qu'est-ce que NFS ?

NFS (Network File System) est un protocole réseau qui permet à un serveur de partager des répertoires avec d'autres machines sur le réseau. Créé en 1984 par Sun Microsystems, il est devenu un standard dans le monde Unix/Linux.

Analogie : imaginez un serveur de fichiers comme une bibliothèque centrale. Chaque machine cliente « emprunte » un rayon entier (un répertoire partagé) et le place dans sa propre étagère (point de montage). Les livres restent physiquement à la bibliothèque, mais chaque emprunteur les lit et les modifie comme s'ils étaient chez lui.

Évolution des versions

Version	Année	Apports principaux
NFSv2	1989	Première version publique, fichiers limités à 2 Go
NFSv3	1995	Fichiers volumineux, écriture asynchrone, meilleur cache
NFSv4	2003	Protocole à états, un seul port (2049/tcp), sécurité Kerberos native
NFSv4.1	2010	Sessions, pNFS (parallel NFS) pour la performance
NFSv4.2	2016	Copie côté serveur, sparse files, étiquetage sécurité

Glissez pour voir

Pourquoi NFSv4.2 ?

Les noyaux Linux récents (5.x+) négocient automatiquement la version la plus haute supportée. Sur Ubuntu 24.04, c'est NFSv4.2 par défaut. Plus besoin des démons rpcbind, mountd ou statd : un seul port TCP 2049 suffit.

Pourquoi utiliser NFS ?

NFS reste pertinent pour plusieurs cas d'usage concrets :

• Centraliser les données : un seul emplacement à sauvegarder au lieu de copier les fichiers sur chaque machine
• Partager des répertoires home : les utilisateurs retrouvent leurs fichiers sur n'importe quel poste
• Distribuer des configurations : scripts, certificats, fichiers partagés accessibles depuis tout le parc
• Fournir du stockage à Kubernetes : NFS sert de backend pour les PersistentVolumes en lecture/écriture partagée (RWX)

NFS vs alternatives

Critère	NFS	iSCSI	Samba (CIFS)	SSHFS
Protocole	Fichiers	Bloc	Fichiers	Fichiers
Port	2049/tcp	3260/tcp	445/tcp	22/tcp
Clients natifs	Linux, macOS	Linux, Windows	Windows, Linux	Linux, macOS
Performance	Bonne	Excellente	Moyenne	Faible
Complexité	Faible	Modérée	Faible	Très faible
Cas d'usage	Partages Linux	Disques virtuels	Partages Windows	Accès ponctuel

Glissez pour voir

Prérequis

• 2 machines Ubuntu 24.04 (physiques ou virtuelles)
• Connectivité réseau entre les deux (même sous-réseau ou routé)
• Accès root ou sudo sur les deux machines
• Port 2049/tcp ouvert entre serveur et client

Pour reproduire ce lab, deux VMs KVM suffisent : un serveur (192.168.122.50) et un client (192.168.122.225).

Installation du serveur NFS

Le paquet nfs-kernel-server fournit le serveur NFS intégré au noyau Linux. C'est la méthode recommandée sur Ubuntu car elle offre les meilleures performances.

Ubuntu / Debian

sudo apt update
sudo apt install nfs-kernel-server

Rocky / RHEL

sudo dnf install nfs-utils

Le service démarre automatiquement. Vérifiez son état :

sudo systemctl status nfs-server

Résultat attendu : Active: active (exited). Le statut exited est normal car le serveur NFS fonctionne via des threads noyau, pas un processus classique.

Configurer les exports

Le fichier /etc/exports définit quels répertoires le serveur partage et avec quelles permissions. Chaque ligne décrit un export : le chemin local, le réseau autorisé et les options entre parenthèses.

Créer les répertoires partagés

Commencez par créer la structure de répertoires. Avec NFSv4, on définit une racine d'export (ici /srv/nfs) qui sert de point d'entrée unique pour tous les partages :

sudo mkdir -p /srv/nfs/partage /srv/nfs/projets
sudo chown nobody:nogroup /srv/nfs/partage /srv/nfs/projets

Configurer /etc/exports

Éditez le fichier /etc/exports pour déclarer vos partages :

sudo nano /etc/exports

/etc/exports

/srv/nfs        192.168.122.0/24(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/partage 192.168.122.0/24(rw,sync,no_subtree_check,no_root_squash)
/srv/nfs/projets 192.168.122.0/24(ro,sync,no_subtree_check,all_squash)

Comprendre les options d'export

Option	Signification	Quand l'utiliser
rw	Lecture et écriture autorisées	Partages collaboratifs
ro	Lecture seule	Distributions de configs, documentation
sync	Écrit sur disque avant de répondre au client	Toujours en production (fiabilité)
async	Répond avant l'écriture sur disque	Tests de performance uniquement (risque de perte)
fsid=0	Désigne la racine du pseudo-filesystem NFSv4	Une seule ligne avec cette option
crossmnt	Traverse les sous-montages automatiquement	Sur la racine d'export
no_subtree_check	Désactive la vérification de sous-arbre	Recommandé (performances + stabilité)
no_root_squash	Le root du client reste root sur le serveur	Déploiement automatisé, Ansible
root_squash	Le root du client devient nobody (défaut)	Production (sécurité)
all_squash	Tous les utilisateurs deviennent nobody	Partages publics en lecture seule
anonuid=N / anongid=N	UID/GID utilisé pour les utilisateurs « squashés »	Contrôler les permissions du nobody

Glissez pour voir

Attention à no_root_squash

no_root_squash donne au root du client les pleins pouvoirs sur le serveur. Utilisez-le uniquement pour des machines de confiance (orchestrateurs, scripts d'automatisation). En production, préférez root_squash (activé par défaut).

Appliquer les exports

Après toute modification de /etc/exports, appliquez les changements :

sudo exportfs -ra

Vérification, Affichez les exports actifs avec leurs options :

sudo exportfs -v

/srv/nfs        192.168.122.0/24(rw,sync,wdelay,crossmnt,root_squash,...,fsid=0,...)
/srv/nfs/partage 192.168.122.0/24(rw,sync,wdelay,no_root_squash,...,no_subtree_check,...)
/srv/nfs/projets 192.168.122.0/24(ro,sync,wdelay,root_squash,...,all_squash,...,no_subtree_check,...)

Monter un partage NFS côté client

Installer le client NFS

Ubuntu / Debian

sudo apt update
sudo apt install nfs-common

Rocky / RHEL

sudo dnf install nfs-utils

Montage manuel

Créez les points de montage et montez les partages :

sudo mkdir -p /mnt/nfs-partage /mnt/nfs-projets
sudo mount -t nfs4 192.168.122.50:/partage /mnt/nfs-partage
sudo mount -t nfs4 192.168.122.50:/projets /mnt/nfs-projets

Chemin relatif à la racine NFSv4

Avec NFSv4 et fsid=0, les chemins sont relatifs à la racine d'export. Le serveur exporte /srv/nfs comme racine, donc /srv/nfs/partage se monte via serveur:/partage (et non serveur:/srv/nfs/partage).

Vérification, Confirmez le montage et la version négociée :

mount | grep nfs4

192.168.122.50:/partage on /mnt/nfs-partage type nfs4 (rw,...,vers=4.2,...,proto=tcp,...)
192.168.122.50:/projets on /mnt/nfs-projets type nfs4 (ro,...,vers=4.2,...,proto=tcp,...)

Le résultat montre vers=4.2 : le client et le serveur ont automatiquement négocié NFSv4.2, la version la plus récente.

Tester la lecture et l'écriture

Créez un fichier depuis le serveur, puis vérifiez depuis le client :

# Sur le client : écrire sur le partage rw
echo "Données partagées via NFS" | sudo tee /mnt/nfs-partage/test.txt

# Vérifier la lecture
cat /mnt/nfs-partage/test.txt

Données partagées via NFS

Testez que le partage en lecture seule refuse bien l'écriture :

echo "test" | sudo tee /mnt/nfs-projets/interdit.txt

tee: /mnt/nfs-projets/interdit.txt: Read-only file system

Le partage projets est bien en lecture seule : le serveur refuse l'écriture conformément à l'option ro configurée dans /etc/exports.

Montage automatique via /etc/fstab

Pour que les partages se montent automatiquement au démarrage, ajoutez-les dans /etc/fstab :

/etc/fstab

192.168.122.50:/partage /mnt/nfs-partage nfs4 defaults,_netdev 0 0
192.168.122.50:/projets /mnt/nfs-projets nfs4 defaults,ro,_netdev 0 0

L'option _netdev indique au système d'attendre que le réseau soit disponible avant de tenter le montage. Sans elle, le démarrage peut rester bloqué si le serveur NFS n'est pas joignable.

Vérification, Testez le montage sans redémarrer :

sudo mount -a
df -h | grep nfs

Options de montage utiles

Option	Effet	Recommandation
vers=4.2	Force NFSv4.2	Utile si le serveur supporte plusieurs versions
hard	Retente indéfiniment en cas de coupure (défaut)	Production (pas de perte de données)
soft	Abandonne après un délai	Scripts batch non critiques
noatime	Ne met pas à jour la date de dernier accès	Performance (réduit les écritures)
rsize=262144	Taille des blocs de lecture (octets)	Augmenter si bande passante disponible
wsize=262144	Taille des blocs d'écriture (octets)	Idem
nconnect=4	Connexions TCP parallèles	Réseau rapide (10 Gbps+)
_netdev	Attend le réseau pour monter	Obligatoire dans fstab

Glissez pour voir

hard ou soft : un choix qui peut coûter des données

Gardez hard (le défaut). Si le serveur NFS tombe, les processus qui accèdent au montage passent en état D (uninterruptible sleep) : ils bloquent jusqu'au retour du serveur, kill -9 n'a aucun effet et la charge système grimpe. C'est gênant, mais réversible.

soft est plus dangereux : man nfs avertit qu'il peut provoquer une corruption silencieuse des données. Après expiration du délai, une écriture échoue alors que l'application la croit réussie. Réservez-le aux accès en lecture non critiques, où la réactivité prime sur l'intégrité.

Si un montage hard vous inquiète, ajustez timeo et retrans plutôt que de passer à soft. L'ancienne option intr est ignorée depuis le noyau 2.6.25 : elle ne sert plus à rien.

Gestion des permissions : UID/GID et idmapd

NFS utilise les UID et GID numériques pour les permissions. Si l'utilisateur bob a l'UID 1000 sur le serveur et 1001 sur le client, les fichiers apparaîtront avec le mauvais propriétaire.

Deux approches

Synchroniser les UID/GID

La méthode la plus simple : assurer que chaque utilisateur a le même UID et GID sur toutes les machines. C'est l'approche recommandée dans un petit environnement.

# Vérifier l'UID d'un utilisateur
id bob
# uid=1000(bob) gid=1000(bob) groups=1000(bob)

Si les UID diffèrent, modifiez-les :

sudo usermod -u 1000 bob
sudo groupmod -g 1000 bob
sudo find / -user ANCIEN_UID -exec chown -h 1000 {} \;

Configurer idmapd

Pour les environnements plus grands, idmapd résout les noms d'utilisateurs entre client et serveur. Configurez le même domaine sur toutes les machines dans /etc/idmapd.conf :

/etc/idmapd.conf

[General]
Domain = lab.local

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

Redémarrez le service :

sudo systemctl restart nfs-idmapd

Fichiers appartenant à nobody

Si tous vos fichiers montés affichent nobody:nogroup comme propriétaire, c'est un symptôme classique : le domaine idmapd diffère entre serveur et client, ou le service nfs-idmapd n'est pas actif.

Optimiser les performances

Benchmark de référence

Mesurez les débits avant toute optimisation pour avoir une base de comparaison :

# Écriture (100 Mo, I/O direct)
dd if=/dev/zero of=/mnt/nfs-partage/bench bs=1M count=100 oflag=direct

# Lecture
dd if=/mnt/nfs-partage/bench of=/dev/null bs=1M iflag=direct

Sur notre lab (réseau virtio, même hôte KVM), les résultats sont :

Sens	Débit mesuré
Écriture	~135 Mo/s
Lecture	~2,7 Go/s

Glissez pour voir

Un benchmark sur le même hôte mesure le cache

Ces chiffres viennent d'un lab où client et serveur tournent sur le même hôte KVM : la lecture à 2,7 Go/s reflète surtout le cache mémoire, pas le réseau. En production, NFS est limité par la latence réseau (RTT) autant que par le débit, surtout pour beaucoup de petits fichiers dont les opérations de métadonnées sont synchrones. Pour un benchmark réaliste, mesurez depuis un client distant, avec un jeu de données plus grand que la RAM, cache vidé (echo 3 | sudo tee /proc/sys/vm/drop_caches).

Tuning du montage

Pour de meilleurs débits, augmentez la taille des blocs et activez les connexions parallèles :

sudo mount -t nfs4 \
  -o rsize=1048576,wsize=1048576,noatime,nconnect=4 \
  192.168.122.50:/partage /mnt/nfs-partage

Équivalent dans /etc/fstab :

192.168.122.50:/partage /mnt/nfs-partage nfs4 rsize=1048576,wsize=1048576,noatime,nconnect=4,_netdev 0 0

Tuning système

Augmentez les buffers réseau du noyau pour supporter les transferts volumineux :

/etc/sysctl.d/99-nfs-perf.conf

net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

sudo sysctl -p /etc/sysctl.d/99-nfs-perf.conf

Surveillance

Commande	Usage
nfsstat -s	Statistiques NFS côté serveur (appels RPC)
nfsstat -c	Statistiques NFS côté client
mountstats	Détails par montage (latence, retransmissions)
iostat -x 1	Activité disque en temps réel

Glissez pour voir

# Voir les statistiques détaillées d'un montage
mountstats /mnt/nfs-partage

Sécuriser NFS avec Kerberos

Par défaut, NFS utilise le mode sec=sys (AUTH_SYS), que man nfs résume sans détour : aucune sécurité cryptographique. L'autorisation repose sur deux éléments faibles : l'adresse IP déclarée dans /etc/exports et l'UID que le client s'attribue lui-même à chaque requête. Le serveur fait confiance à cet UID sans le vérifier : un attaquant disposant des droits root sur une machine du réseau peut forger n'importe quel UID et lire les fichiers correspondants. Même root_squash ne protège que l'UID 0, pas les autres.

Conséquence concrète : sans Kerberos, NFS n'est sûr que sur un réseau de confiance et isolé (VLAN dédié, pare-feu strict). Pour tout réseau partagé ou exposé, Kerberos ajoute une authentification forte et, en option, le chiffrement des données en transit.

Les trois niveaux de sécurité

Niveau	Option	Authentification	Intégrité	Chiffrement	Impact performance
Basique	sec=krb5	Oui	Non	Non	Faible
Intégrité	sec=krb5i	Oui	Oui	Non	Modéré
Complet	sec=krb5p	Oui	Oui	Oui	Significatif (~30–50 %)

Glissez pour voir

Prérequis Kerberos

• Un KDC (Key Distribution Center), serveur d'authentification central (MIT Kerberos ou FreeIPA)
• Horloges synchronisées via NTP sur toutes les machines (tolérance ±5 min)
• DNS fonctionnel avec résolution directe et inverse (Kerberos utilise les FQDN)

Configuration côté serveur

1. Installer les paquets Kerberos :

   sudo apt install krb5-user nfs-kernel-server

2. Créer un principal NFS dans le KDC :

   kadmin -q "addprinc -randkey nfs/serveur.lab.local"

3. Exporter la clé dans un keytab :

   kadmin -q "ktadd -k /etc/krb5.keytab nfs/serveur.lab.local"
   sudo chmod 600 /etc/krb5.keytab

4. Configurer l'export avec Kerberos :

   /etc/exports

   /srv/nfs 192.168.122.0/24(rw,sync,fsid=0,crossmnt,sec=krb5p)

5. Redémarrer le serveur :

   sudo exportfs -ra
   sudo systemctl restart nfs-server

Configuration côté client

1. Installer les paquets :

   sudo apt install krb5-user nfs-common

2. Obtenir un ticket Kerberos :

   kinit utilisateur@LAB.LOCAL
   klist   # vérifier le ticket

3. Monter avec Kerberos :

   sudo mount -t nfs4 -o sec=krb5p serveur.lab.local:/ /mnt/nfs

Vérification :

mount | grep nfs4 | grep sec=krb5p

Si la ligne apparaît, le chiffrement Kerberos est actif.

NFS comme backend Kubernetes

NFS occupe une place particulière dans Kubernetes : il fournit le mode d'accès ReadWriteMany (RWX), où plusieurs nœuds montent le même volume en lecture-écriture. Peu de backends l'offrent (la plupart des disques bloc sont limités à un seul nœud), ce qui fait de NFS une solution simple pour partager des données entre pods.

Deux intégrations existent. Le csi-driver-nfs (nfs.csi.k8s.io, version 4.13.x en 2026) est l'approche moderne et recommandée : provisioning dynamique, snapshots et clonage à partir d'un serveur NFS existant. L'ancien nfs-subdir-external-provisioner (figé depuis début 2023) reste répandu mais n'est plus guère maintenu ; il crée un sous-répertoire par volume.

Deux pièges reviennent en cluster. Les permissions : si l'export est en root_squash, les conteneurs tournant en root et les chown récursifs déclenchés par fsGroup se heurtent à la projection vers l'utilisateur anonyme ; il faut cadrer les UID des conteneurs ou ajuster anonuid. Et le point de défaillance : un serveur NFS unique devient un SPOF pour tous les volumes RWX qui en dépendent.

Dépannage

Symptôme	Cause probable	Solution
mount bloqué ou timeout	Service NFS arrêté sur le serveur	sudo systemctl start nfs-server
mount.nfs4: access denied	IP du client absente de /etc/exports	Vérifier le réseau dans /etc/exports et exportfs -ra
Permission denied sur les fichiers	root_squash actif (root → nobody)	Utiliser no_root_squash ou travailler sans sudo
Fichiers appartiennent à nobody	Domaine idmapd différent client/serveur	Synchroniser /etc/idmapd.conf (même Domain)
Montage en NFSv3 au lieu de v4	Client négociant une version basse	Forcer mount -t nfs4 ou vers=4.2 dans fstab
Performances dégradées	Blocs trop petits (rsize/wsize)	Augmenter à 1048576 + activer nconnect=4
kinit échoue	Horloge désynchronisée (>5 min) vs KDC	Synchroniser avec NTP : sudo systemctl restart chronyd
Port 2049 filtré	Pare-feu bloque le trafic NFS	sudo ufw allow from 192.168.122.0/24 to any port 2049
Stale file handle	Export modifié sans exportfs -ra	sudo exportfs -ra puis re-monter côté client

Glissez pour voir

Diagnostic pas à pas

En cas de problème, suivez cette chaîne : client → réseau → serveur → exports.

1. Le client résout-il le nom du serveur ? (ping serveur)
2. Le port 2049 est-il ouvert ? (nc -zv serveur 2049)
3. Le serveur exporte-t-il le partage ? (exportfs -v sur le serveur)
4. Les options d'export correspondent-elles ? (IP, rw/ro, squash)

Quand NFS n'est pas le bon choix

NFS est simple et efficace, mais il a des limites qu'il vaut mieux connaître avant de l'imposer partout.

• Un serveur unique est un SPOF. Tous les clients en dépendent. La haute disponibilité NFS (Pacemaker + DRBD) est possible mais complexe à opérer ; si la résilience est critique, un stockage distribué par conception comme CephFS est plus adapté.
• Les millions de petits fichiers font souffrir NFS : chaque opération de métadonnées synchrone paie un aller-retour réseau. Un système de fichiers distribué ou un stockage objet sont alors préférables.
• Les bases de données s'accommodent mal du verrouillage réseau et des garanties de cohérence de NFS : pour un SGBD, préférez un stockage bloc (iSCSI ou disque local).

Le bon réflexe : NFS pour du partage de fichiers entre machines de confiance, un outil dédié dès que la résilience, la latence sur petits fichiers ou une base de données entrent en jeu.

À retenir

• NFS permet de partager des répertoires entre machines Linux via le réseau, de façon transparente pour les applications
• NFSv4.2 est la version actuelle : un seul port (2049/tcp), négociation automatique, sécurité Kerberos native
• Le fichier /etc/exports sur le serveur contrôle quoi est partagé, à qui et avec quelles permissions
• L'option fsid=0 désigne la racine du pseudo-filesystem NFSv4, les clients montent des chemins relatifs à cette racine
• Utilisez sync en production (fiabilité), root_squash (sécurité) et _netdev dans fstab (stabilité au boot)
• Pour les performances, augmentez rsize/wsize à 1 Mo et activez nconnect=4 sur les réseaux rapides
• Le mode par défaut sec=sys ne vérifie pas les UID : sans Kerberos (sec=krb5p), NFS n'est sûr que sur un réseau isolé et de confiance
• Conservez hard (le défaut) ; soft peut corrompre des données silencieusement si le serveur tombe
• NFS brille en RWX comme backend Kubernetes, mais reste un SPOF : pour la résilience ou une base de données, regardez CephFS ou un stockage bloc

Prochaines étapes

iSCSI : disques virtuels en réseau Protocole bloc complémentaire à NFS pour le stockage réseau

Longhorn : stockage Kubernetes répliqué Volumes persistants répliqués avec NFS comme backend de backup

Ceph : stockage distribué unifié Solution de stockage bloc, fichier et objet à grande échelle

MinIO : stockage objet S3 Alternative objet compatible S3 pour les backups et artefacts

×

📖 Voir la documentation →