Provided by: manpages-fr-extra_20151231_all bug

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.

       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.

       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      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 trois 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é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     Durée  minimale  (en  seconde)  de  mémorisation (cache) des attributs d'un fichier normal
                      avant leur actualisation depuis le serveur. La valeur par défaut  est  de  3 secondes,  si
                      cette option n'est pas définie.

       acregmax=n     Durée  maximale  (en  seconde)  de  mémorisation (cache) des attributs d'un fichier normal
                      avant leur actualisation depuis le serveur. La valeur par défaut est  de  60 secondes,  si
                      cette option n'est pas définie.

       acdirmin=n     Durée  minimale  (en  seconde) de mémorisation (cache) des attributs d'un répertoire avant
                      leur actualisation depuis le serveur. La valeur par défaut est de  30 secondes,  si  cette
                      option n'est pas définie.

       acdirmax=n     Durée  maximale  (en  seconde) de mémorisation (cache) des attributs d'un répertoire avant
                      leur actualisation depuis le serveur. La valeur par défaut est de  60 secondes,  si  cette
                      option n'est pas définie.

       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.

       sec=type       Le  type  de  sécurité  à utiliser pour accéder aux fichiers de ce point de montage. Si le
                      serveur ne prend pas en charge ce type, 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. Consultez la section CONSIDÉRATIONS DE SÉCURITÉ.

       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.

       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         Cette option est une variante pour l'option nfsvers,  compatible  avec  d'autres  systèmes
                      d'exploitation.

       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.

       intr / nointr  Indiquer si les signaux peuvent interrompre les opérations sur le fichier pour ce point de
                      montage. Si  aucune  option  n'est  indiquée  (ou  si  nointr  est  choisi),  les  signaux
                      n'interrompent  pas  les  opérations NFS sur les fichiers. Si intr est indiqué, les appels
                      systèmes renvoient EINTR si une opération NFS en cours est interrompue par un signal.

                      L'utilisation de l'option intr est préférable à celle de l'option soft car  le  risque  de
                      corruption des données est moins important.

                      Les  options  de montage intr/ nointr sont obsolètes pour des noyaux ultérieurs au 2.6.25.
                      Seul un signal de terminaison SIGKILL peut interrompre une opération NFS en cours sur  ces
                      noyaux,  et,  si  précisée,  cette  option  est  ignorée  pour  assurer  une compatibilité
                      ascendante sur des anciens noyaux.

       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é.

       intr / nointr  Indiquer  si les signaux peuvent interrompre les opérations sur les fichiers pour ce point
                      de montage. Si aucune option n'est indiquée (ou si intr est choisi), les  appels  systèmes
                      renvoient EINTR si une opération NFS en cours est interrompue par un signal. Si nointr est
                      indiqué, les signaux n'interrompent pas les opérations NFS.

                      L'utilisation de l'option intr est préférable à celle de l'option soft car  le  risque  de
                      corruption des données est moins important.

                      Les  options  de montage intr/ nointr sont obsolètes pour des noyaux ultérieurs au 2.6.25.
                      Seul un signal de terminaison SIGKILL peut interrompre une opération NFS en cours sur  ces
                      noyaux,  et,  si  précisée,  cette  option  est  ignorée  pour  assurer  une compatibilité
                      ascendante sur des anciens noyaux.

       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.

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

       Essayez cet exemple afin de réaliser un  montage  NFS  version 4  en  TCP,  utilisant  l'authentification
       réciproque de Kerberos 5.

               serveur:/export /mnt  nfs4  sec=krb5                      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   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

       Certains systèmes de fichiers en grappes (cluster) récents offrent une cohérence absolue du cache à leurs
       clients. La cohérence parfaite de cache aux clients NFS « disparates » est difficile à  obtenir,  surtout
       sur  les  réseaux  de  grandes tailles (WAN). Dans ce cas, NFS est réglé pour la plus faible cohérence de
       cache qui satisfait les contraintes de la plupart des types de partage de  fichiers.  Habituellement,  le
       partage de fichiers est totalement séquentiel : le premier client A ouvre un fichier, écrit quelque chose
       dedans, puis le ferme. Ensuite, un client B ouvre ce même fichier, puis lit les modifications.

   Cohérence de cache « close-to-open »
       Quand une application ouvre un fichier stocké sur un serveur NFS, le  client  NFS  vérifie  qu'il  existe
       toujours  sur  le  serveur  et  que  l'utilisateur  qui  ouvre ce fichier en a bien le droit, grâce à des
       requêtes GETATTR ou ACCESS. Quand l'application  ferme  le  fichier,  le  client  NFS  écrit  toutes  les
       modifications  en  attente  afin que le prochain à ouvrir 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). Ce système de vérification à l'ouverture et de purge à la fermeture
       est connu sous le nom de cohérence de cache « close-to-open » (close-to-open cache consistency).

   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.

   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.

       L'option de montage sec indique quel type de sécurité est utilisé sur ce point de montage NFS. L'ajout de
       sec=krb5 fournit la preuve chiffrée 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
       que  des configurations supplémentaires à cet ajout de l'option de mount sont nécessaires pour activer la
       sécurité Kerberos. Consultez la page de manuel de rpc.gssd(8) pour plus de détails.

       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.

       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.

   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

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), 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

       Cette page de manuel a été traduite et mise à jour par Christophe Blaess entre 1997 et 2003.  La  version
       présente  dans  Debian  est  maintenue  par Sylvain Cherrier <sylvain DOT cherrier AT free DOT fr> et les
       membres de la liste <debian-l10n-french AT lists DOT debian DOT org>. Veuillez signaler toute  erreur  de
       traduction par un rapport de bogue sur le paquet manpages-fr-extra.

                                                 9 octobre 2012                                           NFS(5)