Ubuntu Manpage: nfs – Format de fstab et options pour les systèmes de fichiers nfs

NOM

       nfs – Format de fstab et options pour les systèmes de fichiers nfs

SYNOPSIS

       /etc/fstab

DESCRIPTION

NFS est un protocole aux normes de l'Internet créé par Sun Microsystems en 1984. NFS a été développé pour
permettre le partage de fichiers entre des systèmes connectés à un réseau local. Selon la configuration
du noyau, le client Linux de NFS peut gérer les versions 3, 4.0, 4.1 ou 4.2.

La commande mount(8) lie un système de fichiers à un point de montage donné dans la hiérarchie d'espaces
de noms du système. Le fichier /etc/fstab décrit la façon dont mount(8) doit recréer la hiérarchie
d'espaces de noms du système de fichiers à partir de systèmes de fichiers indépendants (dont ceux
exportés par des serveurs NFS). Chacune des lignes du fichier /etc/fstab décrit un seul système de
fichiers, son point de montage et un ensemble d'options de montage par défaut pour ce point de montage.

Dans le cas des montages de systèmes de fichiers NFS, une ligne dans le fichier /etc/fstab indique le nom
du serveur, le chemin du répertoire exporté à monter, le répertoire local qui sera le point de montage,
le type de système de fichiers à monter et la liste des options de montage qui indiquent la façon dont le
système de fichiers sera monté et quel sera le comportement du client NFS lorsqu'il accédera aux fichiers
du point de montage. Les cinquième et sixième champs de chaque ligne ne sont pas utilisés par NFS et par
conséquent contiennent par convention le chiffre zéro. Par exemple :

serv:chemin /pt_montage type_sdf option,option,... 0 0

Le nom du serveur et le chemin de partage sont séparés par un deux-points, tandis que les options de
montage sont séparées par des virgules. Les champs restants sont séparés par des espaces ou des
tabulations.

Le nom d’hôte du serveur peut être un nom d'hôte non qualifié, un nom de domaine pleinement qualifié
(« fully qualified domain name »), une adresse IPv4 sous forme de quadruplet avec points ou une adresse
IPv6 entourée par des crochets. Les adresses IPv6 de liens locaux ou de sites locaux doivent être
accompagnées d'un identifiant d'interface. Consulter ipv6(7) pour des détails quant à l'écriture des
adresses IPv6 brutes.

Le champ type_sdf contient « nfs ». La valeur « nfs4 » est obsolète.

OPTIONS DE MONTAGE

Consultez mount(8) pour la description des options de montage génériques disponibles pour tous les
systèmes de fichiers. Si vous n'avez pas besoin d'indiquer d'options de montage particulières, utilisez
l'option générique defaults dans /etc/fstab.

Options prises en charge par toutes les versions
Les options suivantes peuvent être utilisées avec n'importe quelle version de NFS.

nfsvers=n Le numéro de version du protocole NFS utilisé pour contacter le service NFS du serveur. Si
le serveur ne gère pas la version demandée, la requête de montage échoue. Si cette option
n'est pas définie, le client essaie d’abord la version 4.2, puis essaie une version
inférieure jusqu’à trouver une version prise en charge par le serveur.

vers=n Cette option est une solution de remplacement de l'option nfsvers. Elle est incluse pour
des raisons de compatibilité avec d’autres systèmes d'exploitation.

soft/softerr/hard
Définir le comportement de récupération du client NFS lorsqu'une requête NFS ne répond pas
(délai dépassé). Si aucune option n'est indiquée (ou si c'est l'option hard qui est
indiquée), les requêtes NFS sont retentées indéfiniment. Si l'option soft ou l’option
softerr est indiquée, le client NFS échouera après l’envoi de retrans retransmissions,
entraînant le renvoi par le client NFS de soit EIO (pour l’option soft) ou ETIMEDOUT (pour
l’option softerr) à l'application appelante.

NB : Un délai expiré « soft » peut provoquer dans certains cas des erreurs de données non
signalées. C'est pourquoi l'option soft ou l’option softerr ne doivent être utilisées que
si la réactivité du client est plus importante que l'intégrité des données. L'utilisation
de NFS avec TCP ou l'augmentation de la valeur de l'option retrans peut diminuer les
risques liés à l'utilisation de l'option soft ou softerr.

softreval/nosoftreval
Dans le cas où le serveur NFS est hors service, il peut être utile de permettre au client
NFS de servir des chemins et des attributs à partir du cache après retrans essais pour
revalider ce que ce cache a invalidé. Cela peut être utile, par exemple, lors d’un essai
de démontage d’un arbre de système de fichiers d’un serveur hors service de manière
permanente.

Il est possible de combiner softreval avec l’option de montage soft, auquel cas les
opérations qui ne peuvent être servies à partir du cache dépasseront le délai imparti et
renverront une erreur après retrans essais. La combinaison avec l’option de montage par
défaut hard implique que ces opérations non mises en cache continueront d’essayer jusqu’à
ce qu’une réponse soit reçue du serveur.

Remarque : l’option de montage par défaut est nosoftreval qui ne permet pas un repli vers
le cache lorsque la revalidation échoue, et qui suit plutôt le comportement dicté par les
options de montage hard ou soft.

intr/nointr Cette option est fournie pour la rétrocompatibilité. Elle est ignorée après le
noyau 2.6.25.

timeo=n Le temps en dixièmes de seconde pendant lequel le client NFS attend une réponse avant de
réessayer une requête NFS.

Pour NFS sur TCP, la valeur timeo est de 600 par défaut (60 secondes). Le client NFS
effectue une progression linéaire : après chaque retransmission la temporisation est
augmentée de timeo jusqu'au maximum de 600 secondes.

Cependant, dans le cas de NFS sur UDP, le client utilise un algorithme adaptatif pour
estimer la valeur appropriée de dépassement de temps pour les types de requêtes
fréquemment utilisées (les requêtes READ et WRITE par exemple), mais utilise le réglage
timeo pour les requêtes moins courantes (comme FSINFO). Si l'option timeo n'est pas
définie, les types de requêtes moins courantes sont réémises après 1,1 seconde. Après
chaque retransmission, le client NFS double la valeur de dépassement de temps pour cette
requête, jusqu'à atteindre un maximum de 60 secondes.

Toute valeur de timeo supérieure à la valeur par défaut sera définie à la valeur par
défaut. Pour TCP et RDMA, la valeur par défaut est de 600 (60 secondes). Pour UDP, la
valeur par défaut est de 60 (6 secondes).

retrans=n Nombre de tentatives de réémission de la requête avant que le client NFS n'enclenche une
action de récupération. Si l'option retrans n'est pas définie, le client NFS essaye chaque
requête UDP trois fois et chaque requête TCP deux fois.

Le client NFS génère un message « le serveur ne répond pas » après retrans tentatives,
puis enclenche la récupération (qui dépend de l'activation de l'option hard de mount).

rsize=n Nombre maximal d'octets pour chaque requête réseau en LECTURE que peut recevoir le client
NFS lorsqu'il lit les données d'un fichier sur le serveur NFS. La taille réelle de la
charge utile de données pour chaque requête NFS en LECTURE est plus petite ou égale au
réglage rsize. La plus grande charge utile gérée par le client NFS Linux est de
1 048 576 octets (un mégaoctet).

The allowed rsize value is a positive integral multiple of system's page size or a power
of two if it is less than system's page size. Specified rsize values lower than 1024 are
replaced with 4096; values larger than 1048576 are replaced with 1048576. If a specified
value is within the supported range but not such an allowed value, it is rounded down to
the nearest allowed value.

Si la valeur de rsize n'est pas définie, ou si la valeur de rsize dépasse le maximum qu'à
la fois le client et le serveur peuvent gérer, le client et le serveur négocient la plus
grande valeur de rsize qu'ils peuvent gérer ensemble.

L'option rsize de mount telle qu'elle a été définie sur la ligne de commande lors du
mount(8) apparaît dans le fichier /etc/mtab. Cependant, la valeur réelle de rsize négociée
entre le client et le serveur est indiquée dans le fichier /proc/mounts.

wsize=n Nombre maximal d'octets par requête d'ÉCRITURE réseau que le client NFS peut envoyer quand
il écrit des données dans un fichier sur un serveur NFS. La taille réelle de la charge
utile de données pour chaque requête NFS en ÉCRITURE est plus petite ou égale au réglage
wsize. La plus grande charge utile gérée par le client NFS Linux est de 1 048 576 octets
(un mégaoctet).

Similar to rsize, the allowed wsize value is a positive integral multiple of system's page
size or a power of two if it is less than system's page size. Specified wsize values lower
than 1024 are replaced with 4096; values larger than 1048576 are replaced with 1048576. If
a specified value is within the supported range but not such an allowed value, it is
rounded down to the nearest allowed value.

Si la valeur de wsize n'est pas définie, ou si la valeur wsize indiquée est supérieure au
maximum que soit le client, soit le serveur peuvent gérer, le client et le serveur
négocient la plus grande valeur de wsize qu'ils peuvent tous les deux gérer.

L'option wsize de mount telle qu'elle a été indiquée sur la ligne de commande de mount(8)
apparaît dans le fichier /etc/mtab. Cependant, la valeur réelle de wsize négociée par le
client et le serveur est indiquée dans le fichier /proc/mounts.

ac/noac Définir si le client peut mettre en cache les attributs des fichiers. Si aucune option
n'est indiquée (ou si c'est ac qui est indiqué), le client met en cache les attributs des
fichiers.

