Provided by: manpages-fr-extra_20111118_all bug

NOM

       nfs - Format de fstab et options pour les systemes de fichiers nfs

SYNOPSIS

       /etc/fstab

DESCRIPTION

       NFS est un protocole standard de l'Internet cree par Sun Microsystem en
       1984. NFS a ete developpe pour permettre le partage de  fichiers  entre
       des  systemes  connectes a un reseau local. Le client NFS de Linux gere
       trois versions du protocole : NFS version 2  [RFC1094],  NFS  version 3
       [RFC1813], et NFS version 4 [RFC3530].

       La  commande  mount(8)  lie  un systeme de fichiers au point de montage
       donne  dans  l'espace  de  noms  hierarchise  du  systeme.  Le  fichier
       /etc/fstab  decrit la facon dont mount(8) doit recreer la hierarchie de
       l'espace de noms du  systeme  de  fichiers  a  partir  de  systemes  de
       fichiers  independants  (dont  ceux  partages  par  des  serveurs NFS).
       Chacune des lignes du fichier /etc/fstab decrit un  unique  systeme  de
       fichiers,  son  point  de  montage, et un ensemble d'options par defaut
       pour ce point de montage.

       Dans le cas des montages de systemes de fichiers NFS, une ligne dans le
       fichier  /etc/fstab  indique le nom du serveur, le chemin du repertoire
       partage a monter, le repertoire local qui sera le point de montage,  le
       type de systeme de fichiers a monter et la liste des options de montage
       qui indique la facon dont le systeme de fichiers  sera  monte  et  quel
       sera  le  comportement du client NFS lorsqu'il accedera aux fichiers du
       point de montage. Le cinquieme et le sixieme champs de chaque ligne  ne
       sont pas utilises par NFS, et par consequent contiennent par convention
       la valeur zero. Par exemple :

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

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

       Le  nom  du  serveur  peut  etre  un nom d'hote non qualifie, un nom de
       domaine pleinement qualifie (<< fully qualified  domain  name >>),  une
       adresse  IPv4,  ou  une  adresse  IPv6  entouree  par des crochets. Les
       adresses  IPv6  de  liens  locaux  ou  de  sites  locaux  doivent  etre
       accompagnees  d'un identifiant d'interface. Referez-vous a ipv6(7) pour
       des details quant a l'ecriture des adresse IPv6 brutes.

       Le champ fstype contient << nfs >>.  La valeur << nfs4 >> est obsolete.

