Provided by: manpages-fr-extra_20101103_all bug

NOM

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

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 :

            serveur:chemin /point_de_montage   type_de_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 soit << nfs >> (versions 2  ou  3  du  montage
       NFS)  ou  << nfs4 >>  (version 4 du protocole). Les systemes de fichier
       nfs et nfs4 ont des options de montage similaires, decrites ci-dessous.

OPTIONS DE MONTAGE

       Reportez-vous a 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 valides pour les syst`emes de fichiers nfs ou nfs4
       L'utilisation de ces options est valable a la fois pour les systemes de
       fichiers nfs et nfs4. Cela entraine le meme comportement et  les  memes
       valeurs par defaut pour les deux systemes de fichiers.

       soft / hard    Definit  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        Temps  d'attente  (en dixiemes de seconde) du client NFS
                      avant de re-emettre la  requete  NFS.  Si  cette  option
                      n'est  pas  definie,  les requetes sont re-emises toutes
                      les 60 secondes dans le cas de NFS sur  TCP.  Le  client
                      NFS  ne  fait  aucune verification du delai d'expiration
                      dans le cas de NFS sur TCP.

                      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 maximum 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 maximum 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   blocages   (locking)   de
                      fichiers  est  de  preference  recommandee.  La  section
                      COH'ERENCE DES DONN'EES ET DES M'ETA-DONN'EES  contient  une
                      presentation detaillee de ces approches.

       acregmin=n     Fixer  (en  secondes)  la duree minimale 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     Fixer (en secondes) la duree  maximale  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     Fixer  (en  secondes)  la duree minimale 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     Fixer (en secondes) la duree  maximale  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   fixe  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        Determine  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        Fixer  la duree, en minutes, pendant laquelle le montage
                      NFS sera tente par la commande mount(8), en arriere-plan
                      ou  en avant-plan, avant d'abandonner. Si l'option n'est
                      pas definie, la valeur par defaut pour l'avant-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, 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  obtient  un cache unique. 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 concurrents de  ce
                      meme partage.

                      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
                      Indique 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  maximum  de  points  de  montages
                      permis  par  client,  mais les serveurs NFS doivent etre
                      configures pour permettre la connexion de client par des
                      ports sources non privilegies.

                      Merci  de  vous  referer  a la section CONSID'ERATIONS DE
                      S'ECURIT'E pour d'importants details.

       lookupcache=mode
                      Precise 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 de cache
                      repertoires sont valides 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 valides  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   de  cache  d'entrees  repertoires  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'ETA-DONN'EES
                      contient un propos detaille sur ces echanges.

   Options valides pour le syst`eme de fichiers nfs
       Utilisez   ces  options  ainsi  que  les  options  de  la  sous-section
       precedente pour monter des systemes de fichiers de type nfs.

       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  mont.nfs,  idreseau  est un identifiant reseau
                      valide liste  dans  /etc/netconfig.  Sinon  idreseaupeut
                      valoir  << tcp >>,  << udp >> ou << rdma >> et IPv4 sera
                      utilise.

                      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.

       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.

                      Merci de vous reporter a la partie M'ETHODES DE TRANSPORT
                      pour plus de renseignement 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 maximum du nom du chemin composant ce montage.
                      Si cette option n'est pas definie, la taille maximum est
                      negociee avec le serveur. Dans la plupart des cas, cette
                      taille maximum 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   maximum   aux
                      applications pour ces versions.

       nfsvers=n      Le  numero  de  version  du  protocole  NFS utilise pour
                      contacter le service NFS du serveur. Le  client  NFS  de
                      Linux  gere  les  versions  2  et  3  du  protocole  NFS
                      lorsqu'il utilise un systeme de fichiers de type nfs. Si
                      le  serveur  ne gere pas la version demandee, la requete
                      de montage echoue. Si cette option n'est pas definie, le
                      client tente l'utilisation de la version 3, puis negocie
                      la version NFS avec le  serveur  si  la  gestion  de  la
                      version 3 n'est pas disponible.

       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 blocage 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 COHERENCE DES
                      DONNEES ET DES META-DONNEES 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 uvre 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
                      rendu 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.

   Options valides pour le syst`eme de fichiers nfs4
       Utilisez ces options ainsi que les options de la premiere  sous-section
       ci-dessus pour monter des systemes de fichiers de type nfs4.

       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 respecter TCP, donc
                      si cette  option  n'est  pas  precisee,  le  client  NFS
                      utilise  le  protocole  TCP.  Merci de 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
                      utilise 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'ETA-DONN'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.

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
       nfs4. L'option de montage nfsvers n'est alors pas accepte.

       L'exemple  de fichier /etc/fstab qui suit permet a la commande mount de
       negocier des valeurs par defaut convenables pour le comportement NFS.

            server:/export /mnttnfstdefaults   0 0

       Voici un exemple, issu du fichier /etc/fstab, concernant un montage NFS
       version 2 en UDP.

            server:/export /mnttnfstnfsvers=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.

            server:/export /mnttnfs4 sec=krb5  0 0

       Cet exemple peut servir a realiser le montage de /usr grace a NFS.

            server:/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'ETA-DONN'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 apparu 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 meta-donnees 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
       indiques  (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 meta-donnees 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 meta-donnees 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 meta-donnees 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 singent
       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  cur 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. La gestion similaire
       d'autres  formes  de  securites  par  chiffrement (telles que lipkey ou
       SPKM3) sont aussi disponibles.

       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 chiffre 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  (ie  avec  une
       valeur  inferieure  a 1024). Seul un processus tournant avec des droits
       d'administrateur  (root)  peut  creer  un  tuyau  a  partir  d'un  port
       privilegie.

       La  fourchette des ports potentiellement choisis est configuree par une
       paire de systcls pour eviter l'utilisation de ports  bien  connus,  tel
       celui  de  ssh. Cela signifie que le nombre de ports sources potentiels
       pour le client NFS, et donc pour le  nombre  de  connexions  par  tuyau
       disponible  a  un  moment  donnee  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 maximum 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 d'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  automatiques  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 RPCs

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

       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-feux  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 (ACLs) 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 ACLs
       POSIX. Les ACLs de NFS version 4 ne  sont  pas  totalement  compatibles
       avec  les  ACLs  POSIX. De ce fait, des traductions entre les deux sont
       obligatoires dans un environnement qui melange a la fois les ACLs POSIX
       et NFS version 4.

FICHIERS

       /etc/fstab     Table des systemes de fichiers

BOGUES

       L'option  generique  remount  n'est  pas  totalement geree. Les options
       generiques, comme rw ou ro peuvent  etre  modifiees  grace  a  l'option
       remount,  mais  les  options specifiques NFS ne sont pas toutes gerees.
       Par exemple, le transport utilise, ou la version  NFS  ne  peuvent  pas
       etre changes par un remount. L'execution d'un remount sur un systeme de
       fichiers NFS monte avec  l'option  noac  peut  avoir  des  consequences
       inattendues.  L'option  noac est un melange d'option generique, de sync
       et de l'option actimeo=0 specifique a NFS.

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