Afin d'améliorer les performances, les clients NFS mettent en cache les attributs des
fichiers. À intervalles de quelques secondes, un client NFS vérifie la version du serveur
de chaque attribut de fichier pour rechercher des mises à jour. Les modifications qui
interviennent pendant ces petits intervalles restent inaperçues tant que le client n'a pas
consulté de nouveau le serveur. L'option noac empêche la mise en cache des attributs de
fichiers par le client, ce qui permet aux applications de détecter plus rapidement les
modifications des fichiers sur le serveur.

En plus d'empêcher le client de mettre en cache les attributs des fichiers, l'option noac
force l'écriture synchronisée pour les applications afin que les modifications sur un
fichier soient immédiatement visibles sur le serveur. De cette façon, les autres clients
peuvent rapidement détecter les nouvelles écritures lors de la vérification des attributs
du fichier.

L'usage de l'option noac offre une plus grande cohérence du cache aux clients NFS qui
accèdent aux mêmes fichiers, mais au prix d'une pénalisation significative des
performances. C'est pour cette raison qu'une utilisation judicieuse des verrouillages
(« locking ») de fichiers est préférable. La section COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES contient une présentation détaillée de ces approches.

acregmin=n Durée minimale (en seconde) de mise en cache des attributs d'un fichier normal par un
client NFS avant leur actualisation depuis le serveur. La valeur par défaut est de
3 secondes si cette option n'est pas définie. Consulter la section COHÉRENCE DES DONNÉES
ET DES MÉTADONNÉES pour des explications complètes sur la mise en cache des attributs.

acregmax=n Durée maximale (en seconde) de mise en cache des attributs d'un fichier normal par un
client NFS avant leur actualisation depuis le serveur. La valeur par défaut est de
60 secondes si cette option n'est pas définie. Consulter la section COHÉRENCE DES DONNÉES
ET DES MÉTADONNÉES pour des explications complètes sur la mise en cache des attributs.

acdirmin=n Durée minimale (en seconde) de mise en cache des attributs d'un répertoire par un client
NFS avant leur actualisation depuis le serveur. La valeur par défaut est de 30 secondes si
cette option n'est pas définie. Consulter la section COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES pour des explications complètes sur la mise en cache des attributs.

acdirmax=n Durée maximale (en seconde) de mise en cache des attributs d'un répertoire par un client
NFS avant leur actualisation depuis le serveur. La valeur par défaut est de 60 secondes si
cette option n'est pas définie. Consulter la section COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES pour des explications complètes sur la mise en cache des attributs.

actimeo=n L'utilisation de actimeo configure toutes les durées acregmin, acregmax, acdirmin et
acdirmax à la même valeur. Si cette option n'est pas définie, le client NFS utilisera les
valeurs par défaut de chacune des options décrites ci-dessus.

bg/fg Déterminer le comportement de la commande mount(8) dans le cas d'un échec d'une tentative
de montage d'une exportation. L'option fg entraîne l'arrêt de mount(8) avec un état
d'erreur si la moindre partie de la requête de montage dépasse le temps alloué ou échoue
complètement. C'est ce qui est appelé un montage en « premier plan » (pas en mode démon)
et c'est le comportement par défaut si ni fg ni bg ne sont indiqués.

Si l'option bg est indiquée, un dépassement du temps alloué ou un échec entraînera la
création d'un enfant (fork) qui continuera à essayer de monter le partage. Le parent
s'interrompt immédiatement en renvoyant un code de sortie à zéro. C'est ce qui est appelé
un montage en « arrière-plan » (en mode démon).

Si le répertoire servant de point de montage local n'existe pas, la commande mount(8) se
comporte comme si la requête était restée sans réponse (délai dépassé). Cela permet aux
montages NFS imbriqués définis dans /etc/fstab d’être exécutés dans n'importe quel ordre
lors de l'initialisation du système, même si certains serveurs NFS ne sont pas encore
disponibles. On peut aussi gérer ces problèmes grâce à un automonteur (consulter
automount(8) pour plus de détails).

nconnect=n Lors de l’utilisation d’un protocole orienté connexion tel que TCP, il peut parfois être
avantageux d’établir plusieurs connexions entre le client et le serveur. Par exemple, si
les clients ou les serveurs sont équipés de plusieurs cartes d’interface réseau (NIC),
l’utilisation de plusieurs connexions pour répartir la charge peut améliorer les
performances générales. Dans de tels cas, l’option nconnect permet à l’utilisateur de
préciser le nombre de connexions à établir entre le client et le serveur jusqu’à un
maximum de 16.

Il est à remarquer que l’option nconnect peut aussi être utilisée par quelques pilotes
pNFS pour décider combien de connexions vers les serveurs de données sont à utiliser.

rdirplus/nordirplus
Indiquer s'il faut utiliser les requêtes READDIRPLUS de NFS version 3 ou 4. Si cette
option n'est pas définie, le client NFS utilisera les requêtes READDIRPLUS sur les
montages en NFS version 3 ou 4 pour la lecture des petits répertoires. Certaines
applications sont plus efficaces si le client n'utilise que des requêtes READDIR pour tous
les répertoires.

retry=n Nombre de minutes pendant lequel le montage NFS sera retenté par la commande mount(8), en
arrière-plan ou au premier plan, avant d'abandonner. Si cette option n'est pas définie, la
valeur par défaut pour le premier plan est de 2 minutes et celle pour l'arrière-plan est
10 000 minutes, soit environ une semaine à 80 minutes près. La commande mount(8)
s'arrêtera dès le premier échec si on lui passe la valeur 0.

Il est à remarquer que cela affecte le nombre d’essais effectués, mais n’affecte pas le
délai causé par chaque nouvel essai. Pour UDP, chaque essai prend le temps déterminé par
les options timeo et retrans qui par défaut est à peu près de 7 secondes. Pour TCP il est
de 3 minutes, mais les délais d’expiration TCP du système peuvent parfois limiter le délai
d’expiration de chaque retransmission aux environs de 2 minutes.

sec=types Une liste de types de sécurité, séparés pas des deux-points, à utiliser pour accéder aux
fichiers de l’exportation montée. Si le serveur ne prend en charge aucun de ces types,
l'opération de montage échoue. Si l'option sec= n'est pas indiquée, le client essaie de
trouver un type de sécurité pris en charge à la fois par le client et le serveur. Les
types de sécurité pris en charge sont none, sys, krb5, krb5i et krb5p. Consulter la
section CONSIDÉRATIONS DE SÉCURITÉ pour les détails.

sharecache/nosharecache
Déterminer comment le client partage ses caches de données et d'attributs de fichiers
lorsqu'une même exportation est montée plus d'une fois en même temps. L'utilisation d'un
seul cache réduit les besoins en mémoire sur le client et présente aux applications un
contenu identique lorsque l'on accède au même fichier distant par différents points de
montage.

Si aucune des options n'est indiquée, ou si l'option sharecache est demandée, un seul
cache est utilisé pour tous les points de montage qui accèdent à la même exportation. Si
l'option nosharecache est indiquée, ce point de montage utilise un cache unique. Notez que
lorsque les caches des données et des attributs sont partagés, les options de montage du
premier point de montage s'appliquent pour les futurs montages simultanés de cette même
exportation.

En ce qui concerne le noyau 2.6.18, le comportement défini par nosharecache est le
comportement traditionnel normal. Cela est considéré comme dangereux pour les données
puisque de multiples copies mises en cache du même fichier sur le même client peuvent se
désynchroniser suite à une mise à jour locale d'une des copies.

resvport/noresvport
Indiquer si le client NFS doit utiliser un port source privilégié quand il communique avec
un serveur NFS pour ce point de montage. Si cette option n'est pas précisée, ou si
l'option resvport est précisée, le client NFS utilise un port source privilégié. Si
l'option noresvport est activée, le client NFS utilise un port source non privilégié.
Cette option est permise par les noyaux 2.6.28 et suivants.

Utiliser un port source non privilégié permet d'augmenter le nombre maximal de points de
montage permis par client, mais les serveurs NFS doivent être configurés pour permettre la
connexion de clients par des ports source non privilégiés.

Veuillez consulter la section CONSIDÉRATIONS DE SÉCURITÉ pour d'importantes précisions.

lookupcache=mode
Préciser comment le noyau gère son cache d’entrées de répertoire pour un point de montage
donné. mode peut être all, none, pos ou positive. Cette option est prise en charge par les
noyaux 2.6.28 et suivants.

Le client NFS Linux garde en cache tous les résultats des requêtes NFS LOOKUP. Si l’entrée
de répertoire recherchée existe sur le serveur, le résultat est considéré comme positif,
sinon il est considéré comme négatif.

Si cette option n'est pas précisée, ou si all est précisé, le client suppose que les deux
types d'entrées (positif ou négatif) du cache de répertoire sont valables jusqu'à ce que
les attributs mis en cache de leur répertoire parent expirent.

Si pos ou positive est précisé, le client suppose que les entrées positives sont valables
jusqu'à ce que les attributs mis en cache de leur répertoire parent expirent, mais
revalide toujours les entrées négatives avant qu'une application puisse les utiliser.

Si none est précisé, le client revalide les deux types d'entrées mises en cache de
répertoire avant qu'une application puisse les utiliser. Cela permet une détection rapide
des fichiers qui ont été créés ou supprimés par d'autres clients, mais peut avoir des
répercussions sur ces applications et les performances du serveur.

