Provided by: manpages-fr_4.18.1-1_all bug

NOM

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

SYNOPSIS

       /etc/fstab

DESCRIPTION

       NFS  is  an  Internet  Standard  protocol  created  by  Sun  Microsystems in 1984. NFS was
       developed to allow file  sharing  between  systems  residing  on  a  local  area  network.
       Depending  on  kernel configuration, the Linux NFS client may support NFS versions 3, 4.0,
       4.1, or 4.2.

       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      The  NFS  protocol version number used to contact the server's NFS service.
                      If the server does not support the requested  version,  the  mount  request
                      fails. If this option is not specified, the client tries version 4.2 first,
                      then negotiates down until it finds a version supported by the server.

       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.

       softreval / nosoftreval
                      In  cases  where  the NFS server is down, it may be useful to allow the NFS
                      client to continue to serve  up  paths  and  attributes  from  cache  after
                      retrans  attempts  to  revalidate  that cache have timed out. This may, for
                      instance, be helpful when trying to unmount a filesystem tree from a server
                      that is permanently down.

                      It  is  possible  to combine softreval with the soft mount option, in which
                      case operations that cannot be served up  from  cache  will  time  out  and
                      return  an  error  after retrans attempts. The combination with the default
                      hard mount option implies those uncached operations will continue to  retry
                      until a response is received from the server.

                      Note:  the  default mount option is nosoftreval which disallows fallback to
                      cache when revalidation fails, and instead follows the behavior dictated by
                      the hard or soft mount option.

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

       nconnect=n     When  using a connection oriented protocol such as TCP, it may sometimes be
                      advantageous to set up multiple connections between the client and  server.
                      For  instance,  if  your  clients and/or servers are equipped with multiple
                      network interface cards (NICs), using multiple connections  to  spread  the
                      load  may  improve  overall performance. In such cases, the nconnect option
                      allows the user to  specify  the  number  of  connections  that  should  be
                      established between the client and server up to a limit of 16.

                      Note  that  the  nconnect  option  may also be used by some pNFS drivers to
                      decide how many connections to set up to the data servers.

       max_connect=n  While nconnect option sets a limit on the number of connections that can be
                      established  to  a  given  server IP, max_connect option allows the user to
                      specify maximum number of connections to different server IPs  that  belong
                      to  the  same NFSv4.1+ server (session trunkable connections) up to a limit
                      of 16. When client discovers that it established a client ID to an  already
                      existing  server,  instead of dropping the newly created network transport,
                      the client will add this new connection to the list of available transports
                      for that RPC client.

       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    Enable/Disables the cache of (read-only) data pages to the local disk using
                      the      FS-Cache       facility.       See       cachefilesd(8)        and
                      <kernel_source>/Documentation/filesystems/caching  for  detail  on  how  to
                      configure the FS-Cache facility. Default value is nofsc.

       sloppy         The sloppy option is an alternative to specifying mount.nfs -s option.

   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 The netid determines the transport that is used to communicate with the NFS
                      server. Available options are udp, udp6, tcp, tcp6, rdma, and rdma6.  Those
                      which  end  in  6  use IPv6 addresses and are only available if support for
                      TI-RPC is built in. Others use IPv4 addresses.

                      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
       Use these options, along with the options in the first subsection above, for  NFS  version
       4.0 and newer.

       proto=idreseau The netid determines the transport that is used to communicate with the NFS
                      server. Supported options are tcp, tcp6, rdma, and  rdma6.  tcp6  use  IPv6
                      addresses  and  is  only  available if support for TI-RPC is built in. Both
                      others use IPv4 addresses.

                      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.

       minorversion=n Specifies the  protocol  minor  version  number.  NFSv4  introduces  "minor
                      versioning,"  where  NFS  protocol  enhancements  can be introduced without
                      bumping the NFS protocol version number. Before kernel  2.6.38,  the  minor
                      version  is  always  zero,  and  this  option is not recognized. After this
                      kernel, specifying "minorversion=1" enables a number of advanced  features,
                      such as NFSv4 sessions.

                      Recent  kernels  allow  the  minor  version to be specified using the vers=
                      option.  For  example,  specifying  vers=4.1  is  the  same  as  specifying
                      vers=4,minorversion=1.

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

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

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

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

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

       clientaddr=n.n.n.n

       clientaddr=n:n:...:n
                      Specifies a single IPv4 address (in dotted-quad form), or a  non-link-local
                      IPv6  address,  that  the NFS client advertises to allow servers to perform
                      NFS version 4.0 callback requests against files on this mount point. If the
                      server  is unable to establish callback connections to clients, performance
                      may degrade, or accesses to files may temporarily hang. Can specify a value
                      of  IPv4_ANY  (0.0.0.0) or equivalent IPv6 any address which will signal to
                      the NFS server that this NFS client does not want delegations.

                      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.

                      NFS protocol versions 4.1 and 4.2 use the client-established TCP connection
                      for callback requests, so do not require  the  server  to  connect  to  the
                      client. This option is therefore only affect NFS version 4.0 mounts.

       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

       mount  option.  To mount using NFS version 3, use the nfs file system type and specify the
       nfsvers=3 mount option. To mount using NFS version 4, use either the nfs file system type,
       with the nfsvers=4 mount option, or the nfs4 file system type.

       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

       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
       This  section  applies  only  to  NFS  version 3 mounts since NFS version 4 does not use a
       separate protocol for mount requests.

       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

       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 maintenance
       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
       The  Network  Lock  Manager  protocol  is a separate sideband protocol used to manage file
       locks in NFS version 3. To support lock recovery after a client or server reboot, a second
       sideband  protocol -- known as the Network Status Manager protocol -- is also required. In
       NFS version 4, file locking is supported directly in the main NFS protocol,  and  the  NLM
       and NSM sideband protocols are not used.

       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 during which a server irrevocably  grants  a  client
       file  locks.  Once  the  lease  expires,  the  server  may  revoke  those  locks.  Clients
       periodically renew their leases to prevent lock revocation.

       After an NFS version 4 server reboots, each client tells the server  about  existing  file
       open  and  lock  state under its lease before operation can continue. If a client reboots,
       the server frees all open and lock state associated with that client's lease.

       When establishing a lease, therefore, a client must identify  itself  to  a  server.  Each
       client  presents  an arbitrary string to distinguish itself from other clients. The client
       administrator can supplement the default identity  string  using  the  nfs4.nfs4_unique_id
       module parameter to avoid collisions with other client identity strings.

       A  client  also uses a unique security flavor and principal when it establishes its lease.
       If two clients present the same identity string, a server can  use  client  principals  to
       distinguish  between  them,  thus securely preventing one client from interfering with the
       other's lease.

       The Linux NFS client establishes one lease on each NFS version 4 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 client that owns that lease. A  client  uses  a
       consistent identity string, security flavor, and principal across client reboots to ensure
       that the server can promptly reap expired lease state.

       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. Kerberos provides secure authentication of each client. By default,
       the  client  uses  the  host/  or  nfs/ service principal in its /etc/krb5.keytab for this
       purpose, as described in rpc.gssd(8).

       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

NOTES

       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.

       The  Linux  client's  support for protocol versions depend on whether the kernel was built
       with   options   CONFIG_NFS_V2,   CONFIG_NFS_V3,   CONFIG_NFS_V4,   CONFIG_NFS_V4_1,   and
       CONFIG_NFS_V4_2.

VOIR AUSSI

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

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

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)