Provided by: manpages-fr-extra_20111118_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 adresse 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 puissent 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).

       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=mode       Le type de sécurité RPCGSS à utiliser pour  accéder  aux
                      fichiers  de  ce point de montage. Si l'option sec n'est
                      pas définie, ou si sec=sys est choisie,  le  client  NFS
                      utilise  le type de sécurité AUTH_SYS pour toute requête
                      NFS sur ce point de montage. Les types de sécurité gérés
                      sont  none, sys, krb5, krb5i, krb5p, lkey, lkeyi, lkeyp,
                      spkm,   spkmi   et   spkmp.   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 le même  fichier  partagé  est
                      accédé via 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  historique
                      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  montages
                      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 ngatif (« 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  ngatif)  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.

   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 Le  nom  et  la  famille  du  protocole   de   transport
                      qu'utilise  le  client NFS pour transmettre ses requêtes
                      au serveur NFS pour ce point de montage. Si  un  serveur
                      NFS  a  en  même  temps  une  adresse  IPv4 et une IPv6,
                      l'utilisation   d'un   identifiant    réseau    idreseau
                      entraînera  le  choix  d'IPv4 ou d'IPv6 pour communiquer
                      avec ce serveur.

                      Si la prise en charge de TI-RPC  est  compilée  dans  la
                      commande  mount.nfs,  netid  doit  être  un  identifiant
                      réseau valable présent dans le  fichier  /etc/netconfig.
                      On  peut  fournir  une valeur à « rdma ». Si la commande
                      mount.nfs ne gère pas TI-RPC, netid doit valoir « tcp »,
                      « udp »  ou  « rdma »,  et on utilisera alors uniquement
                      une adresse 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.

                      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.

       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  nom  et  la famille du protocole de transport que le
                      client NFS utilise  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.

                      Si  la  prise en charge pour TI-RPC est compilée dans la
                      commande mount.nfs, idreseau peut  être  un  identifiant
                      réseau  valide  parmi  ceux  listés dans /etc/netconfig.
                      Sinon, idreseau doit valoir « tcp » ou « udp », et  IPv4
                      sera utilisé.

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

       rdirplus / nordirplus
                      Indiquer  s'il faut utiliser les requêtes READDIRPLUS de
                      NFS version 3. Si cette option  n'est  pas  définie,  le
                      client  NFS  utilisera  les requêtes READDIRPLUS sur les
                      montages en NFS version 3 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.

       local_lock=mcanisme
                      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  via  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 Le  nom  et  la  famille  du  protocole   de   transport
                      qu'utilise  le  client NFS pour transmettre ses requêtes
                      au serveur NFS pour ce point de montage. Si  un  serveur
                      NFS  a  en  même  temps  une  adresse  IPv4 et une IPv6,
                      l'utilisation   d'un   identifiant    réseau    idreseau
                      entraînera  le  choix  d'IPv4 ou d'IPv6 pour communiquer
                      avec ce serveur.

                      Si la prise en charge pour TI-RPC est compilée  dans  la
                      commande  mount.nfs,  idreseau  peut être un identifiant
                      réseau valide parmi  ceux  listés  dans  /etc/netconfig.
                      Sinon,  idreseau doit valoir « tcp » ou « udp », et IPv4
                      sera utilisé.

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

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, via le  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é
       ngatif.

       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'information 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  dlgation 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 dlgation 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  les  ACLs  NFSv4,  l'authentification RPCGSS, et les diverses
       sécurités RPCGSS permettant le contrôle d'intégrité et  le  chiffrement
       via  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 que le  mode  de  sécurité  RPCGSS  est
       actif  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 (telles que lipkey ou SPKM3) sont aussi prises
       en charge.

       Le  protocole  NFS  version 4  permet  aux  clients  et aux serveurs la
       négociation de multiples dispositifs de sécurité lors du  processus  de
       montage.   Cependant,   Linux   n'implémente   pas   encore  une  telle
       négociation. Le client Linux indique un seul dispositif de sécurité  au
       moment  du  montage  qui  restera  ensuite actif pour toute la durée du
       montage. Si le serveur ne gère pas ce dispositif, la requête de montage
       initiale est refusée par le serveur.

   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 privilgi (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 montages 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  montages,  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'information 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  example,  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.

                                2 novembre 2007                         NFS(5)