La partie COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES contient des explications détaillées
sur ces arbitrages.

fsc/nofsc Activer ou désactiver le cache des pages de données (en lecture seule) du disque local en
utilisant l'outil FS-Cache. Consultez cachefilesd(8) et Documentation/filesystems/caching
dans le code source du noyau pour plus de détails sur la configuration de l'outil
FS-Cache. La valeur par défaut est nofsc.

sloppy L’option sloppy est une solution de remplacement pour l’option -s de mount.nfs

xprtsec=politique
Indiquer l’utilisation d’une sécurité de la couche transport pour protéger le trafic
réseau NFS pour ce point de montage. politique peut être none, tls ou mtls.

Si none est indiqué, la sécurité de la couche transport est désactivée, même si le serveur
NFS la gère.

Si tls est indiqué, le client utilise RPC avec TLS pour la confidentialité au cours du
transport.

Si mtls est indiqué, le client utilise RPC avec TLS pour s’authentifier lui-même et pour
assurer la confidentialité au cours du transport.

Si soit tls ou mtls est indiqué et que le serveur ne prend pas en charge RPC avec TLS ou
que l’authentification de pair échoue, l’essai de montage échoue.

Si l’option xprtsec= n’est pas indiquée, le comportement par défaut dépend de la version
du noyau, mais habituellement est équivalent à xprtsec=none.

Options pour les versions NFS 2 et 3 uniquement
Utilisez ces options ainsi que les options de la sous-section précédente uniquement pour les systèmes de
fichiers de type NFS version 2 et 3.

proto=idreseau L'identifiant réseau idreseau détermine le transport utilisé pour communiquer avec le
serveur NFS. Les options possibles sont udp, udp6, tcp, tcp6, rdma et rdma6. Les valeurs
qui se terminent par 6 utilisent des adresses IPv6 et ne sont disponibles que si la prise
en charge de TI-RPC est intégrée. Les autres utilisent des adresses IPv4.

Chaque protocole de transport utilise différents réglages de retrans et de timeo (se
référer à la description de ces deux options de montage).

En plus de contrôler la façon dont le client NFS transmet les requêtes au serveur, cette
option de montage gère aussi la façon dont la commande mount(8) communique avec les
services rpcbind et mountd du serveur. Indiquer un ID réseau qui utilise TCP entraîne
l'utilisation de TCP par tout le trafic passant par la commande mount(8) ou le client NFS.
Indiquer un ID réseau qui utilise UDP entraîne l'utilisation d'UDP par tous les trafics.

Avant d'utiliser NFS sur UDP, consultez la section MÉTHODES DE TRANSPORT.

Si l'option proto de montage n'est pas définie, la commande mount(8) découvrira quels
protocoles sont acceptés par le serveur et choisira un transport approprié pour chacun des
services. Consultez la section MÉTHODES DE TRANSPORT pour plus de détails.

udp L'option udp est une solution de remplacement pour proto=udp, incluse pour la
compatibilité avec d'autres systèmes d'exploitation.

Avant d'utiliser NFS sur UDP, consultez la section MÉTHODES DE TRANSPORT.

tcp L'option tcp est une solution de remplacement pour proto=tcp, incluse pour la
compatibilité avec d'autres systèmes d'exploitation.

rdma L'option rdma est une solution de remplacement pour proto=rdma.

port=n Valeur numérique du port du service NFS sur le serveur. Si le service NFS du serveur n'est
pas accessible sur le port indiqué, la requête de montage échoue.

Si cette option n'est pas définie, ou si le port indiqué est 0, le client NFS utilise le
numéro du port du service NFS publié par le service rpcbind du serveur. La requête de
montage échoue si le service rpcbind du serveur n'est pas accessible, si le service NFS du
serveur n'est pas enregistré dans son service rpcbind, ou si le service NFS du serveur
n'est pas accessible sur le port publié.

mountport=n Valeur numérique du port de mountd sur le serveur. Si le service mountd du serveur n'est
pas présent sur le port indiqué, la requête de montage échoue.

Si cette option n'est pas définie, ou si le port indiqué est 0, la commande mount(8)
utilise le numéro du port du service mountd publié par le service rpcbind du serveur. La
requête de montage échoue si le service rpcbind du serveur n'est pas accessible, si le
service mountd du serveur n'est pas enregistré dans son service rpcbind ou si le service
mountd du serveur n'est pas accessible sur le port publié.

Cette option peut être utilisée pour les montages sur un serveur NFS à travers un pare-feu
qui bloque le protocole rpcbind.

mountproto=idreseau
Le transport utilisé par le client NFS pour transmettre ses requêtes au service mountd
d'un serveur NFS quand il lance cette requête de montage, puis quand il démontera ensuite
ce montage.

idreseau peut valoir udp ou tcp qui utilisent des adresses IPv4, ou bien, si TI-RPC est
intégré dans la commande mount.nfs, udp6 ou tcp6 qui utilisent des adresses IPv6.

Cette option peut être utilisée pour monter un serveur NFS à travers un pare-feu qui
bloque des transferts spécifiques. Lorsqu’elle est utilisée avec l'option proto,
différents modes de transfert peuvent être choisis pour les requêtes vers mountd et NFS.
Si le serveur ne propose pas de service mountd pour le transfert indiqué, la requête de
montage échoue.

Veuillez consulter la section MÉTHODES DE TRANSPORT pour plus de renseignements sur la
manière dont l'option de montage mountproto interagit avec l'option proto.

mounthost=nom Le nom d'hôte de la machine qui exécute le mountd. Si cette option n'est pas définie, la
commande mount(8) considère que le service mountd est assuré par la machine qui offre le
service NFS.

mountvers=n Numéro de version des RPC utilisé pour contacter le démon mountd du serveur. Si cette
option n'est pas définie, le client utilise un numéro de version approprié à la version de
NFS requise. Cette option est utile quand de nombreux services NFS sont offerts par un
seul et même serveur distant.

namlen=n La taille maximale d'un composant du nom de chemin de ce montage. Si cette option n'est
pas définie, la taille maximale est négociée avec le serveur. Dans la plupart des cas,
cette taille maximale est 255 caractères.

Des versions précédentes de NFS ne gèrent pas cette négociation. L'utilisation de cette
option garantit que pathconf(3) donnera bien la longueur maximale aux applications pour
ces versions.

lock/nolock Indiquer s'il faut utiliser le protocole auxiliaire NLM pour verrouiller les fichiers sur
le serveur. Si aucune option n'est indiquée (ou si c'est lock qui est choisi), le
verrouillage NLM est activé pour ce point de montage. Si on utilise l'option nolock, les
applications peuvent verrouiller les fichiers, mais ces verrous n’excluent que les autres
applications qui tournent sur ce même client. Les applications distantes ne sont pas
affectées par ces verrous.

Le verrouillage NLM doit être désactivé avec l'utilisation de l'option nolock si /var est
monté à l'aide de NFS parce que /var contient des fichiers utilisés par l'implémentation
de NLM sous Linux. L'usage de nolock est aussi requis lors des montages des exportations
de serveurs NFS ne gérant pas le protocole NLM.

cto/nocto Indiquer s'il faut utiliser la sémantique de cohérence de cache close-to-open. Si aucune
option n'est indiquée (ou si c'est cto qui est indiquée), le client utilise la sémantique
de cohérence de cache close-to-open. Si c'est l'option nocto qui est indiquée, le client
utilise une heuristique non standard pour savoir quand les fichiers ont changé sur le
serveur.

L'utilisation de l'option nocto peut améliorer les performances des montages en lecture
seule, mais devrait être limitée au cas où les données sur le serveur ne changent
qu’occasionnellement. La section COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES expose le
comportement de cette option en détails.

acl/noacl Indiquer s'il faut utiliser le protocole auxiliaire NFSACL sur ce point de montage. Le
protocole auxiliaire NFSACL est un protocole propriétaire mis en œuvre dans Solaris et qui
gère les listes de contrôle d'accès (ACL). NSFACL n'est jamais devenu un élément standard
de la spécification du protocole NFS.

Si ni acl ni noacl ne sont précisées, le client NFS négocie avec le serveur afin de savoir
si le protocole NFSACL est géré et l'utilise dans ce cas. La désactivation du protocole
auxiliaire NFSACL est parfois rendue nécessaire quand la négociation pose des problèmes
sur le client ou sur le serveur. Consultez la section CONSIDÉRATIONS DE SÉCURITÉ pour plus
de détails.

local_lock=mécanisme
Indiquer si le verrouillage local doit être utilisé pour les mécanismes de verrouillage
flock, POSIX ou pour les deux. mécanisme peut être all, flock, posix ou none. Cette option
est prise en charge par les noyaux 2.6.37 et suivants.

Le client Linux NFS fournit un moyen de poser des verrous locaux. Les applications peuvent
donc verrouiller des fichiers, mais ces verrous n’excluent que les autres applications qui
tournent sur ce même client. Les applications distantes ne sont pas affectées par ces
verrous.

Si cette option n'est pas précisée, ou si none est précisé, le client suppose que les
verrous ne sont pas locaux.

Si all est spécifié, le client suppose que les deux types de verrous flock et POSIX sont
locaux.

Si flock est spécifié, le client suppose que seuls les verrous flock sont locaux, et
utilise le protocole NLM auxiliaire pour verrouiller les fichiers quand les verrous POSIX
sont utilisés.