OPTIONS DE MONTAGE

       Consultez  mount(8)  pour  la  description  des  options   de   montage
       generiques  disponibles  pour  tous  les  systemes de fichiers. Si vous
       n'avez  pas  besoin  d'indiquer  d'options  de  montage  particulieres,
       utilisez l'option generique defaults dans /etc/fstab.

   Options prises en charge par toutes les versions
       Les  options  suivantes  peuvent  etre  utilisees avec n'importe quelle
       version de NFS.

       soft / hard    Definir le comportement de recuperation  du  client  NFS
                      lorsqu'une  requete  NFS ne repond pas (<< time out >>).
                      Si aucune option n'est indiquee (ou  si  c'est  l'option
                      hard qui a ete choisie), les requetes NFS sont retentees
                      indefiniment. Si par contre l'option soft a ete choisie,
                      le  client  NFS levera un echec apres l'envoi de retrans
                      retransmissions, entrainant alors le retour d'une erreur
                      a l'application appelante.

                      NB :  Un  delai  expire  << soft >>  peut provoquer dans
                      certains cas des erreurs de donnees non signalees. C'est
                      pourquoi  l'option soft doit etre utilisee uniquement si
                      la  reactivite  du  client  est  plus   importante   que
                      l'integrite  des  donnees. L'utilisation de NFS avec TCP
                      ou l'augmentation de la valeur de l'option retrans  peut
                      diminuer  les  risques  lies a l'utilisation de l'option
                      soft.

       timeo=n        Le temps en dixiemes de seconde ou le client NFS  attend
                      une reponse avant qu'il reessaie une requete NFS.

                      Pour  NFS sur TCP, la valeur timeo est de 600 par defaut
                      (60 secondes). Le client NFS  effectue  une  progression
                      lineaire :  apres chaque retransmission la temporisation
                      est augmentee de timeo jusqu'au maximum de 600 secondes.

                      Cependant, dans le cas de NFS sur UDP, le client utilise
                      un algorithme evolutif pour estimer la valeur appropriee
                      de depassement de temps (<< timeout >>) pour  les  types
                      de  requetes frequemment utilisees (les requetes READ et
                      WRITE par exemple), mais utilise le reglage  timeo  pour
                      les requetes moins courantes (comme FSINFO). Si l'option
                      timeo n'est pas definie, les  types  de  requetes  moins
                      courantes   sont  re-emises  apres  1,1 secondes.  Apres
                      chaque re-emission, le client NFS double  la  valeur  de
                      depassement   de   temps  pour  cette  requete,  jusqu'a
                      atteindre un maximum de 60 secondes.

       retrans=n      Nombre de tentatives de re-emission de la requete  avant
                      que   le   client   NFS   n'enclenche   une   action  de
                      recuperation. Si l'option retrans n'est pas definie,  le
                      client NFS essaye chaque requete trois fois.

                      Le  client NFS genere un message << le serveur ne repond
                      pas >>  apres  retrans  tentatives,  puis  enclenche  la
                      recuperation  (qui  depend  de  l'activation de l'option
                      hard de mount).

       rsize=n        Nombre maximal d'octets pour chaque  requete  reseau  en
                      LECTURE  que  peut  recevoir le client NFS lorsqu'il lit
                      les donnees d'un fichier sur le serveur NFS.  La  taille
                      reelle de la charge utile de donnees pour chaque requete
                      NFS en LECTURE est  plus  petite  ou  egale  au  reglage
                      rsize.  La  plus grande charge utile geree par le client
                      NFS Linux est de 1 048 576 octets (un mega-octet).

                      La valeur de rsize est un  entier  positif  multiple  de
                      1024.  Les  valeurs  de  rsize  inferieures  a 1024 sont
                      remplacees par 4096, et celles superieures  a  1 048 576
                      sont remplacees par 1 048 576. Si la valeur indiquee est
                      bien dans la plage geree,  mais  qu'elle  n'est  pas  un
                      multiple de 1024, elle sera arrondie au multiple de 1024
                      inferieur le plus proche.

                      Si la valeur de rsize n'est pas definie, ou si la valeur
                      de rsize depasse le maximum qu'a la fois le client et le
                      serveur peuvent gerer, le client et le serveur negocient
                      la  plus  grande  valeur  de rsize qu'ils puissent gerer
                      ensemble.

                      L'option rsize de mount telle qu'elle a ete definie  sur
                      la  ligne  de commande lors du mount(8) apparait dans le
                      fichier /etc/mtab. D'autre part,  la  valeur  reelle  de
                      rsize  negociee  entre  le  client  et  le  serveur  est
                      indiquee dans le fichier /proc/mounts.

       wsize=n        Nombre maximal d'octets par  requete  d'ECRITURE  reseau
                      que  le  client  NFS  peut  envoyer  quand  il ecrit des
                      donnees dans un fichier sur un serveur  NFS.  La  taille
                      reelle de la charge utile de donnees pour chaque requete
                      NFS en ECRITURE est plus  petite  ou  egale  au  reglage
                      wsize.  La  plus grande charge utile geree par le client
                      NFS Linux est de 1 048 576 octets (un mega-octet).

                      Comme pour rsize, la  valeur  de  wsize  est  un  entier
                      positif   multiple   de   1024.  Les  valeurs  de  wsize
                      inferieures a 1024 sont remplacees par 4096,  et  celles
                      superieures  a  1 048 576  par  1 048 576.  Si la valeur
                      definie est bien  dans  l'etendue  valide  mais  qu'elle
                      n'est  pas  multiple  de  1024,  elle  est  arrondie  au
                      multiple de 1024 inferieur le plus proche.

                      Si la valeur de wsize n'est pas definie, ou si la valeur
                      wsize  indiquee  est  superieure  au maximum que soit le
                      client soit le serveur  peut  gerer,  le  client  et  le
                      serveur  negocient la plus grande valeur de wsize qu'ils
                      peuvent tous les deux gerer.

                      L'option wsize de mount telle qu'elle a ete indiquee sur
                      la  ligne  de  commande  du  mount(8)  apparait  dans le
                      fichier /etc/mtab. D'autre part,  la  valeur  reelle  de
                      wsize  negociee par le client et le serveur est indiquee
                      dans le fichier /proc/mounts.

       ac / noac      Definir  si  le  client  peut  memoriser   (cache)   les
                      attributs  des fichiers. Si aucune option n'est indiquee
                      (ou si c'est ac qui est choisi), le client memorise  les
                      attributs des fichiers.

                      Afin  d'ameliorer  les  performances,  les  clients  NFS
                      memorisent  (mettent  en  cache)   les   attributs   des
                      fichiers.  Toutes  les  quelques secondes, un client NFS
                      verifie les attributs de chaque fichier de la version du
                      serveur  afin de se mettre a jour. Les modifications qui
                      interviennent pendant  ces  petits  intervalles  restent
                      inapercues  tant  que  le  client  n'a  pas  relance  sa
                      verification sur le serveur. L'option  noac  empeche  la
                      memorisation des attributs de fichiers par le client, ce
                      qui permet aux applications de detecter plus  rapidement
                      les modifications des fichiers sur le serveur.

                      En  plus d'empecher le client de memoriser les attributs
                      des   fichiers,   l'option   noac    force    l'ecriture
                      synchronisee   pour   les   applications  afin  que  les
                      modifications  sur  un  fichier   soient   immediatement
                      visibles  sur  le  serveur.  De  cette facon, les autres
                      clients  peuvent  rapidement  detecter   les   nouvelles
                      ecritures  lors  de  la  verification  des  attributs du
                      fichier.

                      L'usage de l'option noac offre une plus grande coherence
                      du   cache  aux  clients  NFS  qui  accedent  aux  memes
                      fichiers, mais au prix d'une penalisation  significative
                      des   performances.   C'est  pour  cette  raison  qu'une
                      utilisation judicieuse des verrouillages (<< locking >>)
                      de  fichiers  est  preferable.  La section COH'ERENCE DES
                      DONN'EES ET DES  M'ETADONN'EES  contient  une  presentation
                      detaillee de ces approches.

       acregmin=n     Duree  minimale (en seconde) de memorisation (cache) des
                      attributs d'un fichier normal avant  leur  actualisation
                      depuis   le   serveur.  La  valeur  par  defaut  est  de
                      3 secondes, si cette option n'est pas definie.

       acregmax=n     Duree maximale (en seconde) de memorisation (cache)  des
                      attributs  d'un  fichier normal avant leur actualisation
                      depuis  le  serveur.  La  valeur  par  defaut   est   de
                      60 secondes, si cette option n'est pas definie.

       acdirmin=n     Duree  minimale (en seconde) de memorisation (cache) des
                      attributs  d'un  repertoire  avant  leur   actualisation
                      depuis   le   serveur.  La  valeur  par  defaut  est  de
                      30 secondes, si cette option n'est pas definie.

       acdirmax=n     Duree maximale (en seconde) de memorisation (cache)  des
                      attributs   d'un  repertoire  avant  leur  actualisation
                      depuis  le  serveur.  La  valeur  par  defaut   est   de
                      60 secondes, si cette option n'est pas definie.

       actimeo=n      L'utilisation  de  actimeo  configure  toutes les durees
                      acregmin, acregmax, acdirmin  et  bacdirmax  a  la  meme
                      valeur.  Si  cette  option  n'est pas definie, le client
                      utilisera les valeurs par defaut de chacune des options,
                      telles que decrites ci-dessus.

       bg / fg        Determiner  le comportement de la commande mount(8) dans
                      le cas  d'un  echec  d'une  tentative  de  montage  d'un
                      partage.  L'option  fg entraine l'arret de mount(8) avec
                      un statut d'erreur si la moindre partie de la requete de
                      montage   depasse   le  temps  alloue  ou  echoue  d'une
                      quelconque autre maniere. C'est ce que l'on  appelle  le
                      montage  en << premier plan (foreground) >>, et c'est le
                      comportement par defaut si ni fg ni bg n'est indique.

                      Si l'option bg est indiquee,  un  depassement  du  temps
                      alloue (timeout) ou un echec entrainera la creation d'un
                      fils (fork)  qui  continuera  a  essayer  de  monter  le
                      partage. Le pere s'interrompt immediatement en renvoyant
                      un code de sortie a zero. C'est ce que l'on  appelle  le
                      montage en << arriere-plan (background) >>.

                      Si  le  repertoire  servant  de  point  de montage local
                      n'existe pas, la commande mount(8) se comporte comme  si
                      la  requete  etait  restee  sans reponse (timeout). Cela
                      permet  aux  montages   NFS   imbriques   definis   dans
                      /etc/fstab  de s'executer dans n'importe quel ordre lors
                      de  l'initialisation  du  systeme,  meme   si   certains
                      serveurs  NFS  ne  sont  pas encore disponibles. On peut
                      aussi  gerer  ces  problemes  grace  a  un  auto-monteur
                      (consultez automount(8) pour plus de details).

       retry=n        Duree,  en  minute, pendant laquelle le montage NFS sera
                      tente par la commande mount(8), en  arriere-plan  ou  au
                      premier  plan, avant d'abandonner. Si l'option n'est pas
                      definie, la valeur par defaut pour le premier  plan  est
                      de   2 minutes,   et   celle   pour  l'arriere-plan  est
                      10 000 minutes, soit environ une semaine,  a  80 minutes
                      pres.  La  commande  mount(8)  s'arretera des le premier
                      echec si on lui passe la valeur 0.

       sec=mode       Le type de securite RPCGSS a utiliser pour  acceder  aux
                      fichiers  de  ce point de montage. Si l'option sec n'est
                      pas definie, ou si sec=sys est choisie,  le  client  NFS
                      utilise  le type de securite AUTH_SYS pour toute requete
                      NFS sur ce point de montage. Les types de securite geres
                      sont  none, sys, krb5, krb5i, krb5p, lkey, lkeyi, lkeyp,
                      spkm,   spkmi   et   spkmp.   Consultez    la    section
                      CONSID'ERATIONS DE S'ECURIT'E.

       sharecache / nosharecache
                      Determiner  comment  le  client  partage  ses  caches de
                      donnees  et  d'attributs  de  fichiers  lorsqu'un   meme
                      partage  est  monte  plus  d'une  fois  en  meme  temps.
                      L'utilisation d'un seul  cache  reduit  les  besoins  en
                      memoire  sur  le  client et presente aux applications un
                      contenu identique lorsque le meme  fichier  partage  est
                      accede via differents points de montage.

                      Si  aucune  des  options  n'est indiquee, ou si l'option
                      sharecache est demandee, un seul cache est utilise  pour
                      tous les points de montage qui accedent au meme partage.
                      Si l'option  nosharecache  est  indiquee,  ce  point  de
                      montage  utilise son propre cache. Notez que lorsque les
                      caches des donnees et des attributs sont  partages,  les
                      options   de   montage   du  premier  point  de  montage
                      s'appliquent  pour  les  futurs  montages  de  ce   meme
                      partage, tant que celui-ci est monte.

                      En  ce  qui  concerne  le  noyau 2.6.18, le comportement
                      defini par nosharecache est le  comportement  historique
                      normal.  Ceci  est  considere  comme  dangereux pour les
                      donnees puisque de multiples copies memorisees  du  meme
                      fichier  sur  le  meme  client peuvent se desynchroniser
                      suite a une mise a jour locale d'une des copies.

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

                      Utiliser   un   port   source   non   privilegie  permet
                      d'augmenter le nombre  maximal  de  points  de  montages
                      permis  par  client,  mais les serveurs NFS doivent etre
                      configures pour permettre la connexion  de  clients  par
                      des ports source non privilegies.

                      Veuillez consulter la section CONSID'ERATIONS DE S'ECURIT'E
                      pour d'importantes precisions.

       lookupcache=mode
                      Preciser comment le noyau s'occupe du cache des  entrees
                      de  repertoire pour un point de montage donne. mode peut
                      etre 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 resultats
                      des requetes NFS LOOKUP. Si le repertoire indique existe
                      sur   le   serveur,  le  resultat  renvoye  est  positif
                      (<< positive >>), sinon c'est n'egatif (<< negative >>).

                      Si cette option  n'est  pas  precisee,  ou  si  all  est
                      precise,  le client suppose que les deux types d'entrees
                      (positif  ou  n'egatif)  du  cache  de  repertoire   sont
                      valables  jusqu'a  ce  que  le  cache de leur repertoire
                      parent expire.

                      Si pos ou positive est precise, le  client  suppose  que
                      les  entrees  positives  sont valables jusqu'a ce que le
                      cache de leur repertoire parent expire, mais valide  les
                      entrees negatives avant qu'une application les utilise.

                      Si none est precise, le client valide a nouveau les deux
                      types d'entrees de  cache  de  repertoire  avant  qu'une
                      application   puisse   les  utiliser.  Cela  permet  une
                      detection rapide des  fichiers  qui  ont  ete  crees  ou
                      supprimes  par  d'autres  clients,  mais  peut avoir des
                      repercussions sur ces applications et  les  performances
                      du serveur.

                      La  partie  COH'ERENCE  DES  DONN'EES  ET  DES M'ETADONN'EES
                      contient un propos detaille sur ces echanges.

   Options pour les versions NFS 2 et 3 uniquement
       Utilisez  ces  options  ainsi  que  les  options  de  la   sous-section
       precedente  uniquement  pour  les  systemes  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 requetes
                      au serveur NFS pour ce point de montage. Si  un  serveur
                      NFS  a  en  meme  temps  une  adresse  IPv4 et une IPv6,
                      l'utilisation   d'un   identifiant    reseau    idreseau
                      entrainera  le  choix  d'IPv4 ou d'IPv6 pour communiquer
                      avec ce serveur.

                      Si la prise en charge de TI-RPC  est  compilee  dans  la
                      commande  mount.nfs,  netid  doit  etre  un  identifiant
                      reseau valable present dans le  fichier  /etc/netconfig.
                      On  peut fournir une valeur a << rdma >>. Si la commande
                      mount.nfs  ne  gere  pas  TI-RPC,  netid   doit   valoir
                      << tcp >>,  << udp >>  ou  << rdma >>,  et  on utilisera
                      alors uniquement une adresse IPv4.

                      Chaque  protocole  de   transport   utilise   differents
                      reglages  de  retransmission  et de timeo. Merci de vous
                      referer a la description de ces deux options de montage

                      En plus  de  controler  la  facon  dont  le  client  NFS
                      transmet  les requetes au serveur, cette option de mount
                      gere aussi la facon dont la commande mount(8) communique
                      avec les services rpcbind et mountd du serveur. Indiquer
                      un id reseau qui utilise TCP entraine  l'utilisation  de
                      TCP  par tout le trafic passant par la commande mount(8)
                      ou le client NFS. Reciproquement, indiquer UDP  entraine
                      l'utilisation d'UDP par tout le trafic.

                      Si  l'option  proto  de  mount  n'est  pas  definie,  la
                      commande  mount(8)  decouvrira  quels  protocoles   sont
                      acceptes   par  le  serveur  et  choisira  un  transport
                      approprie pour chacun des services. Consultez la section
                      M'ETHODES DE TRANSPORT pour plus de details.

       udp            L'option udp est une variante pour proto=udp, compatible
                      avec d'autres systemes d'exploitation.

       tcp            L'option tcp est une variante pour proto=tcp, compatible
                      avec d'autres systemes d'exploitation.

       rdma           L'option rdma est une variante pour proto=rdma.

       port=n         Valeur  numerique du port du service NFS sur le serveur.
                      Si le service NFS du serveur n'est pas accessible sur le
                      port indique, la requete de montage echoue.

                      Si cette option n'est pas definie, ou si le port indique
                      est 0, le client  NFS  utilise  le  numero  du  port  du
                      service NFS publie par le service rpcbind du serveur. La
                      requete de montage  echoue  si  le  service  rpcbind  du
                      serveur  n'est  pas  accessible,  si  le  service NFS du
                      serveur n'est pas enregistre dans son  service  rpcbind,
                      ou si le service NFS du serveur n'est pas accessible sur
                      le port publie.

       mountport=n    Valeur numerique du port de mountd sur le serveur. Si le
                      service  mountd du serveur n'est pas present sur le port
                      indique, la requete de montage echoue.

                      Si cette option n'est pas definie, ou si le port indique
                      est 0, la commande mount(8) utilise le numero du port du
                      service mountd publie par le service rpcbind du serveur.
                      La  requete  de  montage echoue si le service rpcbind du
                      serveur n'est pas accessible, si le  service  mountd  du
                      serveur  n'est  pas enregistre dans son service rpcbind,
                      ou si le service mountd du serveur n'est pas  accessible
                      sur le port publie.

                      Cette option peut etre utilisee pour les montages sur un
                      serveur  NFS  a  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  requetes  au
                      service  mountd  d'un  serveur  NFS quand il lance cette
                      requete de montage, puis quand il demontera  ensuite  ce
                      montage.

                      Si  la  prise en charge pour TI-RPC est compilee dans la
                      commande mount.nfs, idreseau peut  etre  un  identifiant
                      reseau  valide  parmi  ceux  listes dans /etc/netconfig.
                      Sinon, idreseau doit valoir << tcp >> ou  << udp >>,  et
                      IPv4 sera utilise.

                      Cette  option  peut etre utilisee pour monter un serveur
                      NFS a travers un  pare-feu  qui  bloque  des  transferts
                      specifiques.  Utilise  avec  l'option  proto, differents
                      modes  de  transfert  peuvent  etre  choisis  pour   les
                      requetes  vers  mountd  et NFS. Si le serveur ne propose
                      pas de service pour  le  mode  indique,  la  requete  de
                      montage echoue.

                      Veuillez consulter la section M'ETHODES DE TRANSPORT pour
                      plus de renseignements sur la maniere dont  l'option  de
                      montage mountproto interagit avec l'option proto.

       mounthost=nom  Le  nom  d'hote  de la machine qui execute le mountd. Si
                      cette option n'est pas  definie,  la  commande  mount(8)
                      considere  que  le  service  mountd  est  assure  par la
                      machine qui offre le service NFS.

       mountvers=n    Numero de version des  RPC  utilise  pour  contacter  le
                      mountd du serveur. Si cette option n'est pas definie, le
                      client utilise un  numero  de  version  approprie  a  la
                      version du NFS contacte. Cette option est utile quand de
                      nombreux services NFS sont offerts par un seul  et  meme
                      serveur.

       namlen=n       La  taille  maximale  d'un composant du nom de chemin ce
                      montage. Si cette option n'est pas  definie,  la  taille
                      maximale  est  negociee avec le serveur. Dans la plupart
                      des cas, cette taille maximale est 255 caracteres.

                      Des versions precedentes de  NFS  ne  gerent  pas  cette
                      negociation.  L'utilisation de cette option garantit que
                      pathconf(3)  donnera  bien  la  longueur  maximale   aux
                      applications pour ces versions.

       nfsvers=n      Le  numero  de  version  du  protocole  NFS utilise pour
                      contacter le service NFS du serveur.  Si le  serveur  ne
                      gere  pas  la  version  demandee,  la requete de montage
                      echoue. Si cette option n'est  pas  definie,  le  client
                      tente  de  trouver  une  version  adaptee 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 systemes 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 indiquee (ou si c'est lock qui est choisi),
                      le verrouillage NLM est active pour ce point de montage.
                      Si  on utilise l'option nolock, les applications peuvent
                      verrouiller les fichiers,  mais  ces  verrous  n'ont  de
                      portee  que  pour  les  applications qui tournent sur ce
                      meme client. Les  applications  distantes  ne  sont  pas
                      informees de ces verrous.

                      Le   verrouillage   NLM  doit  etre  desactive  lors  de
                      l'utilisation de l'option nolock si /var est  monte  via
                      NFS,  parce  que /var contient des fichiers utilises par
                      l'implementation de NLM sous Linux.  L'usage  de  nolock
                      est  aussi  requis  lors  des  montages  de  partages de
                      serveurs NFS ne gerant pas le protocole NLM.

       intr / nointr  Indiquer  si  les  signaux   peuvent   interrompre   les
                      operations  sur  le fichier pour ce point de montage. Si
                      aucune option n'est indiquee (ou si nointr est  choisi),
                      les  signaux  n'interrompent  pas les operations NFS sur
                      les fichiers. Si intr est indique, les  appels  systemes
                      renvoient  EINTR  si  une  operation  NFS  en  cours est
                      interrompue par un signal.

                      L'utilisation de l'option intr est preferable a celle de
                      l'option  soft  car  le risque de corruption des donnees
                      est moins important.

                      Les options de montage intr/ nointr sont obsoletes  pour
                      des  noyaux  ulterieurs  au  2.6.25.  Seul  un signal de
                      terminaison SIGKILL peut interrompre une  operation  NFS
                      en  cours  sur ces noyaux, et, si precisee, cette option
                      est ignoree pour assurer  une  compatibilite  ascendante
                      sur des anciens noyaux.

       cto / nocto    Indiquer  s'il  faut utiliser la semantique de coherence
                      de cache close-to-open. Si aucune option n'est  indiquee
                      (ou  si  c'est cto qui est choisi), le client utilise la
                      semantique de coherence 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 change sur le serveur.

                      L'utilisation  de  l'option  nocto  peut  ameliorer  les
                      performances des montages en lecture seule, mais devrait
                      etre  limitee  au  cas  ou les donnees sur le serveur ne
                      changent qu'occasionnellement. La section COH'ERENCE  DES
                      DONN'EES  ET  DES  M'ETADONN'EES  expose le comportement de
                      cette option en details.

       acl / noacl    Indiquer s'il  faut  utiliser  le  protocole  auxiliaire
                      NFSACL  sur ce point de montage. Le protocole auxiliaire
                      NFSACL est un protocole proprietaire mis en oeuvre  dans
                      Solaris  et qui gere les listes de controle d'acces (les
                      ACLs). NSFACL n'est jamais devenu un element standard de
                      la specification du protocole NFS.

                      Si  ni  acl  ni  noacl  ne sont precisees, le client NFS
                      negocie avec le serveur afin de savoir si  le  protocole
                      NFSACL   est   actif,  et  l'utilise  dans  ce  cas.  La
                      desactivation du protocole auxiliaire NFSACL est parfois
                      rendue   necessaire   quand   la  negociation  pose  des
                      problemes sur le client ou sur le serveur. Consultez  la
                      section CONSID'ERATIONS DE S'ECURIT'E pour plus de details.

       rdirplus / nordirplus
                      Indiquer  s'il faut utiliser les requetes READDIRPLUS de
                      NFS version 3. Si cette option  n'est  pas  definie,  le
                      client  NFS  utilisera  les requetes READDIRPLUS sur les
                      montages en NFS version 3 pour  la  lecture  des  petits
                      repertoires.  Certaines applications sont plus efficaces
                      si le client n'utilise que  des  requetes  READDIR  pour
                      tous les repertoires.

       local_lock=m'ecanisme
                      Precise  si le verrouillage local doit etre utilise pour
                      les mecanismes flock, POSIX,  ou  les  deux.   mechanism
                      peut  etre  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
                      portee  que  pour  les  applications qui tournent sur ce
                      meme client. Les  applications  distantes  ne  sont  pas
                      informees de ces verrous.

                      Si  cette  option  n'est  pas  precisee,  ou si none est
                      precise, le client suppose que les verrous ne  sont  pas
                      locaux.

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

                      Si flock est specifie, le client suppose que  seuls  les
                      verrous  flock  sont locaux, et utilise le protocole NLM
                      associe pour verrouiller les fichiers quand les  verrous
                      POSIX sont utilises.

                      Si posix est specifie, le client suppose que les verrous
                      POSIX sont locaux, et utilise le protocole  NLM  associe
                      pour  verrouiller  les  fichiers quand les verrous flock
                      sont utilises.

                      Pour supporter le comportement flock de facon  semblable
                      a  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 partage en  mode  verrouille  flock.  Puisque  les
                      clients  NFS  >  2.6.12  utilise  flock  en  emulant les
                      verrous POSIX, il y aura un conflit de verrous.

                      NOTE : Quand elles sont utilisees ensemble, l'option  de
                      montage   'local_lock'  sera  ecrasee  par  l'option  de
                      montage 'nolock'/'lock'.

   Options pour NFS version 4 uniquement
       Utilisez ces options ainsi que les options de la premiere  sous-section
       ci-dessus  pour  les systemes de fichiers de type NFS version 4 et plus
       recents.

       proto=idreseau Le  nom  et  la  famille  du  protocole   de   transport
                      qu'utilise  le  client NFS pour transmettre ses requetes
                      au serveur NFS pour ce point de montage. Si  un  serveur
                      NFS  a  en  meme  temps  une  adresse  IPv4 et une IPv6,
                      l'utilisation   d'un   identifiant    reseau    idreseau
                      entrainera  le  choix  d'IPv4 ou d'IPv6 pour communiquer
                      avec ce serveur.

                      Si la prise en charge pour TI-RPC est compilee  dans  la
                      commande  mount.nfs,  idreseau  peut etre un identifiant
                      reseau valide parmi  ceux  listes  dans  /etc/netconfig.
                      Sinon,  idreseau  doit valoir << tcp >> ou << udp >>, et
                      IPv4 sera utilise.

                      Les serveurs NFS version 4  doivent  prendre  en  charge
                      TCP,  donc si cette option n'est pas precisee, le client
                      NFS utilise le protocole TCP. Veuillez vous referer a la
                      section M'ETHODES DE TRANSPORT pour plus de details.

       port=n         Valeur  numerique du port du service NFS sur le serveur.
                      Si le service NFS du serveur n'est pas accessible sur le
                      port indique, la requete de montage echoue.

                      Si  cette option de montage n'est pas definie, le client
                      NFS utilisera le numero de port standard de  NFS  (2049)
                      sans  verifier  de  prime  abord  le  service rpcbind du
                      serveur. Cette option permet a un client  NFS  version 4
                      de  contacter  un  serveur  NFS  version 4  a travers un
                      pare-feu qui bloquerait les requetes rpcbind.

                      Si la valeur du port  indiquee  est  0,  le  client  NFS
                      utilisera le numero de port du service NFS publie par le
                      service  rpcbind  du  serveur.  La  requete  de  montage
                      echouera  si  le  service  rpcbind  du serveur n'est pas
                      disponible, si le  service  NFS  du  serveur  n'est  pas
                      enregistre  dans  son  service rpcbind, ou si le service
                      NFS du serveur n'est pas accessible sur le port publie.

       intr / nointr  Indiquer  si  les  signaux   peuvent   interrompre   les
                      operations sur les fichiers pour ce point de montage. Si
                      aucune option n'est indiquee (ou si  intr  est  choisi),
                      les appels systemes renvoient EINTR si une operation NFS
                      en cours est interrompue par un signal.  Si  nointr  est
                      indique,  les  signaux n'interrompent pas les operations
                      NFS.

                      L'utilisation de l'option intr est preferable a celle de
                      l'option  soft  car  le risque de corruption des donnees
                      est moins important.

                      Les options de montage intr/ nointr sont obsoletes  pour
                      des  noyaux  ulterieurs  au  2.6.25.  Seul  un signal de
                      terminaison SIGKILL peut interrompre une  operation  NFS
                      en  cours  sur ces noyaux, et, si precisee, cette option
                      est ignoree pour assurer  une  compatibilite  ascendante
                      sur des anciens noyaux.

       cto / nocto    Indiquer  s'il  faut utiliser la semantique de coherence
                      du cache close-to-open pour les repertoires  NFS  de  ce
                      point  de montage. Si ni cto ni nocto ne sont indiquees,
                      la semantique de coherence du cache  close-to-open  sera
                      utilisee par defaut pour les repertoires.

                      La  politique  de mise en cache des donnees des fichiers
                      n'est  pas  concernee  par  cette  option.  La   section
                      COH'ERENCE  DES  DONN'EES  ET  DES  M'ETADONN'EES  decrit le
                      comportement de cette option en details.

       clientaddr=n.n.n.n
                      Indiquer  une  seule  adresse  IPv4  en  quatre  parties
                      separees  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 requetes NFSv4 de rappel
                      sur les fichiers de ce point de montage. Si  le  serveur
                      ne   peut   pas   etablir   de   connexion   de   rappel
                      (<< callback >>)  sur  ces  clients,  les   performances
                      peuvent  etre  degradees  ou  les  acces  a ces fichiers
                      temporairement suspendus.

                      Si cette option n'est pas indiquee, la commande mount(8)
                      essaie  de  decouvrir  automatiquement  une  adresse  de
                      rappel  (<< callback >>)  appropriee.  La  procedure  de
                      decouverte  automatique  n'est  cependant  pas parfaite.
                      Dans le cas d'interfaces reseau multiples, de directives
                      de  routages  speciales ou de typologie reseau atypique,
                      l'adresse exacte a utiliser pour les rappels peut ne pas
                      etre triviale a determiner.

SYST`EME DE FICHIERS DE TYPE nfs4

       Le  type nfs4 de systeme de fichiers est une ancienne syntaxe precisant
       l'utilisation de NFSv4. Il peut toujours etre utilise avec  toutes  les
       options  specifiques  a  NFSv4,  a  l'exception  de l'option de montage
       nfsvers

FICHIER DE CONFIGURATION DU MONTAGE

       Si la commande de montage est configuree pour, toutes  les  options  de
       montage  decrites  dans  la section precedente peuvent etre configurees
       dans le fichier  /etc/nfsmount.conf.  Referez-vous  a  nfsmount.conf(5)
       pour plus de details.

EXEMPLES

       Pour  realiser  le  montage  d'un  partage  en  NFS  version 2, il faut
       preciser que le type  du  systeme  de  fichiers  est  nfs  et  indiquer
       l'option  de  montage  nfsvers=2.  Pour  realiser  un  montage  en  NFS
       version 3, il faut preciser que le type du systeme de fichiers est  nfs
       et  indiquer l'option de montage nfsvers=3. Pour realiser un montage en
       NFS version 4, il faut preciser que le type du systeme de fichiers  est
       nfs,  avec  l'option  de  montage  nfsver=4,  ou demander le systeme de
       fichiers nfs4.

       L'exemple de fichier /etc/fstab qui suit permet a la commande mount  de
       negocier des valeurs par defaut 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 realiser un montage NFS version 4  en  TCP,
       utilisant l'authentification reciproque de Kerberos 5.

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

       Cet exemple peut servir a realiser le montage de /usr grace a 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'ETHODES DE TRANSPORT.

       Les  clients  NFS  envoient  leurs  requetes aux serveurs NFS grace aux
       appels de procedures  distantes  (<< Remote  Procedure  Calls >>),  les
       RPCs.  Le  client  RPC  decouvre automatiquement les entrees du service
       distant,  gere  l'authentification  requete  par  requete,  ajuste  les
       parametres  des requetes afin de gerer l'ordre des octets sur le client
       et le serveur (<< endianess >>), et se charge de la retransmission  des
       requetes  qui  pourraient  s'etre  perdues  dans  le  reseau  ou sur le
       serveur. Les requetes et les reponses RPC circulent sur un protocole de
       transport reseau.

       Dans  la  plupart  des  cas,  la commande mount(8), le client NFS et le
       serveur NFS peuvent negocier automatiquement les valeurs  adequates  de
       taille  pour les transferts de donnees et de transport pour un point de
       montage. Cependant, dans certains cas, il peut etre efficace d'indiquer
       explicitement ces valeurs grace aux options de montage.

       Anciennement,  les clients NFS se servaient uniquement du transport UDP
       pour transmettre des requetes aux serveurs. Bien que son implementation
       soit  simple,  NFS  sur UDP a de nombreuses limitations qui l'empechent
       d'obtenir de bonnes  performances  et  un  fonctionnement  fluide  dans
       certains  environnements  de  deploiement  courants. Un taux de paquets
       perdus meme insignifiant entraine la perte de requetes  NFS  completes.
       On  regle  alors generalement le delai de depassement (<< timeout >>) a
       une valeur inferieure a  la  seconde  afin  que  les  clients  puissent
       recuperer  rapidement  en cas de requetes rejetees. Cela peut entrainer
       une surcharge du trafic reseau et du serveur.

       Cependant,  UDP  peut  etre  assez  efficace  grace  a   des   reglages
       specifiques  lorsque le MTU du reseau depasse la taille de transfert de
       donnees  de  NFS  (par  exemple  dans  les  environnements  reseau  qui
       utilisent  les  trames  Ethernet Jumbo). Dans ces cas, il est judicieux
       d'adapter les reglages rsize et wsize de facon a ce que chaque  requete
       de  lecture  ou  d'ecriture  NFS  soit contenue dans quelques trames du
       reseau (voire meme dans une seule trame). Cela  reduit  la  probabilite
       qu'une  perte d'une simple trame reseau de la taille de la MTU entraine
       la perte complete d'un grande requete en lecture ou ecriture.

       TCP est le protocole de transport utilise par defaut  dans  toutes  les
       implementations modernes de NFS. Il est efficace dans pratiquement tous
       les environnements reseau concevables et offre d'excellentes  garanties
       contre  la  corruption  de  donnees  que pourrait entrainer un incident
       reseau. TCP est souvent requis pour acceder a un serveur a  travers  un
       pare-feu.

       Dans  des  conditions  normales, les reseaux rejettent des paquets bien
       plus souvent que les serveurs  NFS  ne  rejettent  de  requetes.  C'est
       pourquoi  un  reglage agressif de delai de depassement (<< time-out >>)
       de retransmission pour NFS sur TCP est inutile. Les reglages  habituels
       de  delai  de  depassement  pour  NFS  sur TCP varient entre une et dix
       minutes. Apres qu'un client a termine ses retransmissions (la valeur de
       l'option retrans de mount), il considere que le reseau a subi une panne
       et tente de se reconnecter au serveur grace a une nouvelle interface de
       connexion (<< socket >>). Puisque TCP fiabilise le transport de donnees
       sur le reseau, rsize et wsize peuvent en toute securite  permettre  par
       defaut  la  plus  grande valeur geree a la fois par le client et par le
       serveur, independamment de la taille du MTU du reseau.

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

       Le  client  Linux  peut  utiliser  differents  modes  de transfert pour
       contacter le service rpcbind d'un  serveur,  son  service  mountd,  son
       gestionnaire  de  verrou  reseau  (NLM)  et son service NFS. Le mode de
       transport utilise par le client NFS  de  Linux  pour  chaque  point  de
       montage  depend  des  options  passees  a  mount,  qui  incluent proto,
       mountproto udp et tcp.

       Le client envoie des notifications au  gestionnaire  reseau  de  statut
       (NSM :  << network status manager >>) via UDP, quel que soit le mode de
       transfert precise. Il ecoute cependant les notifications NSM du serveur
       a  la  fois  sur  UDP  et TCP. Le protocole gerant la liste de controle
       d'acces a NFS (NFACL : << nfs access control list >>) utilise  le  meme
       mode de transfert que le service NFS principal.

       Si  aucune  option n'est precisee 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 defaut.

       Si  le serveur ne gere 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 gere par le client ou est mal  configure,
       la  requete de montage echoue. Si l'option bg a ete passee, la commande
       mount passe en arriere-plan et continue d'essayer la requete de montage
       demandee.

       Quand  l'une  des  options  proto,  udp  ou  tcp  est  passee  mais que
       mountproto ne l'est pas, le mode de transfert demande est utilise a  la
       fois pour contacter le service mountd du serveur et ses services NLM et
       NFS.

       Si l'option mountproto est passee mais que ni proto, ni udp et  ni  tcp
       n'est  passee  alors  le mode demande est utilise pour la requete mount
       initiale, mais la commande mount  essaye  de  decouvrir  quel  mode  de
       transfert est pris en charge pour le protocole NFS, et preferera TCP si
       les deux modes sont implementes.

       Si mountproto et proto (ou udp ou tcp) sont passes en  meme  temps,  le
       mode  de  transport  indique  a l'option mountproto est utilise pour la
       requete initiale de mountd, et le mode indique a proto (ou udp ou  tcp)
       est  utilise  pour  NFS,  quel  que  soit  l'ordre  de  ces options. Le
       programme ne cherchera pas a trouver les services si ces  options  sont
       donnees.

       Si  l'une  des  options  proto,  udp, tcp ou mountproto est passee plus
       d'une fois dans une meme commande, alors la valeur retenue  sera  celle
       la plus a droite.

COH'ERENCE DES DONN'EES ET DES M'ETADONN'EES

       Certains  systemes de fichiers en grappes (cluster) recents offrent une
       coherence absolue du cache a leurs clients. La  coherence  parfaite  de
       cache aux clients NFS << disparates >> est difficile a obtenir, surtout
       sur les reseaux de grandes tailles (WAN). Dans ce cas,  NFS  est  regle
       pour la plus faible coherence de cache qui satisfait les contraintes de
       la plupart des types de partage de fichiers. Habituellement, le partage
       de  fichiers  est  totalement sequentiel : le premier client A ouvre un
       fichier, ecrit quelque chose dedans, puis le ferme. Ensuite, un  client
       B ouvre ce meme fichier, puis lit les modifications.

   Coh'erence de cache << close-to-open >>
       Quand  une  application  ouvre un fichier stocke sur un serveur NFS, le
       client NFS  verifie  qu'il  existe  toujours  sur  le  serveur  et  que
       l'utilisateur  qui  ouvre  ce  fichier  en a bien le droit, grace a des
       requetes GETATTR ou ACCESS. Quand l'application ferme  le  fichier,  le
       client  NFS  ecrit  toutes  les  modifications  en  attente afin que le
       prochain a ouvrir ce fichier puisse en voir les changements. Cela donne
       l'opportunite  au  client NFS de prevenir l'application de toute erreur
       en ecriture sur le serveur, via le  code  de  retour  de  close(2).  Ce
       systeme  de  verification  a l'ouverture et de purge a la fermeture est
       connu  sous  le  nom  de   coherence   de   cache   << close-to-open >>
       (close-to-open cache consistency).

   Faible coh'erence de cache
       Il  y  a  toujours  des cas dans lesquels le cache de donnees du client
       contient des donnees incoherentes. Dans la version 3 du  protocole  NFS
       est  apparue  la  << faible  coherence de cache >> (appelee aussi WCC),
       offrant une methode efficace de verification des attributs d'un fichier
       avant  et  apres  une  requete  unique.  Cela  permet  a  un client une
       meilleure perception des modifications qui ont pu  etre  realisees  par
       les autres clients.

       Quand   un   client  genere  beaucoup  d'operations  concomitantes  qui
       modifient le meme fichier au meme  moment  (par  exemple  grace  a  des
       ecritures  asynchrones  en arriere-plan), il est difficile de savoir si
       le fichier a ete modifie par ce client ou par un autre.

   M'emorisation (cache) des attributs
       L'utilisation de l'option noac de mount permet de realiser la coherence
       de  la  memorisation  (cache)  des attributs pour de multiples clients.
       Pratiquement toutes les operations de systeme de fichiers verifient les
       informations d'attributs de fichiers. Le client garde cette information
       en memoire (cache) pendant un certain temps afin de reduire  la  charge
       du serveur et du reseau. Quand noac est activee, le cache des attributs
       de fichier est desactive sur le client et  chaque  operation  qui  doit
       verifier  les  attributs des fichiers doit imperativement s'adresser au
       serveur. Ceci permet au client de voir rapidement les modifications sur
       un   fichier,   en   contrepartie  d'une  augmentation  importante  des
       operations reseaux.

       Soyez attentif  a  ne  pas  confondre  l'option  noac  avec  << pas  de
       memorisation  de  donnees  (no data caching) >>. L'option noac de mount
       empeche la mise en cache par le client des metadonnees du fichier, mais
       il  existe  toujours  des cas dans lesquels des incoherences de donnees
       cachees peuvent survenir entre le client et le serveur.

       Le protocole NFS n'a pas ete concu pour gerer la coherence absolue  des
       caches  pour  des grappes (clusters) de systemes de fichiers sans qu'il
       soit necessaire d'utiliser des types particuliers de  serialisation  au
       niveau  applicatif. Si la coherence absolue du cache est necessaire 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
       desactiver totalement la mise en cache des donnees.

   Mettre en cache les entr'ees r'epertoires
       Le  client  NFS  Linux  garde  en cache les resultats d'une requete NFS
       LOOKUP. Si la requete pointe sur un repertoire existant sur le serveur,
       le  resultat  sera  note  positif. Sinon, si le repertoire n'existe pas
       (c'est-a-dire si le serveur retourne ENOENT),  le  resultat  sera  note
       n'egatif.

       Afin  de  detecter  l'ajout  ou  la  suppression  de repertoires sur le
       serveur,  le  client  NFS  Linux  regarde  la  date   de   modification
       (<< mtime >>)  du  repertoire.  Si le client detecte un changement dans
       cette date, le client supprime tous  les  resultats  LOOKUP  encore  en
       cache  concernant  ce  repertoire. Comme la date de modification est un
       attribut conserve en cache, il est possible qu'un peu de temps se passe
       avant   que   le   client  remarque  le  changement.  Referez-vous  aux
       descriptions des options de montage acdirmin,  acdirmax  et  noac  pour
       plus d'information quant a la maniere dont le temps de modification est
       mis en cache.

       Mettre en cache les entrees des repertoires ameliore  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
       repertoires,  cependant,  peut  interferer  avec  des  applications qui
       tournent simultanement sur de nombreux clients et qui doivent  detecter
       rapidement  la  creation  ou  la  suppression  de fichiers. L'option de
       montage lookupcache permet de personnaliser certains  comportements  de
       mise en cache de repertoires.

       Avant  la  version  2.6.28  du  noyau,  le  client  NFS Linux cherchait
       uniquement les resultats de recherches positifs.  Cela  permettait  aux
       applications de detecter rapidement de nouvelles entrees de repertoires
       creees par  d'autres  clients,  tout  en  fournissant  une  partie  des
       benefices  dus  a  la  mise  en cache. Si une application depend de cet
       ancien     comportement,     vous     pouvez     utiliser      l'option
       lookupcache=positive.

       Si  le  client  ignore  son  cache  et  valide  toutes  les requetes de
       recherche avec le serveur, il peut alors detecter  immediatement  toute
       creation  ou suppression de repertoire par un autre client. Vous pouvez
       forcer ce comportement avec  l'option  lookupcache=none.  L'absence  de
       mise  en  cache  des repertoires entraine une augmentation du nombre de
       requetes NFS, et donc une perte de performances. Empecher 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  maniere
       dont le client NFS met en cache les attributs d'un fichier.

   L'option de montage sync
       Le  client  NFS gere l'option de montage sync differemment que d'autres
       systemes de fichiers (consultez mount(8) pour une description generique
       des  options  de  montage  sync  et async). Si ni sync ni async ne sont
       indiquees (ou si l'option async est indiquee), le  client  NFS  retarde
       l'envoi  au  serveur  des ordres d'ecriture des applications jusqu'a ce
       que l'un de ces evenements survienne :

              La saturation en memoire  entraine  une  demande  de  ressources
              memoire au systeme.

              Une  application  met  a  jour  (<< flush >>)  les  donnees d'un
              fichier de maniere explicite avec sync(2), msync(2) ou fsync(3).

              Une application ferme un fichier avec close(2).

              Le fichier est verrouille/deverrouille grace a fcntl(2).

       Autrement dit, dans les conditions normales d'utilisation, des  donnees
       ecrites  par  une  application peuvent ne pas apparaitre instantanement
       sur le serveur qui heberge le fichier.

       Si l'option sync est precisee pour un  point  de  montage,  tout  appel
       systeme  qui ecrit des donnees dans des fichiers de ce point de montage
       entraine la purge des donnees sur le serveur avant de revenir en espace
       utilisateur  (<< user  space >>). Cela offre une meilleure coherence du
       cache des donnees, mais a un impact certain sur les performances.

       Les applications peuvent utiliser le drapeau  d'ouverture  O_SYNC  afin
       que  les  ecritures  d'un fichier precis soient immediatement 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 Reseaux (NLM, Network Lock Manager) est un
       protocole auxiliaire  separe  servant  a  gerer  les  verrous  sur  les
       fichiers  dans  les  versions 2 et 3 de NFS. Pour gerer la recuperation
       des verrous apres le redemarrage d'un client ou du serveur,  un  second
       protocole  (connu  sous le nom de protocole Network Status Manager) est
       necessaire. Dans la version 4 de NFS, le verrouillage des fichiers  est
       directement  implante  dans  le protocole NFS, et les protocoles NLM et
       NSM ne sont plus utilises.

       Dans la plupart  des  cas,  les  services  NLM  et  NSM  sont  demarres
       automatiquement et aucune configuration additionnelle n'est requise. La
       configuration en noms de domaine completement definis  (FQDN)  de  tous
       les  clients  NFS  est  necessaire  pour  permettre aux serveurs NFS de
       retrouver leurs clients, afin de les prevenir en cas de redemarrage.

       NLM ne gere 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
       grace a flock(2) en annonces de verrouillage.

       Lors du montage de serveurs ne gerant pas le protocole NLM ou lorsqu'on
       monte un serveur NFS a travers  un  pare-feu  qui  bloque  le  port  du
       service NLM, il faut utiliser l'option nolock de mount. Le verrouillage
       NLM doit etre desactive grace a l'option nolock lorsqu'on  utilise  NFS
       pour  monter  /var, puisque /var contient les fichiers utilises par NLM
       dans son implementation sous Linux.

       L'utilisation de l'option nolock est parfois conseillee pour  ameliorer
       les  performances  d'une application proprietaire qui ne tourne que sur
       un seul client mais qui utilise intensement les verrous de fichiers.

   Les caract'eristiques du cache de la version 4 de NFS.
       Le comportement du cache des donnees et des metadonnees des clients NFS
       version 4 est identique a celui des precedentes versions. Toutefois, la
       version 4 de NFS offre deux  nouveaux  dispositifs  pour  ameliorer  le
       comportement  du  cache :  attributs  de  changement  et  d'el'egation de
       fichier.

       L'attribut de changement est  un  nouvel  element  des  metadonnees  de
       fichiers  et  de  repertoires  NFS qui enregistre les modifications des
       donnees.  Il  se  substitue  a  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  lies  a la gestion de l'horodatage ni sur le
       client ni sur le serveur.

       La d'el'egation 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 etait le seul a y acceder.  Le  serveur  s'engage  a
       prevenir  le  client (grace a une requete de rappel, ou << callback >>)
       si un autre client tente d'acceder a ce meme fichier.  Une  fois  qu'un
       fichier  a ete delegue a un client, ce client peut memoriser (mettre en
       cache) les donnees et les metadonnees de ce fichier de facon  agressive
       sans avoir a contacter le serveur.

       Il y a deux types de delegations : lecture et 'ecriture.  Une delegation
       en lecture indique que  le  serveur  avertira  le  client  si  d'autres
       clients  veulent  ecrire  dans  ce  fichier. Une delegation en 'ecriture
       indique que le  client  sera  prevenu  des  tentatives  de  lecture  ou
       d'ecriture.

       Les serveurs offrent les delegations de fichier sitot qu'un fichier est
       ouvert et peuvent annuler ces  delegations  n'importe  quand  des  lors
       qu'un  autre client desire acceder a un fichier d'une maniere qui entre
       en conflit avec les delegations deja  attribuees.  Les  delegations  de
       repertoires ne sont pas gerees.

       Afin  de  pouvoir  gerer  les  alertes  de  delegations  (<< delegation
       callback >>), le serveur verifie le chemin retour  vers  le  client  au
       moment  du  contact initial de celui-ci. Si le retour vers le client ne
       peut pas etre etabli, le  serveur  n'attribue  purement  et  simplement
       aucune delegation a ce client.

CONSID'ERATIONS DE S'ECURIT'E.

       Les serveurs NFS controlent l'acces aux donnees des fichiers, mais leur
       offre de gestion de l'authentification des requetes NFS depend de  leur
       implementation des RPC. Les controles d'acces NFS traditionnels imitent
       les controles d'acces binaires standards offerts par  les  systemes  de
       fichiers  locaux.  L'authentification  RPC  traditionnelle  utilise  un
       nombre pour representer chaque utilisateur (normalement l'uid propre  a
       cet   utilisateur),  un  nombre  pour  representer  le  groupe  de  cet
       utilisateur (le gid de  l'utilisateur)  et  un  ensemble  d'au  maximum
       16 nombres   de  groupes  additionnels  pour  representer  les  groupes
       auxquels cet utilisateur peut appartenir.

       Traditionnellement, les donnees du fichier et l'ID de l'utilisateur  ne
       sont  pas  chiffrees  sur  le  reseau  (en  clair).  Qui  plus est, les
       versions 2 et 3 de NFS utilisent  des  protocoles  auxiliaires  separes
       pour  le montage, le verrouillage et le deverrouillage des fichiers, et
       pour renvoyer les valeurs de retour systeme des  clients  et  serveurs.
       Ces protocoles auxiliaires n'utilisent pas d'authentification.

       En  plus  d'avoir  integre  ces  deux  protocoles  auxiliaires  dans le
       protocole NFS principal, la version 4 de  NFS  offre  des  formes  plus
       avancees de controle d'acces, d'authentification, et de protection lors
       du transfert des donnees. La  specification  de  la  version 4  de  NFS
       requiert  les  ACLs  NFSv4,  l'authentification RPCGSS, et les diverses
       securites RPCGSS permettant le controle d'integrite et  le  chiffrement
       via  RPC. Puisque la version 4 de NFS ajoute les fonctionnalites de ces
       protocoles au coeur du protocole NFS, les nouvelles caracteristiques de
       securite  s'appliquent  a  toutes  les  operations  de  NFS  version 4,
       incluant donc le montage, le verrouillage des  fichiers,  et  ainsi  de
       suite.  L'authentification  RPCGSS  peut  aussi  etre utilisee avec les
       versions 2 et 3 de NFS, mais ne protege pas les protocoles associes.

       L'option de montage sec indique que le  mode  de  securite  RPCGSS  est
       actif  sur  ce  point  de  montage  NFS. L'ajout de sec=krb5 fournit la
       preuve chiffree de l'identite de l'utilisateur pour chaque requete RPC.
       Ce   dispositif   offre   une  verification  forte  de  l'identite  des
       utilisateurs qui  accedent  aux  donnees  du  serveur.  Notez  que  des
       configurations  supplementaires  a  cet ajout de l'option de mount sont
       necessaires pour activer la securite Kerberos.  Consultez  la  page  de
       manuel de rpc.gssd(8) pour plus de details.

       Deux  dispositifs  additionnels  de  la  securite Kerberos sont pris en
       charge : krb5i et krb5p. Le dispositif  de  securite  krb5i  offre  une
       garantie  de  chiffrement fort contre la falsification des donnees pour
       chaque requete RPC. Le dispositif  de  securite  krb5p  chiffre  chaque
       requete  RPC  afin  d'eviter qu'elle soit exposee pendant son transfert
       sur  le  reseau.  Toutefois,  le  chiffrement  ou  la  verification  de
       l'integrite  entrainent  des baisses de performance. D'autres formes de
       securite par chiffrement (telles que lipkey ou SPKM3) sont aussi prises
       en charge.

       Le  protocole  NFS  version 4  permet  aux  clients  et aux serveurs la
       negociation de multiples dispositifs de securite lors du  processus  de
       montage.   Cependant,   Linux   n'implemente   pas   encore  une  telle
       negociation. Le client Linux indique un seul dispositif de securite  au
       moment  du  montage  qui  restera  ensuite actif pour toute la duree du
       montage. Si le serveur ne gere pas ce dispositif, la requete de montage
       initiale est refusee par le serveur.

   Utiliser un port source non privil'egi'e
       Le  client  NFS  communique  normalement avec le serveur par des tuyaux
       reseaux (network sockets). A chaque bout du tuyau est associe un  port,
       qui  est un simple nombre entre 1 et 65535, ce qui permet de distinguer
       des tuyaux pointant sur la meme adresse IP. Un tuyau est  identifie  de
       maniere  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 general un port privil'egi'e (c'est-a-dire
       avec une valeur inferieure a 1024). Seul un processus tournant avec des
       droits  du  superutilisateur  peut  creer  un  tuyau a partir d'un port
       privilegie.

       La fourchette des ports potentiellement choisis est configuree par  une
       paire  de  sysctls  pour eviter 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 a un moment donne est en pratique de l'ordre d'une centaine.

       Comme decrit plus haut, le schema 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 a  l'origine  de  requetes.  Un
       serveur  NFS  suppose  que  si  une  connexion  provient  d'un port non
       privilegie, les numeros UID et GID de  la  requete  NFS  ont  deja  ete
       verifies  par le noyau du client ou tout autre programme systeme local.
       Ce systeme est  facile  a  contourner,  mais  sur  un  reseau  securise
       d'ordinateurs de confiance, c'est parfaitement adapte.

       En  gros,  un tuyau est utilise pour chaque point de montage NFS. Si un
       client peut aussi utiliser un port source non privilegie, le nombre  de
       tuyaux  autorises  (et  donc le nombre maximal de points de montages en
       paralleles) sera beaucoup plus important.

       Utiliser un port source non privilegie peut quelque peu compromettre la
       securite  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  requete.  C'est  pourquoi les serveurs NFS ne le
       prennent pas en charge par defaut. En regle generale, ils  l'autorisent
       explicitement a l'aide d'une option de partage.

       Pour  garder  un  bon  niveau de securite tout en ouvrant un maximum de
       points de  montages,  il  est  preferable  d'autoriser  les  connexions
       clients sur un port non privilegie seulement si le serveur et le client
       utilisent tous deux une authentification forte, comme celle fournie par
       Kerberos.

   Montage `a 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
       grace  a  des regles de filtrage IP. Il est toujours possible de monter
       un serveur NFS a travers  un  pare-feu,  bien  que  les  mecanismes  de
       decouverte automatique des terminaisons d'acces (<< endpoints >>) de la
       commande mount(8) peuvent ne pas  fonctionner.  Il  vous  faudra  alors
       fournir   des   details   specifiques   a   ces   terminaisons  d'acces
       (<< endpoints >>) grace 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 demon rpcbind pour determiner :

              Le port reseau utilise par chaque service base sur les RPC

              Le protocole de transport utilise par chaque  service  base  sur
              les RPC

       Le  demon  rpcbind  utilise  un  port bien connu (111) afin d'aider les
       clients a trouver la terminaison (endpoint) d'un service. Bien que  NFS
       utilise  souvent  un  numero  de  port  standard  (2049),  des services
       auxiliaires tels que NLM peuvent choisir au hasard des numeros de  port
       inutilises.

       Les configurations habituelles des pare-feu bloquent le port bien connu
       de rpcbind.  En  l'absence  du  service  rpcbind,  l'administrateur  du
       serveur definit un numero de port pour les services lies a NFS afin que
       le pare-feu puisse permettre l'acces aux ports des services specifiques
       NFS.  Les administrateurs des clients pourront alors indiquer le numero
       du port du service mountd grace a l'option  mountport  de  la  commande
       mount(8).  Il  peut  etre  necessaire d'imposer l'utilisation de TCP ou
       d'UDP si le pare-feu bloque l'un de ces transports.

   D'esactiver le traitement des ACL (Access Control List).
       Solaris permet aux clients NFS  version 3  l'acces  direct  aux  Access
       Control  Lists  (ACL) POSIX stockes dans son systeme de fichiers local.
       Ce protocole auxiliaire proprietaire, connu  sous  le  nom  de  NFSACL,
       offre  un  controle  d'acces  plus  riche  que  le  mode binaire. Linux
       implemente  ce  protocole   dans   un   but   de   compatibilite   avec
       l'implementation  NFS  de Solaris. Cependant, le protocole NFSACL n'est
       jamais devenu une partie standard de la specification NFS version 3.

       La specification de NFS  version 4  impose  une  nouvelle  version  des
       Access  Control  Lists  qui sont semantiquement 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 melange a la fois les ACL  POSIX
       et NFS version 4.

OPTION DE REMONTAGE

       Les  options  de  montage  generique  comme  rw  et  sync  peuvent etre
       modifiees par les points de montage utilisant  l'option  remount.  Voir
       mount(8) pour plus d'information sur les options generiques de montage.

       Sauf  quelques exceptions, les options specifiques a NFS ne peuvent pas
       etre  modifiees  pendant  un  remontage.  Par  example,  le   transport
       sous-jacent  ou  la  version  NFS  ne  peuvent  pas etre changes par un
       remontage.

       Effectuer un remontage sur  un  systeme  de  fichiers  NFS  monte  avec
       l'option  noac  peut  avoir des consequences inattendues. L'option noac
       est  une  combinaison  de  l'option  generique  sync  et  de   l'option
       specifique NFS actimeo=0.

   D'emontage apr`es remontage
       Pour  les  points  de  montage  qui  utilisent  NFS versions 2 ou 3, la
       sous-commande de demontage NFS depend de la connaissance de  l'ensemble
       initial  des  options  de  montage utilisees pour effectuer l'operation
       MNT. Ces options sont stockees sur le disque par  la  sous-commande  de
       montage NFS, et peuvent etre effacees par un remontage.

       Afin  de  s'assurer que les options de montage enregistrees ne sont pas
       effacees lors  d'un  remontage,  il  faut  specifier  au  remontage  le
       repertoire   de  montage  local,  ou  le  serveur  hote  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  deja
       enregistrees sur le disque pour le serveur NFS monte dans /mnt.

FICHIERS

       /etc/fstab     Table des systemes de fichiers

BOGUES

       Le client NFS anterieur a 2.4.7 ne gerait pas NFS sur TCP.

       Le  client NFS anterieur a 2.4.20 utilisait une heuristique pour savoir
       si les donnees memorisees d'un  fichier  (en  cache)  etaient  toujours
       valides  plutot  qu'utiliser  la methode standard de coherence de cache
       close-to-open decrite ci-dessus.

       Depuis la version 2.4.22, Le client NFS utilise une estimation  RTT  de
       type  Van  Jacobsen  pour  definir  les  delais de depassement de temps
       (timeout) lorsqu'il utilise NFS sur UDP.

       Le client NFS Linux anterieur a 2.6.0 ne gerait pas NFS version 4.

       Le client NFS anterieur a 2.6.8 n'utilisait les lectures  et  ecritures
       synchrones   que  lorsque  les  reglages  de  rsize  et  wsize  etaient
       inferieurs a la taille des pages du systeme.

       Le  client  NFS  Linux  ne  prend  toujours  pas  en  charge  certaines
       caracteristiques optionnelles du protocole NFS version 4, telles que la
       negociation de securite, les soumissions de serveurs et  les  attributs
       nommes.

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 specification UDP.
       RFC 793 concernant la specification TCP.
       RFC 1094 concernant la specification de NFS version 2.
       RFC 1813 concernant la specification de NFS version 3.
       RFC 1832 concernant la specification XDR.
       RFC 1833 concernant la specification RPC bind.
       RFC 2203 concernant la specification du protocole de l'API GSS RPCSEC.
       RFC 3530 concernant la specification de NFS version 4.

TRADUCTION

       Cette  page  de  manuel  a  ete  traduite et mise a jour par Christophe
       Blaess entre 1997  et  2003.   La  version  presente  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)