Provided by: manpages-fr_4.13-4_all 
NOM
nfs - Format de fstab et options pour les systèmes de fichiers nfs
SYNOPSIS
/etc/fstab
DESCRIPTION
NFS est un protocole standard de l'Internet créé par Sun Microsystem en 1984. NFS a été
développé pour permettre le partage de fichiers entre des systèmes connectés à un réseau
local. Le client NFS de Linux gère trois versions du protocole : NFS version 2 [RFC1094],
NFS version 3 [RFC1813], et NFS version 4 [RFC3530].
La commande mount(8) lie un système de fichiers au point de montage donné dans l'espace de
noms hiérarchisé du système. Le fichier /etc/fstab décrit la façon dont mount(8) doit
recréer la hiérarchie de l'espace de noms du système de fichiers à partir de systèmes de
fichiers indépendants (dont ceux partagés par des serveurs NFS). Chacune des lignes du
fichier /etc/fstab décrit un unique système de fichiers, son point de montage, et un
ensemble d'options 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 partagé à 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 indique 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. Le
cinquième et le sixième champs de chaque ligne ne sont pas utilisés par NFS, et par
conséquent contiennent par convention la valeur zéro. Par exemple :
serv:chemin /pt_montage type_fs 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 du serveur peut être un nom d'hôte non qualifié, un nom de domaine pleinement
qualifié (« fully qualified domain name »), une adresse IPv4, 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. Référez-vous à ipv6(7) pour des détails quant à
l'écriture des adresses IPv6 brutes.
Le champ fstype 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 tente de
trouver une version adaptée au serveur, en tentant successivement les
versions 4, 3 puis 2.
vers=n This option is an alternative to the nfsvers option. It is included for
compatibility with other operating systems
soft / hard Définir le comportement de récupération du client NFS lorsqu'une requête
NFS ne répond pas (« time out »). Si aucune option n'est indiquée (ou si
c'est l'option hard qui a été choisie), les requêtes NFS sont retentées
indéfiniment. Si par contre l'option soft a été choisie, le client NFS
lèvera un échec après l'envoi de retrans retransmissions, entraînant alors
le retour d'une erreur à 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 doit être utilisée
uniquement 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.
intr / nointr This option is provided for backward compatibility. It is ignored after
kernel 2.6.25.
timeo=n Le temps en dixièmes de seconde où le client NFS attend une réponse avant
qu'il réessaie 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
évolutif pour estimer la valeur appropriée de dépassement de temps
(« timeout ») 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 secondes. Après chaque ré-émission, le client NFS double la valeur de
dépassement de temps pour cette requête, jusqu'à atteindre un maximum de
60 secondes.
retrans=n The number of times the NFS client retries a request before it attempts
further recovery action. If the retrans option is not specified, the NFS
client tries each UDP request three times and each TCP request twice.
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éga-octet).
La valeur de rsize est un entier positif multiple de 1024. Les valeurs de
rsize inférieures à 1024 sont remplacées par 4096, et celles supérieures à
1 048 576 sont remplacées par 1 048 576. Si la valeur indiquée est bien
dans la plage gérée, mais qu'elle n'est pas un multiple de 1024, elle sera
arrondie au multiple de 1024 inférieur le plus proche.
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. D'autre part,
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éga-octet).
Comme pour rsize, la valeur de wsize est un entier positif multiple de
1024. Les valeurs de wsize inférieures à 1024 sont remplacées par 4096, et
celles supérieures à 1 048 576 par 1 048 576. Si la valeur définie est bien
dans l'étendue valide mais qu'elle n'est pas multiple de 1024, elle est
arrondie au multiple de 1024 inférieur le plus proche.
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 peut 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 du mount(8) apparaît dans le fichier /etc/mtab. D'autre part, 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 mémoriser (cache) les attributs des fichiers. Si
aucune option n'est indiquée (ou si c'est ac qui est choisi), le client
mémorise les attributs des fichiers.
Afin d'améliorer les performances, les clients NFS mémorisent (mettent en
cache) les attributs des fichiers. Toutes les quelques secondes, un client
NFS vérifie les attributs de chaque fichier de la version du serveur afin
de se mettre à jour. Les modifications qui interviennent pendant ces petits
intervalles restent inaperçues tant que le client n'a pas relancé sa
vérification sur le serveur. L'option noac empêche la mémorisation 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 mémoriser 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 The minimum time (in seconds) that the NFS client caches attributes of a
regular file before it requests fresh attribute information from a server.
If this option is not specified, the NFS client uses a 3-second minimum.
See the DATA AND METADATA COHERENCE section for a full discussion of
attribute caching.
acregmax=n The maximum time (in seconds) that the NFS client caches attributes of a
regular file before it requests fresh attribute information from a server.
If this option is not specified, the NFS client uses a 60-second maximum.
See the DATA AND METADATA COHERENCE section for a full discussion of
attribute caching.
acdirmin=n The minimum time (in seconds) that the NFS client caches attributes of a
directory before it requests fresh attribute information from a server. If
this option is not specified, the NFS client uses a 30-second minimum. See
the DATA AND METADATA COHERENCE section for a full discussion of attribute
caching.
acdirmax=n The maximum time (in seconds) that the NFS client caches attributes of a
directory before it requests fresh attribute information from a server. If
this option is not specified, the NFS client uses a 60-second maximum. See
the DATA AND METADATA COHERENCE section for a full discussion of attribute
caching.
actimeo=n L'utilisation de actimeo configure toutes les durées acregmin, acregmax,
acdirmin et bacdirmax à la même valeur. Si cette option n'est pas définie,
le client utilisera les valeurs par défaut de chacune des options, telles
que 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'un partage. L'option fg entraîne l'arrêt de
mount(8) avec un statut d'erreur si la moindre partie de la requête de
montage dépasse le temps alloué ou échoue d'une quelconque autre manière.
C'est ce que l'on appelle le montage en « premier plan (foreground) », et
c'est le comportement par défaut si ni fg ni bg n'est indiqué.
Si l'option bg est indiquée, un dépassement du temps alloué (timeout) ou un
échec entraînera la création d'un fils (fork) qui continuera à essayer de
monter le partage. Le père s'interrompt immédiatement en renvoyant un code
de sortie à zéro. C'est ce que l'on appelle le montage en « arrière-plan
(background) ».
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
(timeout). Cela permet aux montages NFS imbriqués définis dans /etc/fstab
de s'exécuter 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 auto-monteur (consultez
automount(8) pour plus de détails).
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 Durée, en minute, pendant laquelle le montage NFS sera tenté par la
commande mount(8), en arrière-plan ou au premier plan, avant d'abandonner.
Si l'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.
Note that this only affects how many retries are made and doesn't affect
the delay caused by each retry. For UDP each retry takes the time
determined by the timeo and retrans options, which by default will be about
7 seconds. For TCP the default is 3 minutes, but system TCP connection
timeouts will sometimes limit the timeout of each retransmission to around
2 minutes.
sec=flavors A colon-separated list of one or more security flavors to use for accessing
files on the mounted export. If the server does not support any of these
flavors, the mount operation fails. If sec= is not specified, the client
attempts to find a security flavor that both the client and the server
supports. Valid flavors are none, sys, krb5, krb5i, and krb5p. Refer to the
SECURITY CONSIDERATIONS section for details.
sharecache / nosharecache
Déterminer comment le client partage ses caches de données et d'attributs
de fichiers lorsqu'un même partage est monté 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 partagé 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 au même partage. Si l'option nosharecache est indiquée, ce point
de montage utilise son propre cache. 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 de ce même partage,
tant que celui-ci est monté.
En ce qui concerne le noyau 2.6.18, le comportement défini par nosharecache
est le comportement traditionnel normal. Ceci est considéré comme dangereux
pour les données puisque de multiples copies mémorisées 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 s'occupe du cache des 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 le répertoire indiqué existe sur le serveur, le résultat renvoyé
est positif (« positive »), sinon c'est négatif (« negative »).
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 le cache de leur répertoire parent
expire.
Si pos ou positive est précisé, le client suppose que les entrées positives
sont valables jusqu'à ce que le cache de leur répertoire parent expire,
mais valide les entrées négatives avant qu'une application les utilise.
Si none est précisé, le client valide à nouveau les deux types d'entrées de
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 un propos
détaillé sur ces échanges.
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.
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 et rdma. 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 retransmission
et de timeo. Merci de vous 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 mount 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.
Réciproquement, indiquer UDP entraîne l'utilisation d'UDP par tout le
trafic.
avant d'utiliser NFS sur UDP, consultez la section MÉTHODES DE TRANSPORT.
Si l'option proto de mount 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 variante pour proto=udp, compatible 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 variante pour proto=tcp, compatible avec d'autres
systèmes d'exploitation.
rdma L'option rdma est une variante 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. Utilisé 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 pour le mode
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 mountd du serveur. Si
cette option n'est pas définie, le client utilise un numéro de version
approprié à la version du NFS contacté. Cette option est utile quand de
nombreux services NFS sont offerts par un seul et même serveur.
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'ont de portée que pour les
applications qui tournent sur ce même client. Les applications distantes ne
sont pas informées de ces verrous.
Le verrouillage NLM doit être désactivé lors de 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 de partages 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
choisi), le client utilise la sémantique de cohérence de cache
close-to-open. Si c'est l'option nocto qui est choisie, 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 (les
ACLs). 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 actif, 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
Précise si le verrouillage local doit être utilisé pour les mécanismes
flock, POSIX, ou les deux. mechanism peut être all, flock, posix, or 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'ont
de portée que pour les applications qui tournent sur ce même client. Les
applications distantes ne sont pas informées de 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 associé 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 associé pour verrouiller les fichiers quand les
verrous flock sont utilisés.
Pour supporter le comportement flock de façon semblable à celui des clients
NFS < 2.6.12, utiliser 'local_lock= flock'. Cette option est requise lors
de l'exportation des montages NFS à l'aide de Samba comme des cartes
Windows Samba partagé en mode verrouillé flock. Puisque les clients NFS >
2.6.12 utilise flock en émulant les verrous POSIX, il y aura un conflit de
verrous.
NOTE : Quand elles sont utilisées ensemble, l'option de montage
'local_lock' sera écrasée par l'option de montage 'nolock'/'lock'.
Options pour NFS version 4 uniquement
Utilisez ces options 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 et
rdma. 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 deux autres utilisent des
adresses IPv4.
Les serveurs NFS version 4 doivent prendre en charge TCP, donc si cette
option n'est pas précisée, le client NFS utilise le protocole TCP. Veuillez
vous référer à la section MÉTHODES DE TRANSPORT pour plus de détails.
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 en quatre parties séparées par des points,
ou une adresse IPv6 qui n'est pas un lien local. Le client NFS signalera
alors que les serveurs peuvent envoyer des requêtes NFSv4 de rappel 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.
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.
migration / nomigration
Selects whether the client uses an identification string that is compatible
with NFSv4 Transparent State Migration (TSM). If the mounted server
supports NFSv4 migration with TSM, specify the migration option.
Some server features misbehave in the face of a migration-compatible
identification string. The nomigration option retains the use of a
traditional client indentification string which is compatible with legacy
NFS servers. This is also the behavior if neither option is specified. A
client's open and lock state cannot be migrated transparently when it
identifies itself via a traditional identification string.
This mount option has no effect with NFSv4 minor versions newer than zero,
which always use TSM-compatible client identification strings.
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 spécifiques à NFSv4, à
l'exception de l'option de montage nfsvers
FICHIER DE CONFIGURATION DU MONTAGE
Si la commande de montage est configurée pour, 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 le montage d'un partage en NFS version 2, il faut préciser que le type du
système de fichiers est nfs et indiquer l'option de montage nfsvers=2. Pour réaliser un
montage en NFS version 3, il faut préciser que le type du système de fichiers est nfs et
indiquer l'option de montage nfsvers=3. Pour réaliser un montage en NFS version 4, il faut
préciser que le type du système de fichiers est nfs, avec l'option de montage nfsver=4, ou
demander le système de fichiers nfs4.
L'exemple de fichier /etc/fstab qui suit permet à la commande mount de négocier des
valeurs par défaut convenables pour le comportement NFS.
serveur:/export /mnt nfs defaults 0 0
Voici un exemple de ligne du fichier /etc/fstab concernant un montage NFS version 2 en
UDP.
serveur:/export /mnt nfs nfsvers=2,proto=udp 0 0
This example shows how to mount using NFS version 4 over TCP with Kerberos 5 mutual
authentication.
serveur:/export /mnt nfs4 sec=krb5 0 0
This example shows how to mount using NFS version 4 over TCP with Kerberos 5 privacy or
data integrity mode.
server:/export /mnt nfs4 sec=krb5p:krb5i 0 0
Cet exemple peut servir à réaliser le montage de /usr grâce à NFS.
serveur:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
Cet exemple montre comment utiliser une adresse brute non locale 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 entrées du service distant, gère l'authentification requête par requête, ajuste les
paramètres des requêtes afin de gérer l'ordre des octets sur le client et le serveur
(« endianess »), 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 protocole de transport réseau.
Dans la plupart des cas, la commande mount(8), le client NFS et le serveur NFS peuvent
négocier automatiquement les valeurs adéquates de taille pour les transferts de données et
de transport pour un point de montage. Cependant, dans certains cas, il peut être efficace
d'indiquer explicitement ces valeurs grâce aux options de montage.
Anciennement, 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 requis 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 mount), il
considère que le réseau a subi une panne et tente de se reconnecter au serveur grâce à une
nouvelle interface de connexion (« socket »). Puisque TCP fiabilise le transport de
données sur le réseau, rsize et wsize peuvent en toute sécurité permettre 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 du protocole mount car NFS 4
n'utilise pas un protocole de montage séparé.
Le client Linux peut utiliser différents modes de transfert pour contacter le service
rpcbind d'un serveur, son service mountd, son gestionnaire de verrou réseau (NLM) et son
service NFS. Le mode de transport utilisé par le client NFS de Linux pour chaque point de
montage dépend des options passées à mount, qui incluent proto, mountproto udp et tcp.
Le client envoie des notifications au gestionnaire réseau de statut (NSM : « network
status manager ») à l'aide d'UDP, quel que soit le mode de transfert précisé. Il écoute
cependant les notifications NSM du serveur à la fois sur UDP et TCP. Le protocole gérant
la liste de contrôle d'accès à NFS (NFACL : « nfs access control list ») utilise le même
mode de transfert que le service NFS principal.
Si aucune option n'est précisée quant au mode de transfert, le client NFS Linux utilise
UDP pour contacter le service mountd du server, 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
mount 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 mount initiale, mais la commande mount 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é à l'option mountproto est utilisé pour la requête initiale de mountd, et le mode
indiqué à proto (ou udp ou tcp) est utilisé pour NFS, quel que soit l'ordre de ces
options. Le programme ne cherchera pas à trouver les services si ces options sont données.
Si l'une des options proto, udp, tcp ou mountproto est passée plus d'une fois dans une
même commande, alors la valeur retenue sera celle la plus à droite.
Utiliser NFS sur UDP sur des connexions haut débit
Utiliser NFS sur UDP avec des connexions haut débit comme Gigabit peut causer des
corruptions de données silencieuses.
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 à 1500 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 UPD
auront le même identifiant IP. Le système destinataire récupère ces fragments et les
combine pour reformer les paquets UPD 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 655356 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'UPD, la somme de contrôle UDP sur 16 bits sur la charge utile du
paquet ne correspondra pas, et UDP rejettera le mauvais paquet.
Cependant, comme la somme de contrôle UDP est sur uniquement 16 bits, il y a une chance
sur 655356 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 se sera produite.
Cette possibilité doit être prise au sérieux, au moins sur Ethernet Gigabit. Les débits
réseau de 100 Mbit/s devraient être considérés comme moins problématiques, car dans la
plupart des situations, l'épuisement 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 : Beaucoup de cartes réseau Gigabit sont capables de transmettre des trames
plus grandes que la limite traditionnelle sur Ethernet de 1500 octets
(typiquement 9000 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 de 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 un seul lien 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
Some modern cluster file systems provide perfect cache coherence among their clients.
Perfect cache coherence among disparate NFS clients is expensive to achieve, especially on
wide area networks. As such, NFS settles for weaker cache coherence that satisfies the
requirements of most file sharing types.
Cohérence de cache « close-to-open »
Typically file sharing is completely sequential. First client A opens a file, writes
something to it, then closes it. Then client B opens the same file, and reads the changes.
When an application opens a file stored on an NFS version 3 server, the NFS client checks
that the file exists on the server and is permitted to the opener by sending a GETATTR or
ACCESS request. The NFS client sends these requests regardless of the freshness of the
file's cached attributes.
When the application closes the file, the NFS client writes back any pending changes to
the file so that the next opener can view the changes. This also gives the NFS client an
opportunity to report write errors to the application via the return code from close(2).
The behavior of checking at open time and flushing at close time is referred to as
close-to-open cache consistency, or CTO. It can be disabled for an entire mount point
using the nocto mount option.
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), 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 beaucoup d'opérations concomitantes qui modifient le même fichier
au même moment (par exemple grâce à des écritures asynchrones en arrière-plan), il est
difficile de savoir si le fichier a été modifié par ce client ou par un autre.
Mémorisation (cache) des attributs
L'utilisation de l'option noac de mount permet de réaliser la cohérence de la mémorisation
(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 mémoire (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. Ceci permet au client de voir rapidement les
modifications sur un fichier, en contrepartie d'une augmentation importante des opérations
réseaux.
Soyez attentif à ne pas confondre l'option noac avec « pas de mémorisation de données (no
data caching) ». L'option noac de mount 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 cachées 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 pour des
grappes (clusters) de systèmes de fichiers 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
(« file locking »). D'autre part, 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.
File timestamp maintainence
NFS servers are responsible for managing file and directory timestamps (atime, ctime, and
mtime). When a file is accessed or updated on an NFS server, the file's timestamps are
updated just like they would be on a filesystem local to an application.
NFS clients cache file attributes, including timestamps. A file's timestamps are updated
on NFS clients when its attributes are retrieved from the NFS server. Thus there may be
some delay before timestamp updates on an NFS server appear to applications on NFS
clients.
To comply with the POSIX filesystem standard, the Linux NFS client relies on NFS servers
to keep a file's mtime and ctime timestamps properly up to date. It does this by flushing
local data changes to the server before reporting mtime to applications via system calls
such as stat(2).
The Linux client handles atime updates more loosely, however. NFS clients maintain good
performance by caching data, but that means that application reads, which normally update
atime, are not reflected to the server where a file's atime is actually maintained.
Because of this caching behavior, the Linux NFS client does not support generic
atime-related mount options. See mount(8) for details on these options.
In particular, the atime/noatime, diratime/nodiratime, relatime/norelatime, and
strictatime/nostrictatime mount options have no effect on NFS mounts.
/proc/mounts may report that the relatime mount option is set on NFS mounts, but in fact
the atime semantics are always as described here, and are not like relatime semantics.
Mettre en cache les entrées répertoires
Le client NFS Linux garde en cache les résultats d'une requête NFS LOOKUP. Si la requête
pointe sur un répertoire existant sur le serveur, le résultat sera noté positif. Sinon, si
le répertoire n'existe pas (c'est-à-dire si le serveur retourne ENOENT), le résultat sera
noté négatif.
Afin de détecter l'ajout ou la suppression de répertoires sur le serveur, le client NFS
Linux 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 le temps de modification est mis en cache.
Mettre en cache les entrées des répertoires améliore les performances des applications qui
ne partagent pas de fichiers avec des applications sur un autre client. L'utilisation
d'informations en cache sur des répertoires, cependant, 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 de répertoires.
Avant la version 2.6.28 du noyau, le client NFS Linux cherchait uniquement les résultats
de recherches positifs. Cela permettait aux applications de détecter rapidement de
nouvelles entrées de répertoires créées par d'autres clients, tout en fournissant 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 avec le serveur,
il peut alors détecter immédiatement toute création ou suppression de répertoire par un
autre client. Vous pouvez forcer ce comportement avec l'option lookupcache=none. L'absence
de mise en cache des répertoires entraîne 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.
L'option de montage sync
Le client NFS gère l'option de montage sync différemment que d'autres systèmes de fichiers
(consultez 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 la purge des données sur le
serveur avant de revenir en espace utilisateur (« user space »). Cela offre une meilleure
cohérence du cache des données, mais a un impact certain sur les performances.
Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin que les écritures
d'un fichier précis soient immédiatement prises en compte par le serveur, et ce sans
l'utilisation de l'option sync de mount.
Utilisation des verrous de fichiers avec NFS
Le Gestionnaire de Verrous Réseaux (NLM, Network Lock Manager) est un protocole auxiliaire
séparé servant à gérer les verrous sur les fichiers dans les versions 2 et 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 implanté 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
complètement définis (FQDN) de tous les clients NFS est nécessaire pour permettre aux
serveurs NFS de retrouver leurs clients, afin de les prévenir en cas de redémarrage.
NLM ne gère que l'annonce de verrouillage de fichiers. Pour verrouiller les fichiers NFS,
il faut utiliser fcntl(2) avec les commandes F_GETL et F_SETL. Le client NFS convertit les
verrous de fichiers obtenus grâce à flock(2) en annonces de verrouillage.
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 mount. 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.
Les 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 précédentes versions. 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 offrir aux
clients la validation du contenu de leur cache. 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,
offrant temporairement au client le traitement d'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. Une fois qu'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 offrent 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épertoires 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. Si le
retour vers 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 groupes auxquels cet utilisateur peut appartenir.
Traditionnellement, les données du fichier et l'ID de l'utilisateur ne sont pas chiffrées
sur le réseau (en clair). Qui plus est, les versions 2 et 3 de NFS utilisent des
protocoles auxiliaires séparés 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 les
divers types de sécurité permettant le contrôle d'intégrité et le chiffrement à l'aide de
RPC. Puisque la version 4 de NFS ajoute les fonctionnalités de ces protocoles 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, et
ainsi de suite. L'authentification RPCGSS peut aussi être utilisée avec les versions 2 et
3 de NFS, mais ne protège pas les protocoles associés.
The sec mount option specifies the security flavor used for operations on behalf of users
on that NFS mount point. Specifying sec=krb5 provides cryptographic proof of a user's
identity in each RPC request. This provides strong verification of the identity of users
accessing data on the server. Note that additional configuration besides adding this mount
option is required in order to enable Kerberos security. Refer to the rpc.gssd(8) man page
for details.
Deux dispositifs additionnels de la 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.
NFS version 4 filesystem crossing
Le protocole de la version 4 de NFS permet à un client de renégocier le type de sécurité
lorsqu'un client entre 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.
NFS version 4 Leases
In NFS version 4, a lease is a period of time during which a server irrevocably grants a
file lock to a client. If the lease expires, the server is allowed to revoke that lock.
Clients periodically renew their leases to prevent lock revocation.
After an NFS version 4 server reboots, each client tells the server about all file open
and lock state under its lease before operation can continue. If the client reboots, the
server frees all open and lock state associated with that client's lease.
As part of establishing a lease, therefore, a client must identify itself to a server. A
fixed string is used to distinguish that client from others, and a changeable verifier is
used to indicate when the client has rebooted.
A client uses a particular security flavor and principal when performing the operations to
establish a lease. If two clients happen to present the same identity string, a server can
use their principals to detect that they are different clients, and prevent one client
from interfering with the other's lease.
The Linux NFS client establishes one lease for each server. Lease management operations,
such as lease renewal, are not done on behalf of a particular file, lock, user, or mount
point, but on behalf of the whole client that owns that lease. These operations must use
the same security flavor and principal that was used when the lease was established, even
across client reboots.
When Kerberos is configured on a Linux NFS client (i.e., there is a /etc/krb5.keytab on
that client), the client attempts to use a Kerberos security flavor for its lease
management operations. This provides strong authentication of the client to each server it
contacts. By default, the client uses the host/ or nfs/ service principal in its
/etc/krb5.keytab for this purpose.
If the client has Kerberos configured, but the server does not, or if the client does not
have a keytab or the requisite service principals, the client uses AUTH_SYS and UID 0 for
lease management.
Utiliser un port source non privilégié
Le client NFS communique normalement avec le serveur par des tuyaux réseaux (network
sockets). À chaque bout du tuyau est associé un port qui est un simple nombre entre 1 et
65535, ce qui permet de distinguer des tuyaux pointant sur la même adresse IP. Un tuyau
est identifié de manière unique par un n-uplet comprenant le protocole de passage (TCP ou
UDP) et les ports et adresses IP de chaque bout.
Le client NFS peut choisir n'importe quel port d'origine pour ses tuyaux, 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 tuyau à partir d'un
port privilégié.
La fourchette des ports potentiellement choisis est configurée par une paire de sysctls
pour éviter l'utilisation de ports bien connus, tel celui de SSH. Cela signifie que le
nombre de ports source potentiels pour le client NFS, et donc pour le nombre de connexions
par tuyau disponible à un moment donné est en pratique de l'ordre d'une centaine.
Comme décrit plus haut, le schéma d'authentification NFS traditionnel (connu sous le nom
d'AUTH_SYS) compte 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 non
privilégié, les numéros UID et GID de la requête NFS ont déjà été vérifiés par le noyau du
client ou tout autre programme système local. Ce système est facile à contourner, mais sur
un réseau sécurisé d'ordinateurs de confiance, c'est parfaitement adapté.
En gros, un tuyau est utilisé pour chaque point de montage NFS. Si un client peut aussi
utiliser un port source non privilégié, le nombre de tuyaux autorisés (et donc le nombre
maximal de points de montage en parallèles) 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 sur 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 de partage.
Pour garder un bon niveau de sécurité tout en ouvrant un maximum de points de montage, il
est préférable d'autoriser les connexions clients sur un port non privilégié seulement 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 se trouver entre un client NFS et le serveur, ou alors le client ou le
serveur peuvent bloquer certains de leurs propres ports grâce à des règles de filtrage 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 (« endpoints ») de la
commande mount(8) peuvent ne pas fonctionner. Il vous faudra alors fournir des détails
spécifiques à ces terminaisons d'accès (« endpoints ») grâce aux options de mount.
Les serveurs NFS lancent habituellement un service (daemon) portmapper ou rpcbind pour
annoncer aux clients les terminaisons (endpoints) des services. Les clients se servent du
démon rpcbind pour déterminer :
Le port réseau utilisé par chaque service basé sur les RPC
Le protocole de transport utilisé 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 (endpoint) d'un service. Bien que NFS utilise souvent un numéro de port
standard (2049), des services auxiliaires tels que NLM peuvent choisir au hasard 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 Access Control Lists (ACL)
POSIX stockés 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 binaire.
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 à la fois 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 utilisant l'option remount. Voir 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 le répertoire de montage local, ou 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
BOGUES
Le client NFS antérieur à 2.4.7 ne gérait pas NFS sur TCP.
Le client NFS antérieur à 2.4.20 utilisait une heuristique pour savoir si les données
mémorisées d'un fichier (en cache) étaient toujours valides plutôt qu'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 NFS utilise une estimation RTT de type Van Jacobsen
pour définir les délais de dépassement de temps (timeout) lorsqu'il utilise NFS sur UDP.
Le client NFS Linux antérieur à 2.6.0 ne gérait pas NFS version 4.
Le client 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.
Le client NFS Linux ne prend toujours pas en charge certaines caractéristiques
optionnelles du protocole NFS version 4, telles que la négociation de sécurité, les
soumissions de serveurs et les attributs nommés.
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 1094 concernant la spécification de NFS version 2.
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 3530 concernant la spécification de NFS version 4.
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> et Cédric Boutillier
<cedric.boutillier@gmail.com>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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)