Si posix est spécifié, le client suppose que les verrous POSIX sont locaux, et utilise le
protocole NLM auxiliaire pour verrouiller les fichiers quand les verrous flock sont
utilisés.

Pour prendre en charge le comportement patrimonial de flock de façon semblable à celui des
clients NFS < 2.6.12, il faut utiliser « local_lock=flock ». Cette option est requise lors
de l'exportation des montages NFS à l'aide de Samba car Samba mappe les verrous du mode
partage de Windows comme flock. Puisque les clients NFS > 2.6.12 implémentent flock en
émulant les verrous POSIX, cela aboutira à un conflit de verrous.

NOTE : quand elles sont utilisées ensemble, l'option de montage « local_lock » sera
écrasée par les options de montage « nolock »/« lock ».

Options pour NFS version 4 uniquement
Ces options sont à utiliser ainsi que les options de la première sous-section ci-dessus pour les systèmes
de fichiers de type NFS version 4 et plus récents.

proto=idreseau L'identifiant réseau idreseau détermine le transport utilisé pour communiquer avec le
serveur NFS. Les options possibles sont tcp, tcp6, rdma et rdma6. L'option tcp6 utilise
des adresses IPv6 et n'est disponible que si la prise en charge de TI-RPC est intégrée.
Les autres options utilisent des adresses IPv4.

Les serveurs NFS version 4 doivent prendre en charge TCP, donc si cette option de montage
n'est pas précisée, le client NFS version 4 utilise le protocole TCP. Veuillez vous
référer à la section MÉTHODES DE TRANSPORT pour plus de détails.

minorversion=n Indiquer le numéro mineur de version du protocole. NFS 4 a introduit le « versionnage
mineur » où des améliorations du protocole NFS peuvent être introduites sans toucher son
numéro de version. Avant le noyau 2.6.38, la version mineure était toujours zéro et cette
option n’est par reconnue. Après ce noyau, indiquer « minorversion=1 » active des
fonctions avancées comme les sessions NFSv4.

Les noyaux récents permettent d’indiquer une version mineure en utilisant l’option vers=.
Par exemple, indiquer vers=4.1 a le même effet que vers=4,minorversion=1.

port=n Valeur numérique du port du service NFS sur le serveur. Si le service NFS du serveur n'est
pas accessible sur le port indiqué, la requête de montage échoue.

Si cette option de montage n'est pas définie, le client NFS utilisera le numéro de port
standard de NFS (2049) sans vérifier de prime abord le service rpcbind du serveur. Cette
option permet à un client NFS version 4 de contacter un serveur NFS version 4 à travers un
pare-feu qui bloquerait les requêtes rpcbind.

Si la valeur du port indiquée est 0, le client NFS utilisera le numéro de port du service
NFS publié par le service rpcbind du serveur. La requête de montage échouera si le service
rpcbind du serveur n'est pas disponible, si le service NFS du serveur n'est pas enregistré
dans son service rpcbind ou si le service NFS du serveur n'est pas accessible sur le port
publié.

cto/nocto Indiquer s'il faut utiliser la sémantique de cohérence du cache close-to-open pour les
répertoires NFS de ce point de montage. Si ni cto ni nocto ne sont indiquées, la
sémantique de cohérence du cache close-to-open sera utilisée par défaut pour les
répertoires.

La politique de mise en cache des données des fichiers n'est pas concernée par cette
option. La section COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES décrit le comportement de
cette option en détails.

clientaddr=n.n.n.n

clientaddr=n:n:...:n
Indiquer une seule adresse IPv4 (quadruplet séparé par des points) ou une adresse IPv6 qui
n'est pas un lien local que le client NFS signalera pour permettre aux serveurs d’envoyer
des requêtes de rappel NFS version 4.0 sur les fichiers de ce point de montage. Si le
serveur ne peut pas établir de connexion de rappel (« callback ») sur ces clients, les
performances peuvent être dégradées ou les accès à ces fichiers temporairement suspendus.
Une valeur IPv4_ANY (0.0.0.0) ou n’importe quelle adresse IPv6 équivalente peut être
indiquée qui signalera au serveur NFS que ce client NFS ne veut pas de délégations.

Si cette option n'est pas indiquée, la commande mount(8) essaie de découvrir
automatiquement une adresse de rappel (« callback ») appropriée. La procédure de
découverte automatique n'est cependant pas parfaite. Dans le cas d'interfaces réseau
multiples, de directives de routages spéciales ou de typologie réseau atypique, l'adresse
exacte à utiliser pour les rappels peut ne pas être triviale à déterminer.

Les versions 4.1 et 4.2 du protocole NFS utilisent la connexion TCP établie par le client
pour les requêtes de rappel, donc ne requièrent pas au serveur de se connecter au client.
Cette option affecte par conséquent seulement les montages NFS version 4.0.

migration/nomigration
Choisir si le client utilise une chaîne d’authentification qui est compatible avec TSM
(Transparent State Migration) pour NFSv4. Si le serveur monté prend en charge la migration
de NFSv4 avec TSM, indiquer l’option migration.

Certaines fonctions de serveur se comportent mal face à la chaîne d’authentification
compatible avec la migration. L’option nomigration conserve l’utilisation de la chaîne
d’authentification traditionnelle qui est compatible avec les serveurs NFS patrimoniaux.
C’est aussi le comportement si aucune option n’est indiquée. Un état ouvert et verrouillé
d’un client ne peut être migré de manière transparente quand il s’identifie lui-même avec
une chaîne d’identification traditionnelle.

Cette option de montage n’a aucun effet avec les versions mineures de NFSv4 plus récentes
que zéro, qui utilisent des chaînes d’identification compatibles avec TSM.

max_connect=n Alors que l’option nconnect définit une limite du nombre de connexions pouvant être
établies sur une adresse IP de serveur donnée, l’option max_connect permet à l’utilisateur
d’indiquer le nombre maximal de connexions vers des adresses IP de serveur différentes qui
appartiennent au même serveur NFSv4.1+ (connexions de session simultanées) jusqu’à une
limite de 16. Quand le client découvre que cela établit un ID de client à un serveur déjà
existant, au lieu d’abandonner le transport réseau nouvellement créé, le client ajoute
cette nouvelle connexion à la liste des transports disponibles pour ce client RPC.

trunkdiscovery/notrunkdiscovery
Quand un client découvre un nouveau système de fichiers sur un serveur NFSv4.1+, l’option
de montage trunkdiscovery fera qu’il enverra un GETATTR pour l’attribut fs_locations. S’il
reçoit une réponse de longueur non nulle, il itérera à travers la réponse et pour chaque
emplacement de serveur il établira une connexion, enverra un EXCHANGE_ID et testera le
« trunking » de session. Si le test de « trunking » réussit, la connexion sera ajoutée à
l’ensemble existant des transports pour le serveur, en respectant la limite indiquée par
l’option max_connect. La valeur par défaut est notrunkdiscovery.

SYSTÈME DE FICHIERS DE TYPE nfs4

       Le  type  nfs4  de système de fichiers est une ancienne syntaxe précisant l'utilisation de NFSv4. Il peut
       toujours être utilisé avec toutes les options communes et avec celles spécifiques à NFSv4, à  l'exception
       de l'option de montage nfsvers

FICHIER DE CONFIGURATION DU MONTAGE

       Si  la  commande  de  montage  est  configurée en ce sens, toutes les options de montage décrites dans la
       section  précédente  peuvent  être  configurées  dans  le  fichier  /etc/nfsmount.conf.  Référez-vous   à
       nfsmount.conf(5) pour plus de détails.

EXEMPLES

       Pour  réaliser un montage NFS version 3, le type de système de fichiers à utiliser est nfs et l’option de
       montage nfsvers=3 doit être indiquée. Pour réaliser un montage NFS version  4,  le  type  de  système  de
       fichiers à utiliser est soit nfs avec l’option de montage nfsvers=4 ou le type nfs4.

       L'exemple  de  fichier  /etc/fstab  suivant  permet  à la commande de montage de négocier des valeurs par
       défaut convenables pour le comportement de NFS.

               serveur:/export /mnt  nfs   defaults                      0 0

       Cet exemple montre comment réaliser un montage NFS version 4 à travers TCP, utilisant  l'authentification
       mutuelle avec Kerberos 5.

               serveur:/export /mnt  nfs4  sec=krb5                      0 0

       Cet  exemple  montre  comment  réaliser  un  montage  NFS  version 4 à travers TCP, avec le mode privé de
       Kerberos 5 ou celui d’intégrité des données.

               serveur:/export /mnt  nfs4  sec=krb5p:krb5i               0 0

       Cet exemple peut servir à réaliser le montage de /usr par NFS.

               serveur:/export /usr  nfs   ro,nolock,nocto,actimeo=3600  0 0

       Cet exemple montre comment monter un serveur NFS en utilisant une adresse brute link-local IPv6.

               [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0

MÉTHODES DE TRANSPORT

Les clients NFS envoient leurs requêtes aux serveurs NFS grâce aux appels de procédures distantes
(« Remote Procedure Calls »), les RPCs. Le client RPC découvre automatiquement les terminaisons d’accès
du service distant, gère l'authentification par requête, ajuste les paramètres des requêtes afin de gérer
l'ordre des octets sur le client et le serveur (« endianness ») et se charge de la retransmission des
requêtes qui pourraient s'être perdues dans le réseau ou sur le serveur. Les requêtes et les réponses RPC
circulent sur un transport réseau.

Dans la plupart des cas, la commande mount(8), le client NFS et le serveur NFS peuvent négocier
automatiquement les transports adaptés et la taille de données adéquate pour les transferts pour un point
de montage. Cependant, dans certains cas, il peut être bénéfique d'indiquer explicitement ces réglages
grâce aux options de montage.

Traditionnellement, les clients NFS se servaient uniquement du transport UDP pour transmettre des
requêtes aux serveurs. Bien que son implémentation soit simple, NFS sur UDP a de nombreuses limitations
qui l'empêchent d'obtenir de bonnes performances et un fonctionnement fluide dans certains environnements
de déploiement courants. Un taux de paquets perdus même insignifiant entraîne la perte de requêtes NFS
complètes. On règle alors généralement le délai de dépassement (« timeout ») à une valeur inférieure à la
seconde afin que les clients puissent récupérer rapidement en cas de requêtes rejetées. Cela peut
entraîner une surcharge du trafic réseau et du serveur.

Cependant, UDP peut être assez efficace grâce à des réglages spécifiques lorsque le MTU du réseau dépasse
la taille de transfert de données de NFS (par exemple dans les environnements réseau qui utilisent les
trames Ethernet Jumbo). Dans ces cas, il est judicieux d'adapter les réglages rsize et wsize de façon à
ce que chaque requête de lecture ou d'écriture NFS soit contenue dans quelques trames du réseau (voire
même dans une seule trame). Cela réduit la probabilité qu'une perte d'une simple trame réseau de la
taille de la MTU entraîne la perte complète d'un grande requête en lecture ou écriture.

TCP est le protocole de transport utilisé par défaut dans toutes les implémentations modernes de NFS. Il
est efficace dans pratiquement tous les environnements réseau concevables et offre d'excellentes
garanties contre la corruption de données que pourrait entraîner un incident réseau. TCP est souvent
obligatoire pour accéder à un serveur à travers un pare-feu.

Dans des conditions normales, les réseaux rejettent des paquets bien plus souvent que les serveurs NFS ne
rejettent de requêtes. C'est pourquoi un réglage agressif de délai de dépassement (« time-out ») de
retransmission pour NFS sur TCP est inutile. Les réglages habituels de délai de dépassement pour NFS sur
TCP varient entre une et dix minutes. Après qu'un client a terminé ses retransmissions (la valeur de
l'option retrans de montage), il considère que le réseau a subi un cloisonnement et tente de se
reconnecter au serveur sur un nouveau socket. Puisque TCP rend fiable le transport de données sur le
réseau, rsize et wsize peuvent en toute sécurité prendre pour valeur par défaut la plus grande valeur
gérée à la fois par le client et par le serveur, indépendamment de la taille du MTU du réseau.

Utilisation de l'option de montage mountproto
Cette section s'applique uniquement aux versions 2 et 3 de montages NFS car NFS 4 n'utilise pas un
protocole différent pour les requêtes de montage.

Le client Linux de NFS peut utiliser différents modes de transport pour contacter le service rpcbind d'un
serveur NFS, son service mountd, son gestionnaire de verrous réseau (NLM – Network Lock Manager) et son
service NFS. Le mode exact de transport utilisé par le client Linux de NFS pour chaque point de montage
dépend des réglages des options de transport de montage, qui incluent proto, mountproto udp et tcp.

Le client envoie des notifications au gestionnaire d’état réseau (NSM : Network Status Manager) à l'aide
d’UDP, quel que soit le mode de transport précisé. Il écoute cependant les notifications NSM du serveur à
la fois sur UDP et TCP. Le protocole gérant la liste de contrôles d'accès à NFACL (NFS Access Control
List) utilise le même mode de transport que le service NFS principal.

Si aucune option n'est précisée quant au mode de transport, le client Linux de NFS utilise UDP pour
contacter le service mountd du serveur et TCP pour contacter ses services NLM et NFS par défaut.

Si le serveur ne gère pas ces modes de transfert pour ces services, la commande mount(8) essaye de
trouver quel mode est pris en charge par le serveur et essaye une fois de se reconnecter avec ce mode. Si
le serveur ne propose aucun mode géré par le client ou est mal configuré, la requête de montage échoue.
Si l'option bg a été passée, la commande de montage passe en arrière-plan et continue d'essayer la
requête de montage demandée.

Quand l'une des options proto, udp ou tcp est passée mais que mountproto ne l'est pas, le mode de
transfert demandé est utilisé à la fois pour contacter le service mountd du serveur et ses services NLM
et NFS.

Si l'option mountproto est passée mais que ni proto, ni udp et ni tcp n'est passée alors le mode demandé
est utilisé pour la requête de montage initiale, mais la commande de montage essaye de découvrir quel
mode de transfert est pris en charge pour le protocole NFS, et préférera TCP si les deux modes sont
implémentés.

Si mountproto et proto (ou udp ou tcp) sont passés en même temps, le mode de transport indiqué par
l'option mountproto est utilisé pour la requête initiale de mountd et le mode indiqué par l’option proto
(ou udp ou tcp) est utilisé pour NFS quel que soit l'ordre de ces options. Aucune découverte automatique
de service n’est faite si ces options sont passées.

Si l'une des options proto, udp, tcp ou mountproto est passée plus d'une fois dans une même ligne de
commande de montage, l’instance la plus à droite de chacune de ces options prendra effet.

Utiliser NFS sur UDP sur des connexions haut débit
Utiliser NFS sur UDP avec des connexions haut débit comme Gigabit peut causer silencieusement des
corruptions de données.

Le problème peut être déclenché lors de fortes charges et est causé par des difficultés dans le
réassemblage de fragments IP. Les lectures et écritures par NFS transmettent typiquement des paquets UDP
de 4 kilooctets ou plus, qui doivent être cassés en plusieurs fragments pour être envoyés sur le lien
Ethernet pour lequel la taille des paquets est limitée à 1 500 octets par défaut. Ce processus a lieu au
niveau de la couche réseau IP et est appelé fragmentation.

Afin d'identifier les fragments qui proviennent du même paquet, IP attribue un identifiant IP (IP ID) sur
16 bits à chaque paquet. Les fragments générés à partir du même paquet UDP auront le même identifiant IP.
Le système destinataire récupère ces fragments et les combine pour reformer les paquets UDP originaux. Ce
processus est appelé réassemblage. Le délai d'expiration par défaut pour le réassemblage de paquets est
de 30 secondes. Si la pile réseau ne reçoit pas tous les fragments d'un paquet donné pendant cet
intervalle de temps, elle suppose que les fragments manquants se sont perdus et rejette ceux qui ont déjà
été reçus.

Le problème que cela crée sur des connexions à haut débit est dû au fait qu'il est possible d'envoyer
plus de 655 356 paquets en 30 secondes. En fait, avec un trafic dense NFS, les identifiants IP se
répètent au bout d'environ 5 secondes.

Cela a de sérieux effets sur le réassemblage : si un fragment se perd, un autre fragment d'un paquet
différent mais avec le même identifiant IP arrivera avant l'expiration au bout de 30 secondes et la pile
réseau combinera ces fragments pour former un nouveau paquet. La plupart du temps, les couches réseau
au-dessus d’IP détecteront ce réassemblage non assorti — dans le cas d’UDP, la somme de contrôle UDP sur
16 bits sur la charge utile complète du paquet ne correspondra pas et UDP rejettera le mauvais paquet.

Cependant, comme la somme de contrôle UDP est seulement sur 16 bits, il y a une chance sur 65 536 qu'elle
coïncide même si la charge utile du paquet est complètement aléatoire (ce qui très souvent n'est pas
vrai). Si tel est le cas, une corruption de données silencieuse sera produite.

Cette possibilité doit être prise au sérieux, au moins sur Gigabit Ethernet. Les débits réseau de
100 Mbit/s peuvent être considérés comme moins problématiques, car dans la plupart des situations, la
réinitialisation des identifiants IP prendra bien plus que 30 secondes.

Il est donc fortement recommandé d'utiliser NFS sur TCP là où c'est possible car TCP n'effectue pas de
fragmentation.

Si vous devez absolument utiliser NFS sur UDP sur un réseau Gigabit Ethernet, quelques actions peuvent
être effectuées pour limiter le problème et réduire la probabilité de corruption :

trames Jumbo De nombreuses cartes réseau Gigabit sont capables de transmettre des trames plus grandes
que la limite traditionnelle sur Ethernet de 1 500 octets (typiquement 9 000 octets).
Utiliser ces grandes trames (Jumbo) vous permettra de faire fonctionner NFS sur UDP avec
une taille de page de 8 ko sans fragmentation. Bien sûr, cela n'est possible que si toutes
les stations impliquées gèrent les trames Jumbo.

Pour activer l'envoi de trames Jumbo sur une machine avec une carte réseau qui les gère,
il suffit de configurer l'interface avec une valeur MTU de 9000.

diminution du délai avant expiration du réassemblage
Le réassemblage incorrect de fragments peut être aussi évité en diminuant ce délai sous le
temps nécessaire à la réinitialisation des identifiants IP. Pour ce faire, écrivez
simplement la nouvelle valeur du délai (en seconde) dans le fichier
/proc/sys/net/ipv4/ipfrag_time.

Une valeur de 2 secondes diminuera fortement la probabilité d'une collision d'identifiants
IP sur une seule liaison Gigabit, tout en permettant un délai d'expiration raisonnable
lors de la réception d'un trafic fragmenté depuis des serveurs distants.

COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES

Certains systèmes de fichiers modernes pour les grappes (cluster) offrent une cohérence absolue du cache
à leurs clients. La cohérence parfaite de cache pour des clients NFS hétérogènes est difficile à obtenir,
surtout sur les réseaux de grandes tailles. Dans ce cas, NFS adopte une cohérence de cache plus faible
qui satisfait les contraintes de la plupart des types de partage de fichiers.

Cohérence de cache « close-to-open »
Classiquement, le partage de fichier est complètement séquentiel. Le client A ouvre d’abord un fichier, y
écrit quelque chose et le referme. Puis le client B ouvre le même fichier et lit les modifications.

Quand une application ouvre un fichier stocké sur un serveur NFS version 3, le client NFS vérifie que le
fichier existe sur le serveur et est accessible à cette application en envoyant une requête GETATTR ou
ACCESS. Le client NFS envoie ces requêtes sans tenir compte de l’ancienneté des attributs de fichier mis
en cache.

Quand l'application ferme le fichier, le client NFS y écrit toutes les modifications en attente afin que
le prochain client ouvrant ce fichier puisse en voir les changements. Cela donne l'opportunité au client
NFS de prévenir l'application de toute erreur en écriture sur le serveur grâce au code de retour de
close(2).

Le comportement consistant à vérifier au moment de l’ouverture et à vider à la fermeture est appelé
close-to-open cache consistency (consistance de cache close-to-open) ou CTO. Il peut être désactivé en
entier pour un point de montage en utilisant l’option de montage nocto.

Faible cohérence de cache
Il y a toujours des cas dans lesquels le cache de données du client contient des données incohérentes.
Dans la version 3 du protocole NFS est apparue la « faible cohérence de cache » (appelée aussi WCC – weak
cache consistency), offrant une méthode efficace de vérification des attributs d'un fichier avant et
après une requête unique. Cela permet à un client une meilleure perception des modifications qui ont pu
être réalisées par les autres clients.

Quand un client génère de nombreuses opérations concomitantes qui modifient le même fichier au même
moment (par exemple lors d’écritures asynchrones en arrière-plan), il est difficile de savoir si le
fichier a été modifié par ce client ou par un autre.

Mise en cache des attributs
L'utilisation de l'option de montage noac permet de réaliser la cohérence de la mise en cache des
attributs pour de multiples clients. Pratiquement toutes les opérations de système de fichiers vérifient
les informations d'attributs de fichiers. Le client garde cette information en cache pendant un certain
temps afin de réduire la charge du serveur et du réseau. Quand noac est activée, le cache des attributs
de fichier est désactivé sur le client et chaque opération qui doit vérifier les attributs des fichiers
doit impérativement s'adresser au serveur. Cela permet au client de voir rapidement les modifications sur
un fichier, en contrepartie d'une augmentation importante des opérations sur le réseau.

Soyez attentif à ne pas confondre l'option noac avec « pas de mise en cache des données ». L'option de
montage noac empêche la mise en cache par le client des métadonnées du fichier, mais il existe toujours
des cas dans lesquels des incohérences de données en cache peuvent survenir entre le client et le
serveur.

Le protocole NFS n'a pas été conçu pour gérer la cohérence absolue des caches de systèmes de fichiers
dans des grappes sans qu'il soit nécessaire d'utiliser des types particuliers de sérialisation au niveau
applicatif. Si la cohérence absolue du cache est nécessaire aux clients, les applications devront
utiliser le verrouillage de fichiers. Comme solution de remplacement, les applications pourront aussi
utiliser le drapeau O_DIRECT lors de l'ouverture des fichiers afin de désactiver totalement la mise en
cache des données.

Entretien des horodatages de fichier
Les serveurs NFS sont responsables de la gestion des horodatages de fichier et de répertoire (atime,
ctime et mtime). Quand un fichier est accédé ou mis à jour sur un serveur NFS, ses horodatages sont mis à
jour comme ils le seraient sur un système de fichiers local pour une application.

Les clients NFS mettent en cache les attributs de fichier, horodatages inclus. Les horodatages de fichier
sont mis à jour quand les attributs sont récupérés à partir du serveur NFS. Par conséquent, un certain
délai peut exister avant que les mises à jour d’horodatage sur un serveur NFS apparaissent aux
applications sur les clients NFS.

Pour se conformer aux normes de système de fichiers POSIX, le client Linux NFS se fie aux serveurs NFS
pour conserver correctement à jour les horodatages mtime et ctime. Il réalise cela en vidant les
changements locaux de données sur le serveur avant de rapporter mtime aux applications à l’aide d’appels
système tels que stat(2).

Le client Linux gère les mises à jour de atime plus grossièrement. Les clients NFS entretiennent des
bonnes performances en mettant en cache les données, mais cela signifie que les lectures d’application,
qui normalement mettent à jour atime, ne sont pas reportées sur le serveur où l’atime du fichier est
réellement entretenu.

À cause de ce comportement de mise en cache, le client Linux de NFS ne prend pas en charge les options
génériques de montage relatives à atime. Consulter mount(8) pour plus de détails sur ces options.

En particulier, les options de montage atime/noatime, diratime/nodiratime, relatime/norelatime et
strictatime/nostrictatime n’ont aucun effet sur les montages NFS.

/proc/mounts peut rapporter que l’option de montage relatime est définie sur les montages NFS, mais en
fait les sémantiques de atime sont toujours comme décrit ici et ne sont pas comme les sémantiques de
relatime.

Mise en cache des entrées de répertoire
Le client Linux de NFS garde en cache le résultat de toutes les requêtes NFS LOOKUP. Si l’entrée de
répertoire demandée existe sur le serveur, le résultat de recherche est considéré comme positif. Sinon,
si l’entrée n'existe pas (c'est-à-dire si le serveur retourne ENOENT), le résultat de recherche sera
considéré comme négatif.

Afin de détecter l'ajout ou la suppression d’entrées de répertoire sur le serveur, le client Linux de NFS
regarde la date de modification (« mtime ») du répertoire. Si le client détecte un changement dans cette
date, le client supprime tous les résultats LOOKUP encore en cache concernant ce répertoire. Comme la
date de modification est un attribut conservé en cache, il est possible qu'un peu de temps se passe avant
que le client remarque le changement. Référez-vous aux descriptions des options de montage acdirmin,
acdirmax et noac pour plus d'informations quant à la manière dont la date de modification est mise en
cache.

Mettre en cache les entrées de répertoire améliore les performances des applications qui ne partagent pas
de fichiers avec des applications sur d’autres clients. Cependant, l'utilisation d'informations en cache
sur des répertoires peut interférer avec des applications qui tournent simultanément sur de nombreux
clients et qui doivent détecter rapidement la création ou la suppression de fichiers. L'option de montage
lookupcache permet de personnaliser certains comportements de mise en cache d’entrée de répertoire.

Avant la version 2.6.28 du noyau, le client Linux de NFS cherchait uniquement les résultats de recherche
positifs. Cela permettait aux applications de détecter rapidement de nouvelles entrées de répertoire
créées par d'autres clients, tout en conservant une partie des bénéfices dus à la mise en cache. Si une
application dépend de cet ancien comportement, vous pouvez utiliser l'option lookupcache=positive.

Si le client ignore son cache et valide toutes les requêtes de recherche d’application avec le serveur,
il peut alors détecter immédiatement toute création ou suppression d’entrée de répertoire par un autre
client. Vous pouvez forcer ce comportement avec l'option lookupcache=none. L'absence de mise en cache
d’entrées de répertoire exige une augmentation du nombre de requêtes NFS, et donc une perte de
performances. Empêcher la recherche sur le cache devrait permettre une moindre perte au niveau des
performances que d'utiliser noac, et n'a aucun effet sur la manière dont le client NFS met en cache les
attributs d'un fichier.

Option de montage sync
Le client NFS gère l'option de montage sync différemment d'autres systèmes de fichiers (consulter
mount(8) pour une description générique des options de montage sync et async). Si ni sync ni async ne
sont indiquées (ou si l'option async est indiquée), le client NFS retarde l'envoi au serveur des ordres
d'écriture des applications jusqu'à ce que l'un de ces événements survienne :

La saturation en mémoire entraîne une demande de ressources mémoire au système.

Une application met à jour (« flush ») les données d'un fichier de manière explicite avec sync(2),
msync(2) ou fsync(3).

Une application ferme un fichier avec close(2).

Le fichier est verrouillé/déverrouillé grâce à fcntl(2).

Autrement dit, dans les conditions normales d'utilisation, des données écrites par une application
peuvent ne pas apparaître instantanément sur le serveur qui héberge le fichier.

Si l'option sync est précisée pour un point de montage, tout appel système qui écrit des données dans des
fichiers de ce point de montage entraîne le vidage des données sur le serveur avant de revenir en espace
utilisateur. Cela offre une meilleure cohérence du cache des données entre les clients, mais a un impact
certain sur les performances.

Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin que les applications écrivent dans
des fichiers individuels pour être immédiatement pris en compte par le serveur sans avoir à utiliser
l'option de montage sync.

Utilisation des verrous de fichier avec NFS
Le Gestionnaire de Verrous Réseaux (NLM, Network Lock Manager) est un protocole auxiliaire distinct
servant à gérer les verrous sur les fichiers dans la versions 3 de NFS. Pour gérer la récupération des
verrous après le redémarrage d'un client ou du serveur, un second protocole (connu sous le nom de
protocole Network Status Manager) est nécessaire. Dans la version 4 de NFS, le verrouillage des fichiers
est directement pris en charge dans le protocole NFS et les protocoles NLM et NSM ne sont plus utilisés.

Dans la plupart des cas, les services NLM et NSM sont démarrés automatiquement et aucune configuration
additionnelle n'est requise. La configuration en noms de domaine pleinement qualifiés (FQDN) de tous les
clients NFS est nécessaire pour permettre aux serveurs NFS de retrouver leurs clients pour les informer
des redémarrages de serveur.

NLM ne gère que les verrous partagés de fichier. Pour verrouiller les fichiers NFS, il faut utiliser
fcntl(2) avec les commandes F_GETLK et F_SETLK. Le client NFS convertit les verrous de fichiers obtenus
grâce à flock(2) en verrous partagés.

Lors du montage de serveurs ne gérant pas le protocole NLM ou lorsqu'on monte un serveur NFS à travers un
pare-feu qui bloque le port du service NLM, il faut utiliser l'option nolock de montage. Le verrouillage
NLM doit être désactivé grâce à l'option nolock lorsqu'on utilise NFS pour monter /var, puisque /var
contient les fichiers utilisés par NLM dans son implémentation sous Linux.

L'utilisation de l'option nolock est parfois conseillée pour améliorer les performances d'une application
propriétaire qui ne tourne que sur un seul client, mais qui utilise intensément les verrous de fichiers.

Caractéristiques du cache de la version 4 de NFS.
Le comportement du cache des données et des métadonnées des clients NFS version 4 est identique à celui
des versions précédentes. Toutefois, la version 4 de NFS offre deux nouveaux dispositifs pour améliorer
le comportement du cache : attributs de changement et délégation de fichier.

L'attribut de changement est un nouvel élément des métadonnées de fichiers et de répertoires NFS qui
enregistre les modifications des données. Il se substitue à l'utilisation de l'horodatage des
modifications et changements du fichier pour permettre aux clients de valider le contenu de leurs caches.
Cependant, ces attributs de changement ne sont pas liés à la gestion de l'horodatage ni sur le client ni
sur le serveur.

La délégation de fichier est un contrat qui lie un client NFS version 4 et le serveur, permettant
temporairement au client de traiter un fichier comme s'il était le seul à y accéder. Le serveur s'engage
à prévenir le client (grâce à une requête de rappel, ou « callback ») si un autre client tente d'accéder
à ce même fichier. Lorsqu'un fichier a été délégué à un client, ce client peut mémoriser (mettre en
cache) les données et les métadonnées de ce fichier de façon agressive sans avoir à contacter le serveur.

Il y a deux types de délégations : lecture et écriture. Une délégation en lecture indique que le serveur
avertira le client si d'autres clients veulent écrire dans ce fichier. Une délégation en écriture indique
que le client sera prévenu des tentatives de lecture ou d'écriture.

Les serveurs accordent les délégations de fichier sitôt qu'un fichier est ouvert et peuvent annuler ces
délégations n'importe quand dès lors qu'un autre client désire accéder à un fichier d'une manière qui
entre en conflit avec les délégations déjà attribuées. Les délégations de répertoire ne sont pas gérées.

Afin de pouvoir gérer les alertes de délégations (« delegation callback »), le serveur vérifie le chemin
retour vers le client au moment du contact initial de celui-ci avec le serveur. Si le contact avec le
client ne peut pas être établi, le serveur n'attribue purement et simplement aucune délégation à ce
client.

CONSIDÉRATIONS DE SÉCURITÉ.

Les serveurs NFS contrôlent l'accès aux données des fichiers, mais leur offre de gestion de
l'authentification des requêtes NFS dépend de leur implémentation des RPC. Les contrôles d'accès NFS
traditionnels imitent les contrôles d'accès binaires standards offerts par les systèmes de fichiers
locaux. L'authentification RPC traditionnelle utilise un nombre pour représenter chaque utilisateur
(normalement l'UID propre à cet utilisateur), un nombre pour représenter le groupe de cet utilisateur (le
GID de l'utilisateur) et un ensemble d'au maximum 16 nombres de groupes additionnels pour représenter les
autres groupes auxquels cet utilisateur peut appartenir.

Traditionnellement, les données du fichier et l'ID de l'utilisateur ne sont pas chiffrés sur le réseau
(c’est-à-dire apparaissent en clair). Qui plus est, les versions 2 et 3 de NFS utilisent des protocoles
auxiliaires différents pour le montage, le verrouillage et le déverrouillage des fichiers et pour
renvoyer les valeurs de retour système des clients et serveurs. Ces protocoles auxiliaires n'utilisent
pas d'authentification.

En plus d'avoir intégré ces deux protocoles auxiliaires dans le protocole NFS principal, la version 4 de
NFS offre des formes plus avancées de contrôle d'accès, d'authentification et de protection lors du
transfert des données. La spécification de la version 4 de NFS requiert une prise en charge de
l'authentification renforcée et de types de sécurité permettant le contrôle d'intégrité et le chiffrement
par appel RPC. Puisque la version 4 de NFS ajoute les fonctionnalités de ces protocoles auxiliaires au
cœur du protocole NFS, les nouvelles caractéristiques de sécurité s'appliquent à toutes les opérations de
NFS version 4, incluant donc le montage, le verrouillage des fichiers, etc. L'authentification RPCGSS
peut aussi être utilisée avec les versions 2 et 3 de NFS, mais ne protège pas leurs protocoles
auxiliaires.

L'option de montage sec indique quel type de sécurité est utilisé sur ce point de montage NFS pour un
utilisateur. L'ajout de sec=krb5 fournit la vérification par chiffrement de l'identité de l'utilisateur
pour chaque requête RPC. Ce dispositif offre une vérification forte de l'identité des utilisateurs qui
accèdent aux données du serveur. Notez qu’une configuration supplémentaire à cet ajout d’option de
montage est nécessaire pour activer la sécurité Kerberos. Consulter la page de manuel de rpc.gssd(8) pour
plus de détails.

Deux types supplémentaires de sécurité Kerberos sont pris en charge : krb5i et krb5p. Le dispositif de
sécurité krb5i offre une garantie de chiffrement fort contre la falsification des données pour chaque
requête RPC. Le dispositif de sécurité krb5p chiffre chaque requête RPC afin d'éviter qu'elle soit
exposée pendant son transfert sur le réseau. Toutefois, le chiffrement ou la vérification de l'intégrité
entraînent des baisses de performance. D'autres formes de sécurité par chiffrement sont aussi prises en
charge.

Traversée de systèmes de fichiers NFS version 4
Le protocole de la version 4 de NFS permet à un client de renégocier le type de sécurité lorsqu'un client
passe sur un nouveau système de fichiers sur le serveur. Le type nouvellement négocié ne concerne que le
nouveau système de fichiers.

Une telle négociation se produit typiquement lorsqu'un client passe d'un pseudo-système de fichiers du
serveur à un des systèmes de fichiers physiques exportés par le serveur, qui ont souvent des paramètres
de sécurité plus restrictifs que les pseudo-systèmes de fichiers.

Baux de NFS version 4
Dans NFS version 4, un bail est une période pendant laquelle un serveur accorde irrévocablement à un
client des verrous de fichier. Une fois le bail expiré, le serveur peut révoquer ces verrous. Les clients
renouvellent périodiquement leurs baux pour éviter la révocation du verrou.

Après redémarrage d’un serveur NFS version 4, chaque client indique au serveur l’état d’ouverture et de
verrouillage du fichier existant sous son bail avant que l’opération puisse continuer. Si un client
redémarre, le serveur libère tous les états ouvert et verrouillé associés au bail du client.

Par conséquent, lors de l’établissement d’un bail, un client doit s’authentifier de lui-même auprès d’un
serveur. Chaque client présente une chaîne arbitraire pour se distinguer des autres clients.
L’administrateur de clients peut compléter la chaîne d’identité par défaut en utilisant le paramètre de
module nfs4.nfs4_unique_id pour éviter des collisions avec des chaînes d’identité d’autres clients.

Un client utilise aussi un type unique de sécurité et un commettant quand il établit son bail. Si deux
clients présentent deux chaînes d’identité identiques, un serveur peut utiliser les commettants de client
pour faire la distinction, donc empêchant de manière sécurisée qu’un client interfère avec un autre bail.

Le client établit un bail sur chaque serveur NFS version 4. Les opérations de gestion de bail, telles que
le renouvellement de bail, ne sont pas faites pour le compte d’un fichier, d’un verrou, d’un utilisateur
ou d’un point de montage particuliers, mais pour le compte du client titulaire de ce bail. Un client
utilise une chaîne d’identité, un type de sécurité et un commettant cohérents à travers les redémarrages
de client pour assurer que le serveur puisse promptement connaître l’état d’expiration des baux.

Quand Kerberos est configuré sur un client Linux NFS (c’est-à-dire qu’il existe un /etc/krb5.keytab sur
ce client), le client essaie d’utiliser le type Kerberos de sécurité pour les opérations de gestion de
bail. Kerberos fournit l’authentification sécurisée pour chaque client. Par défaut, le client utilise
host/ ou le commettant du service nfs/ dans son /etc/krb5.keytab dans ce but comme décrit dans
rpc.gssd(8).

Si le client a Kerberos configuré, mais pas le serveur, ou si le client n’a pas de fichier keytab ou les
commettants du service requis, le client utilise AUTH_SYS et l’UID 0 pour la gestion des baux.

Utiliser un port source non privilégié
Le client NFS communique normalement avec les serveurs NFS par des sockets de réseau. À chaque extrémité
d’un socket est associée une valeur de port qui est un simple nombre entre 1 et 65 535 qui permettent de
distinguer ces terminaisons d’accès de socket pour la même adresse IP. Un socket est identifié de manière
unique par un n-uplet comprenant le protocole de transport (TCP ou UDP) et les valeurs de port et
d’adresse IP de chaque terminaison d’accès.

Le client NFS peut choisir n'importe quelle valeur de port source pour ses sockets, mais il choisit en
général un port privilégié (c'est-à-dire avec une valeur inférieure à 1024). Seul un processus tournant
avec des droits du superutilisateur peut créer un socket à partir d'un port source privilégié.

La plage des ports source privilégiés pouvant être choisis est définie par une paire de « sysctl »s pour
éviter l'utilisation d’un port bien connu, tel celui de SSH. Cela signifie que le nombre de ports source
disponibles pour le client NFS, et donc le nombre de connexions de socket disponibles à un moment donné,
est en pratique limité à quelques centaines.

Comme décrit plus haut, le schéma d'authentification NFS traditionnel par défaut (connu sous le nom
d'AUTH_SYS) repose sur l'envoi d'UID et de GID locaux pour identifier les utilisateurs à l'origine de
requêtes. Un serveur NFS suppose que si une connexion provient d'un port privilégié, les numéros d’UID et
de GID des requêtes NFS sur cette connexion ont déjà été vérifiés par le noyau du client ou toute autre
autorité locale. Ce système est facile à usurper, mais sur un réseau physique sécurisé entre hôtes
vérifiés, c'est parfaitement adapté.

En gros, un socket est utilisé pour chaque point de montage NFS. Si un client peut aussi utiliser un port
source non privilégié, le nombre de sockets autorisés (et donc le nombre maximal de points de montage
simultanés) sera beaucoup plus important.

Utiliser un port source non privilégié peut quelque peu compromettre la sécurité du serveur, car
n'importe quel utilisateur d'un point de montage AUTH_SYS peut maintenant se faire passer pour un autre
comme source de la requête. C'est pourquoi les serveurs NFS ne le prennent pas en charge par défaut. En
règle générale, ils l'autorisent explicitement à l'aide d'une option d’exportation.

Pour garder un bon niveau de sécurité tout en permettant un maximum de points de montage, il est
préférable de n'autoriser les connexions clientes sur un port non privilégié que si le serveur et le
client utilisent tous deux une authentification forte, comme celle fournie par Kerberos.

Montage à travers un pare-feu
Un pare-feu peut exister entre un client NFS et le serveur, mais le client ou le serveur peuvent bloquer
certains de leurs propres ports grâce à des règles de filtrage d’IP. Il est toujours possible de monter
un serveur NFS à travers un pare-feu, bien que les mécanismes de découverte automatique des terminaisons
d'accès (endpoint) de la commande mount(8) peuvent ne pas fonctionner. Il faudra alors fournir les
détails spécifiques à ces terminaisons d'accès grâce aux options de montage.

Les serveurs NFS lancent habituellement un démon portmapper ou rpcbind pour annoncer aux clients les
terminaisons d’accès aux services. Les clients se servent du démon rpcbind pour déterminer :

le port réseau utilisé par chaque service basé sur les RPC,

les protocoles de transport pris en charge par chaque service basé sur les RPC.

Le démon rpcbind utilise un port bien connu (111) afin d'aider les clients à trouver la terminaison
d’accès à un service. Bien que NFS utilise souvent un numéro de port standard (2049), des services
auxiliaires tels que NLM peuvent choisir aléatoirement des numéros de port inutilisés.

Les configurations habituelles des pare-feu bloquent le port bien connu de rpcbind. En l'absence du
service rpcbind, l'administrateur du serveur définit un numéro de port pour les services liés à NFS afin
que le pare-feu puisse permettre l'accès aux ports des services spécifiques NFS. Les administrateurs des
clients pourront alors indiquer le numéro du port du service mountd grâce à l'option mountport de la
commande mount(8). Il peut être nécessaire d'imposer l'utilisation de TCP ou d’UDP si le pare-feu bloque
l'un de ces transports.

Désactiver le traitement des ACL (Access Control List).
Solaris permet aux clients NFS version 3 l'accès direct aux ACL (Access Control Lists) POSIX stockées
dans son système de fichiers local. Ce protocole auxiliaire propriétaire, connu sous le nom de NFSACL,
offre un contrôle d'accès plus riche que le mode par bits. Linux implémente ce protocole dans un but de
compatibilité avec l'implémentation NFS de Solaris. Cependant, le protocole NFSACL n'est jamais devenu
une partie standard de la spécification NFS version 3.

La spécification de NFS version 4 impose une nouvelle version des Access Control Lists qui sont
sémantiquement plus riches que les ACL POSIX. Les ACL de NFS version 4 ne sont pas totalement compatibles
avec les ACL POSIX. De ce fait, des traductions entre les deux sont obligatoires dans un environnement
qui mélange les ACL POSIX et NFS version 4.

OPTION DE REMONTAGE

Les options de montage générique comme rw et sync peuvent être modifiées par les points de montage NFS en
utilisant l'option remount. Consulter mount(8) pour plus d'informations sur les options génériques de
montage.

Sauf quelques exceptions, les options spécifiques à NFS ne peuvent pas être modifiées pendant un
remontage. Par exemple, le transport sous-jacent ou la version NFS ne peuvent pas être changés par un
remontage.

Effectuer un remontage sur un système de fichiers NFS monté avec l'option noac peut avoir des
conséquences inattendues. L'option noac est une combinaison de l'option générique sync et de l'option
spécifique NFS actimeo=0.

Démontage après remontage
Pour les points de montage qui utilisent NFS versions 2 ou 3, la sous-commande de démontage NFS dépend de
la connaissance de l'ensemble initial des options de montage utilisées pour effectuer l'opération MNT.
Ces options sont stockées sur le disque par la sous-commande de montage NFS, et peuvent être effacées par
un remontage.

Afin de s'assurer que les options de montage enregistrées ne sont pas effacées lors d'un remontage, il
faut spécifier au remontage soit le répertoire de montage local, soit le serveur hôte et le chemin
d'exportation, mais pas les deux. Par exemple,

mount -o remount,ro /mnt

fusionne l'option de montage ro avec les options de montage déjà enregistrées sur le disque pour le
serveur NFS monté dans /mnt.

FICHIERS

       /etc/fstab     Table des systèmes de fichiers

       /etc/nfsmount.conf
                      Fichier de configuration pour les montages NFS

NOTES

       Le client Linux NFS antérieur à 2.4.7 ne gérait pas NFS sur TCP.

       Le client Linux NFS antérieur à 2.4.20 utilisait une heuristique pour savoir si les données en cache d'un
       fichier étaient toujours valables plutôt que  d’utiliser  la  méthode  standard  de  cohérence  de  cache
       close-to-open décrite ci-dessus.

       Depuis  la  version  2.4.22, le client Linux NFS utilise une estimation RTT (Round Trip Time) de type Van
       Jacobsen pour définir les délais de dépassement de temps lorsqu'il utilise NFS sur UDP.

       Le client Linux NFS antérieur à 2.6.0 ne gérait pas NFS version 4.

       Le client Linux NFS antérieur à 2.6.8 n'utilisait les lectures et écritures synchrones  que  lorsque  les
       réglages de rsize et wsize étaient inférieurs à la taille des pages du système.

       La  prise  en  charge d’un client Linux pour les versions de protocole dépend de l’activation des options
       CONFIG_NFS_V2, CONFIG_NFS_V3, CONFIG_NFS_V4, CONFIG_NFS_V4_1 et CONFIG_NFS_V4_2 lors de  la  construction
       du noyau.

VOIR AUSSI

       fstab(5),  mount(8),  umount(8), mount.nfs(5), umount.nfs(5), exports(5), nfsmount.conf(5), netconfig(5),
       ipv6(7), nfsd(8), sm-notify(8), rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)

       RFC 768 concernant la spécification UDP.
       RFC 793 concernant la spécification TCP.
       RFC 1813 concernant la spécification de NFS version 3.
       RFC 1832 concernant la spécification XDR.
       RFC 1833 concernant la spécification RPC bind.
       RFC 2203 concernant la spécification du protocole de l'API GSS RPCSEC.
       RFC 7530 concernant la spécification de NFS version 4.0
       RFC 5661 concernant la spécification de NFS version 4.1.
       RFC 7862 concernant la spécification de NFS version 4.2.

TRADUCTION

       La   traduction   française   de   cette   page   de   manuel   a   été   créée   par    Valéry    Perrin
       <valery.perrin.debian@free.fr>,    Sylvain    Cherrier    <sylvain.cherrier@free.fr>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>,    Dominique    Simen    <dominiquesimen@hotmail.com>,    Nicolas     Sauzède
       <nsauzede@free.fr>,  Romain  Doumenc  <rd6137@gmail.com>, David Prévot <david@tilapin.org>, Denis Mugnier
       <myou72@orange.fr>,   Cédric   Boutillier   <cedric.boutillier@gmail.com>   et   Jean-Paul    Guillonneau
       <guillonneau.jeanpaul@free.fr>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General Public License
       version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel,  veuillez  envoyer  un  message  à
       debian-l10n-french@lists.debian.org.

                                                 9 octobre 2012                                           NFS(5)