Loading

NOM

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

SYNOPSIS

       /etc/fstab

       NFS est un protocole standard de l’Internet créé par Sun Microsystem en
       1984.  NFS  a été développé pour permettre le partage de fichiers entre
       des systèmes connectés à un réseau local. Le client NFS de  Linux  gère
       trois  versions  du  protocole : NFS version 2 [RFC1094], NFS version 3
       [RFC1813], et NFS version 4 [RFC3530].

       La commande mount(8) lie un système de fichiers  au  point  de  montage
       donné  dans  l’espace  de  noms  hiérarchisé  du  système.  Le  fichier
       /etc/fstab décrit la façon dont mount(8) doit recréer la hiérarchie  de
       l’espace  de  noms  du  système  de  fichiers  à  partir de systèmes de
       fichiers indépendants  (dont  ceux  partagés  par  des  serveurs  NFS).
       Chacune  des  lignes  du fichier /etc/fstab décrit un unique système de
       fichiers, son point de montage, et un  ensemble  d’options  par  défaut
       pour ce point de montage.

       Dans le cas des montages de systèmes de fichiers NFS, une ligne dans le
       fichier /etc/fstab indique le nom du serveur, le chemin  du  répertoire
       partagé  à monter, le répertoire local qui sera le point de montage, le
       type de système de fichiers à monter et la liste des options de montage
       qui  indique  la  façon  dont  le  système de fichiers sera monté et le
       comportement du client NFS lorsqu’il accède aux fichiers  du  point  de
       montage.  Le cinquième et le sixième champs de chaque ligne ne sont pas
       utilisés par NFS, et  par  conséquent  contiennent  par  convention  la
       valeur zéro. Par exemple :

            serveur:chemin /point_de_montage   type_de_fs     option,option,...   0
       0

       Le nom du serveur et  le  répertoire  partagé  sont  séparés  par  deux
       points,  alors  que  les  options  de  montage  sont  séparées  par des
       virgules. Les champs restants sont  séparés  par  des  espaces  ou  des
       tabulations.  Le  nom  du  serveur  peut  être un simple nom, un nom de
       domaine complètement défini (FQDN) ou  une  adresse  IPv4  en  notation
       pointée.  Le  champ  fstype contient soit «nfs » (pour les montages NFS
       version 2 ou 3), soit « nfs4 » (pour les montages NFS version  4).  Les
       types  de  systèmes de fichiers nfs et nfs4 partagent les mêmes options
       de montage, qui sont décrites ci-dessous :

OPTIONS DE MONTAGE

       Reportez vous à mount(8) pour la description  des  options  de  montage
       génériques  disponibles  pour  tous  les  systèmes de fichiers. Si vous
       n’avez pas besoin de  spécifier  d’options  de  montage  particulières,
       indiquez l’option générique defaults dans /etc/fstab.

   Options valides pour les systèmes de fichiers nfs ou nfs4
       L’utilisation de ces options est valable à la fois pour les systèmes de
       fichiers nfs et nfs4. Cela entraîne le même comportement et  les  mêmes
       valeurs par défaut pour les deux systèmes de fichiers.

       soft / hard    Définit  le  comportement  de récupération du client NFS
                      lorsqu’une requête NFS ne  répond  pas  (time  out).  Si
                      aucune  option n’est indiquée (ou si c’est l’option hard
                      qui a été choisie),  les  requêtes  NFS  sont  retentées
                      indéfiniment. Si par contre l’option soft a été choisie,
                      le client NFS sera en échec  après  l’envoi  de  retrans
                      retransmissions, entraînant alors le retour d’une erreur
                      à l’application appelante.

                      NB :  Un  délai  expiré  « soft »  peut  provoquer  dans
                      certains cas des erreurs de données non signalées. C’est
                      pourquoi l’option soft doit être utilisée uniquement  si
                      la   réactivité   du  client  est  plus  importante  que
                      l’intégrité des données. L’utilisation de NFS  avec  TCP
                      ou  l’augmentation de la valeur de l’option retrans peut
                      diminuer les risques liés à  l’utilisation  de  l’option
                      soft.

       timeo=n        Temps  d’attente  (en dixièmes de seconde) du client NFS
                      avant de ré-émettre la  requête  NFS.  Si  cette  option
                      n’est  pas  définie,  les requêtes sont ré-émises toutes
                      les 60 secondes dans le cas de NFS sur  TCP.  Le  client
                      NFS  ne  fait  aucune vérification du délai d’expiration
                      dans le cas de NFS sur TCP.

                      Cependant, dans le cas de NFS sur UDP, le client utilise
                      un algorithme évolutif pour estimer la valeur appropriée
                      de dépassement de temps  (timeout)  pour  les  types  de
                      requêtes  fréquement  utilisées  (les  requêtes  READ et
                      WRITE par exemple), mais utilise le réglage  timeo  pour
                      les requêtes moins courantes (comme FSINFO). Si l’option
                      timeo n’est pas définie, les  types  de  requêtes  moins
                      courantes sont ré-émises après 1,1 seconde. Après chaque
                      ré-émission,  le  client  NFS  double   la   valeur   de
                      dépassement   de   temps  pour  cette  requête,  jusqu’à
                      atteindre un maximum de 60 secondes.

       retrans=n      Nombre de tentatives de ré-émission de la requête  avant
                      que   le   client   NFS   n’enclenche   une   action  de
                      récupération. Si l’option retrans n’est pas définie,  le
                      client NFS essaye chaque requête trois fois.

                      Le  client  NFS génère un message « le serveur ne répond
                      pas »  après  retrans  tentatives,  puis  enclenche   la
                      récupération  (qui  dépend  de  l’activation de l’option
                      hard de mount).

       rsize=n        Nombre maximum d’octets pour chaque  requête  réseau  en
                      LECTURE  que  peut  recevoir le client NFS lorsqu’il lit
                      les données d’un fichier sur le serveur NFS.  La  taille
                      réelle de la charge utile de données pour chaque requête
                      NFS en LECTURE est  plus  petite  ou  égale  au  réglage
                      rsize.  La  plus grande charge utile gérée par le client
                      NFS Linux est de 1 048 576 octets (un méga-octet).

                      La valeur de rsize est un  entier  positif  multiple  de
                      1024.  Les  valeurs  de  rsize  inférieures  à 1024 sont
                      remplacées par 4096, et celles supérieures  à  1 048 576
                      sont remplacées par 1 048 576. Si la valeur indiquée est
                      bien dans la plage gérée,  mais  qu’elle  n’est  pas  un
                      multiple de 1024, elle sera arrondie au multiple de 1024
                      inférieur le plus proche.

                      Si la valeur de rsize n’est pas définie, ou si la valeur
                      de rsize dépasse le maximum qu’à la fois le client et le
                      serveur peuvent gérer, le client et le serveur négocient
                      la  plus  grande  valeur  de rsize qu’ils puissent gérer
                      ensemble.

                      L’option rsize de mount telle qu’elle a été définie  sur
                      la  ligne  de commande lors du mount(8) apparaît dans le
                      fichier /etc/mtab. D’autre part,  la  valeur  réelle  de
                      rsize  négociée  entre  le  client  et  le  serveur  est
                      indiquée dans le fichier /proc/mounts.

       wsize=n        Nombre maximum d’octets par  requête  d’ÉCRITURE  réseau
                      que  le  client  NFS  peut  envoyer  quand  il écrit des
                      données dans un fichier sur un serveur  NFS.  La  taille
                      réelle de la charge utile de données pour chaque requête
                      NFS en ÉCRITURE est plus  petite  ou  égale  au  réglage
                      wsize.  La  plus grande charge utile gérée par le client
                      NFS Linux est de 1 048 576 octets (un méga-octet).

                      Comme pour rsize, la valeur  de  wsize  est  une  entier
                      positif   multiple   de   1024.  Les  valeurs  de  wsize
                      inférieures à 1024 sont remplacées par 4096,  et  celles
                      supérieures  à  1 048 576  par  1 048 576.  Si la valeur
                      définie est bien  dans  l’étendue  valide  mais  qu’elle
                      n’est  pas  multiple  de  1024,  elle  est  arrondie  au
                      multiple de 1024 inférieur le plus proche.

                      Si la valeur de wsize n’est pas définie, ou si la valeur
                      wsize  indiquée  est  supérieure  au maximum que soit le
                      client soit le serveur  peut  gérer,  le  client  et  le
                      serveur  négocient la plus grande valeur de wsize qu’ils
                      peuvent tous les deux gérer.

                      L’option wsize de mount telle qu’elle a été indiquée sur
                      la  ligne  de  commande  du  mount(8)  apparaît  dans le
                      fichier /etc/mtab. D’autre part,  la  valeur  réelle  de
                      wsize  négociée par le client et le serveur est indiquée
                      dans le fichier /proc/mounts.

       ac / noac      Définir  si  le  client  peut  mémoriser   (cache)   les
                      attributs  des fichiers. Si aucune option n’est indiquée
                      (ou si c’est ac qui est choisi), le client mémorise  les
                      attributs des fichiers.

                      Afin  d’améliorer  les  performances,  les  clients  NFS
                      mémorisent (cachent) les attributs des fichiers.  Toutes
                      les   quelques  secondes,  un  client  NFS  vérifie  les
                      attributs de chaque fichier de  la  version  du  serveur
                      afin   de  se  mettre  à  jour.  Les  modifications  qui
                      interviennent pendant  ces  petits  intervalles  restent
                      inconnus   tant   que  le  client  n’a  pas  relancé  sa
                      vérification sur le serveur. L’option  noac  empêche  la
                      mémorisation des attributs de fichiers par le client, ce
                      qui permet aux applications de détecter plus  rapidement
                      les modifications des fichiers sur le serveur.

                      En  plus d’empêcher le client de mémoriser les attributs
                      des   fichiers,   l’option   noac    force    l’écriture
                      synchronisée   pour   les   applications  afin  que  les
                      modifications  sur  un  fichier   soient   immédiatement
                      visibles  sur  le  serveur.  De  cette façon, les autres
                      clients  peuvent  rapidement  détecter   les   nouvelles
                      écritures  lors  de  la  vérification  des  attributs du
                      fichier.

                      L’usage de l’option noac offre une plus grande cohérence
                      du   cache  aux  clients  NFS  qui  accèdent  aux  mêmes
                      fichiers, mais au prix d’une pénalisation  significative
                      des   performances.   C’est  pour  cette  raison  qu’une
                      utilisation  judicieuse  des   blocages   (locking)   de
                      fichiers  est  de  préférence  recommandée.  La  section
                      COHÉRENCE DES DONNÉES ET DES  METADONNÉES  contient  une
                      présentation détaillée de ces approches.

       acregmin=n     Fixer  (en  secondes)  la durée minimale de mémorisation
                      (cache) des attributs d’un fichier régulier avant de les
                      rafraîchir  depuis  le serveur. La valeur par défaut est
                      de 3 secondes, si cette option n’est pas définie.

       acregmax=n     Fixer (en secondes) la durée  maximale  de  mémorisation
                      (cache) des attributs d’un fichier régulier avant de les
                      rafraîchir depuis le serveur. La valeur par  défaut  est
                      de 60 secondes, si cette option n’est pas définie.

       acdirmin=n     Fixer  (en  secondes)  la durée minimale de mémorisation
                      (cache) des  attributs  d’un  répertoire  avant  de  les
                      rafraîchir  depuis  le serveur. La valeur par défaut est
                      de 30 secondes si cette option n’est pas définie.

       acdirmax=n     Fixer (en secondes) la durée  maximale  de  mémorisation
                      (cache)  des  attributs  d’un  répertoire  avant  de les
                      rafraîchir depuis le serveur. La valeur par  défaut  est
                      de 60 secondes si cette option n’est pas définie.

       actimeo=n      L’utilisation   de   actimeo   fixe  toutes  les  durées
                      acregmin, acregmax, acdirmin  et  bacdirmax  à  la  même
                      valeur.  Si  cette  option  n’est pas définie, le client
                      utilisera les valeurs par défaut de chacune des options,
                      telles que décrit ci-dessus.

       bg / fg        Détermine  le  comportement de la commande mount(8) dans
                      le cas  d’un  échec  d’une  tentative  de  montage  d’un
                      partage.  L’option  fg entraîne l’arrêt de mount(8) avec
                      un statut d’erreur si la moindre partie de la requête de
                      montage   dépasse   le  temps  alloué  ou  échoue  d’une
                      quelconque autre manière. C’est ce que l’on  appelle  le
                      montage  en  « premier  plan (foreground) », et c’est le
                      comportement par défaut si ni fg ni bg n’est indiqué.

                      Si l’option bg est indiquée,  un  dépassement  du  temps
                      alloué (timeout) ou un échec entraînera la création d’un
                      fils (fork)  qui  continuera  à  essayer  de  monter  le
                      partage. Le père s’interrompt immédiatement en renvoyant
                      un code de sortie à zéro. C’est ce que l’on  appelle  le
                      montage en « arrière-plan (background) ».

                      Si  le  répertoire  servant  de  point  de montage local
                      n’existe pas, la commande mount(8) se comporte comme  si
                      la  requête  était  restée  sans réponse (timeout). Cela
                      permet  aux  montages   NFS   imbriqués   définis   dans
                      /etc/fstab  de s’exécuter dans n’importe quel ordre lors
                      de  l’initialisation  du  système,  même   si   certains
                      serveurs  NFS  ne  sont  pas encore disponibles. On peut
                      aussi  gérer  ces  problèmes  grâce  à  un  auto-monteur
                      (consultez automount(8) pour plus de détails).

       retry=n        Fixer  la durée, en minutes, pendant laquelle le montage
                      NFS sera tenté par la commande mount(8), en arrière-plan
                      ou  en avant-plan, avant d’abandonner. Si l’option n’est
                      pas définie, la valeur par défaut pour l’avant-plan  est
                      de  2  minutes. La valeur par défaut pour l’arrière-plan
                      est 10 000 minutes,  soit  environ  une  semaine,  à  80
                      minutes près.

       sec=mode       Le  type  de sécurité RPCGSS à utiliser pour accéder aux
                      fichiers de ce point de montage. Si l’option  sec  n’est
                      pas  définie,  ou  si sec=sys est choisie, le client NFS
                      utilise le type de sécurité AUTH_SYS pour toute  requête
                      NFS  sur  ce  point  de  montage. Les types de sécurités
                      gérées sont  none,  krb5,  krb5i,  krb5p,  lkey,  lkeyi,
                      lkeyp,  spkm,  spkmi  et  spkmp.  Consultez  la  section
                      CONSIDÉRATIONS DE SÉCURITÉ.

       sharecache / nosharecache
                      Déterminer comment  le  client  partage  ses  caches  de
                      données   et  d’attributs  de  fichiers  lorsqu’un  même
                      partage  est  monté  plus  d’une  fois  en  même  temps.
                      L’utilisation  d’un  seul  cache  réduit  les besoins en
                      mémoire sur le client et présente  aux  applications  un
                      contenu  identique  lorsque  le même fichier partagé est
                      accédé via différents points de montage.

                      Si aucune des options n’est  indiquée,  ou  si  l’option
                      sharecache  est demandée, un seul cache est utilisé pour
                      tous les points de montage qui accèdent au même partage.
                      Si  l’option  nosharecache  est  indiquée,  ce  point de
                      montage obtient un cache unique. Notez que  lorsque  les
                      caches  des  données et des attributs sont partagés, les
                      options  de  montage  du  premier   point   de   montage
                      s’appliquent  pour les futurs montages concurrents de ce
                      même partage.

                      En ce qui concerne  le  noyau  2.6.18,  le  comportement
                      défini  par  nosharecache est le comportement historique
                      normal. Ceci est  considéré  comme  dangereux  pour  les
                      données  puisque  de multiples copies mémorisées du même
                      fichier sur le même  client  peuvent  se  désynchroniser
                      suite à une mise à jour locale d’une des copies.

       resvport / noresvport
                      Specifies whether the NFS client should use a privileged
                      source port when communicating with an  NFS  server  for
                      this  mount  point.  If this option is not specified, or
                      the resvport option is specified, the NFS client uses  a
                      privileged  source  port.   If  the noresvport option is
                      specified, the NFS client uses a  non-privileged  source
                      port.   This  option  is supported in kernels 2.6.28 and
                      later.

                      Using non-privileged source  ports  helps  increase  the
                      maximum  number of NFS mount points allowed on a client,
                      but NFS servers must be configured to allow  clients  to
                      connect via non-privileged source ports.

                      Refer   to   the  SECURITY  CONSIDERATIONS  section  for
                      important details.

   Options valides pour le système de fichiers nfs
       Utilisez  ces  options  ainsi  que  les  options  de  la   sous-section
       précédente pour monter des systèmes de fichiers de type nfs.

       proto=transport
                      Protocole  de  transport  utilisé par le client NFS pour
                      transmettre les requêtes aux serveur NFS pour  ce  point
                      de  montage.  transport  peut  être  soit  udp soit tcp.
                      Chacun  utilise  différentes  valeurs  par  défaut  pour
                      retrans  et  timeo, consultez la description de ces deux
                      options de mount pour plus de détails.

                      En plus  de  contrôler  la  façon  dont  le  client  NFS
                      transmet  les requêtes au serveur, cette option de mount
                      gère aussi la façon dont la commande mount(8) communique
                      avec les services rpcbind et mountd du serveur. Indiquer
                      proto=tcp force  l’utilisation   de  TCP  pour  tout  le
                      trafic  entre  la  commande  mount(8)  et le client NFS.
                      Indiquer proto=udp force l’utilisation d’UDP  pour  tous
                      ces trafics.

                      Si  l’option  proto  de  mount  n’est  pas  définie,  la
                      commande mount(8) découvrira quels protocoles le serveur
                      accepte  et  choisira un transport approprié pour chacun
                      des services. Consultez la section MÉTHODES DE TRANSPORT
                      pour plus détails.

       udp            L’option udp est une variante pour proto=udp, compatible
                      avec d’autres systèmes d’exploitation.

       tcp            L’option tcp est une variante pour proto=tcp, compatible
                      avec d’autres systèmes d’exploitation.

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

                      Si cette option n’est pas définie, ou si le port indiqué
                      est 0, le client  NFS  utilise  le  numéro  du  port  du
                      service NFS publié par le service rpcbind du serveur. La
                      requête de montage  échoue  si  le  service  rpcbind  du
                      serveur  n’est  pas  accessible,  si  le  service NFS du
                      serveur n’est pas enregistré dans son  service  rpcbind,
                      ou si le service NFS du serveur n’est pas accessible sur
                      le port publié.

       mountport=n    Valeur numérique du port de mountd sur le serveur. Si le
                      service  mountd du serveur n’est pas présent sur le port
                      indiqué, la requête de montage échoue.

                      Si cette option n’est pas définie, ou si le port indiqué
                      est 0, la commande mount(8) utilise le numéro du port du
                      service mountd publié par le service rpcbind du serveur.
                      La  requête  de  montage échoue si le service rpcbind du
                      serveur n’est pas accessible, si le  service  mountd  du
                      serveur  n’est  pas enregistré dans son service rpcbind,
                      ou si le service mountd du serveur n’est pas  accessible
                      sur le port publié.

                      Cette option peut être utilisée pour les montages sur un
                      serveur  NFS  à  travers  un  pare-feu  qui  bloque   le
                      protocole rpcbind.

       mountproto=transport
                      The  transport  the NFS client uses to transmit requests
                      to the NFS server’s mountd service when performing  this
                      mount  request,  and  when  later  unmounting this mount
                      point.  transport can be either udp or tcp.

                      This option can be used  when  mounting  an  NFS  server
                      through  a  firewall that blocks a particular transport.
                      When  used  in  combination  with  the   proto   option,
                      different   transports   for  mountd  requests  and  NFS
                      requests can  be  specified.   If  the  server’s  mountd
                      service  is  not  available via the specified transport,
                      the mount request fails.  Refer to the TRANSPORT METHODS
                      section  for  more  on  how  the mountproto mount option
                      interacts with the proto mount option.

       mounthost=name Le nom d’hôte de la machine qui exécute  le  mountd.  Si
                      cette  option  n’est  pas  définie, la commande mount(8)
                      considère que  le  service  mountd  est  assuré  par  la
                      machine qui offre le service NFS.

       mountvers=n    Numéro  de  version  des  RPC  utilisé pour contacter le
                      mountd du serveur. Si cette option n’est pas définie, le
                      client  utilise  un  numéro  de  version  approprié à la
                      version du NFS contacté. Cette option est utile quand de
                      nombreux  services  NFS sont offerts par un seul et même
                      serveur.

       namlen=n       La taille maximum du nom du chemin composant ce montage.
                      Si cette option n’est pas définie, la taille maximum est
                      négociée avec le serveur. Dans la plupart des cas, cette
                      taille maximum est 255 caractères.

                      Des  versions précédentes de NFS ne supportent pas cette
                      négociation. L’utilisation de cette option garantit  que
                      pathconf(3)   donnera   bien  la  longueur  maximum  aux
                      applications pour ces versions.

       nfsvers=n      Le numéro de  version  du  protocole  NFS  utilisé  pour
                      contacter  le  service  NFS du serveur. Le client NFS de
                      Linux  gère  les  versions  2  et  3  du  protocole  NFS
                      lorsqu’il utilise un système de fichiers de type nfs. Si
                      le serveur ne gère pas la version demandée,  la  requête
                      de montage échoue. Si cette option n’est pas définie, le
                      client tente l’utilisation de la version 3, puis négocie
                      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 systèmes d’exploitation.

       lock / nolock  Indiquer  s’il faut utiliser le protocole auxiliaire NLM
                      pour verrouiller les fichiers sur le serveur. Si  aucune
                      option n’est indiquée (ou si c’est lock qui est choisi),
                      le verrouillage NLM est activé pour ce point de montage.
                      Si  on utilise l’option nolock, les applications peuvent
                      verrouiller les fichiers,  mais  ces  verrous  n’ont  de
                      portée  que  pour  les  applications qui tournent sur ce
                      même client. Les  applications  distantes  ne  sont  pas
                      informées de ces verrous.

                      Le blocage NLM doit être désactivé lors de l’utilisation
                      de l’option nolock si /var est monté via NFS, parce  que
                      /var contient des fichiers utilisés par l’implémentation
                      de NLM sous Linux. L’usage de nolock  est  aussi  requis
                      lors  des montages de partages de serveurs NFS ne gérant
                      pas le protocole NLM.

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

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

                      The intr /  nointr  mount  option  is  deprecated  after
                      kernel 2.6.25.  Only SIGKILL can interrupt a pending NFS
                      operation on these kernels, and if specified, this mount
                      option  is  ignored  to  provide backwards compatibility
                      with older kernels.

       cto / nocto    Indiquer s’il faut utiliser la sémantique  de  cohérence
                      de  cache close-to-open. Si aucune option n’est indiquée
                      (ou si c’est cto qui est choisi), le client  utilise  la
                      sémantique de cohérence de cache close-to-open. Si c’est
                      l’option nocto qui est choisie, le  client  utilise  une
                      heuristique  non standard pour savoir quand les fichiers
                      ont changé sur le serveur.

                      L’utilisation  de  l’option  nocto  peut  améliorer  les
                      performances des montages en lecture seule, mais devrait
                      être limitée au cas où les données  sur  le  serveur  ne
                      changent  qu’occasionnellement. La section COHÉRENCE DES
                      DONNÉES ET DES MÉTA-DONNÉES expose  le  comportement  de
                      cette option en détails.

       acl / noacl    Indiquer  s’il  faut  utiliser  le  protocole auxiliaire
                      NFSACL sur ce point de montage. Le protocole  auxiliaire
                      NFSACL  est un protocole propriétaire mis en oeuvre dans
                      Solaris et qui gère les listes de contrôle d’accès  (les
                      ACLs). NSFACL n’est jamais devenu un élément standard de
                      la spécification du protocole NFS.

                      Si ni acl ni noacl ne  sont  précisées,  le  client  NFS
                      négocie  avec  le serveur afin de savoir si le protocole
                      NFSACL  est  actif,  et  l’utilise  dans  ce   cas.   La
                      dés-activation   du   protocole  auxiliaire  NFSACL  est
                      parfois rendu nécessaire quand la négociation  pose  des
                      problèmes  sur le client ou sur le serveur. Consultez la
                      section CONSIDÉRATIONS DE SÉCURITÉ pour plus de détails.

       rdirplus / nordirplus
                      Indiquer  s’il faut utiliser les requêtes READDIRPLUS de
                      NFS version 3. Si cette option  n’est  pas  définie,  le
                      client  NFS  utilisera  les requêtes READDIRPLUS sur les
                      montages en NFS version 3 pour  la  lecture  des  petits
                      répertoires.  Certaines applications sont plus efficaces
                      si le client n’utilise que  des  requêtes  READDIR  pour
                      tous les répertoires.

   Options valides pour le système de fichiers nfs4
       Utilisez  ces options ainsi que les options de la première sous-section
       ci-dessus pour monter des systèmes de fichiers de type nfs4.

       proto=transport
                      Protocole de transport utilisé par le client NFS pour la
                      transmission  des  requêtes au serveur NFS pour ce point
                      de montage. transport peut valoir  soit  udp  soit  tcp.
                      Tous les serveurs NFS version 4 doivent implémenter TCP,
                      donc si cette option de montage n’est  pas  définie,  le
                      client NFS version 4 utilisera le protocole de transport
                      TCP. Consultez la section  MÉTHODES  DE  TRANSPORT  pour
                      plus de détails.

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

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

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

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

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

                      The  intr  /  nointr  mount  option  is deprecated after
                      kernel 2.6.25.  Only SIGKILL can interrupt a pending NFS
                      operation on these kernels, and if specified, this mount
                      option is ignored  to  provide  backwards  compatibility
                      with older kernels.

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

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

       clientaddr=n.n.n.n
                      Indiquer  une  seule  adresse  IPv4  en  quatre  parties
                      séparées  par  des points. Le client NFS signalera alors
                      que les serveurs peuvent envoyer des requêtes  NFSv4  de
                      rappel  sur  les  fichiers de ce point de montage. Si le
                      serveur ne peut  pas  établir  de  connexion  de  rappel
                      (callback)  sur  ces  clients,  les performances peuvent
                      être   dégradées   ou   les   accès   à   ces   fichiers
                      temporairement suspendus.

                      Si cette option n’est pas indiquée, la commande mount(8)
                      essaie  de  découvrir  automatiquement  une  adresse  de
                      rappel (callback) appropriée. La procédure de découverte
                      automatique n’est cependant pas parfaite.  Dans  le  cas
                      d’interfaces réseau multiples, de directives de routages
                      spéciales ou de  typologie  réseau  atypique,  l’adresse
                      exacte  à  utiliser  pour  les  rappels peut ne pas être
                      triviale  à   déterminer   et   devra   être   spécifiée
                      explicitement avec cette option de montage.

EXEMPLES

       Pour  réaliser  le  montage  d’un  partage  en  NFS  version 2, il faut
       préciser que le système de  fichiers  est  de  type  nfs  et  spécifier
       l’option  de montage nfsvers=2. Pour réaliser un montage en NFS version
       3, il faut préciser que le système de  fichiers  est  de  type  nfs  et
       spécifier  l’option  de  montage nfsvers=3. Pour réaliser un montage en
       NFS version 4, il faut préciser que le système de fichiers est de  type
       nfs4. L’option de montage nfsvers n’est alors pas accepté.

       L’exemple  de fichier /etc/fstab qui suit permet à la commande mount de
       négocier des valeurs par défaut convenables pour le comportement NFS.

            server:/export /mnt nfs  defaults  0 0

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

            server:/export /mnt nfs  nfsvers=2,proto=udp 0 0

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

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

       Cet exemple peut servir à réaliser le montage de /usr grâce à NFS.

            server:/export /usr nfs  ro,nolock,nocto,actimeo=3600  0 0

MÉTHODES DE TRANSPORT.

       Les clients NFS envoient leurs requêtes  aux  serveurs  NFS  grâce  aux
       Appels  de  Procédures Distantes (Remote Procedure Calls), les RPCs. Le
       client RPC découvre les entrées  du  service  distant  automatiquement,
       gère  l’authentification requête par requête, ajuste les paramètres des
       requêtes afin de gérer l’ordre des octets sur le client et  le  serveur
       (endianess),  et  se  charge  de  la  retransmission  des  requêtes qui
       pourraient s’être perdues  dans  le  réseau  ou  sur  le  serveur.  Les
       requêtes  et  les  réponses NFS circulent sur un protocole de transport
       réseau.

       Dans la plupart des cas, la commande mount(8),  le  client  NFS  et  le
       serveur  NFS  peuvent négocier automatiquement les valeurs adéquates de
       taille pour les transferts de données et de transport pour un point  de
       montage. Cependant, dans certains cas, il peut être efficace d’indiquer
       explicitement ces valeurs grâce aux options de montage.

       Par tradition, les clients NFS se servent  exclusivement  du  transport
       UDP  pour  la transmission des requêtes vers les serveurs. Bien que son
       implémentation soit simple, NFS sur UDP a de nombreuses limitations qui
       l’empêche  d’obtenir de bonnes performances et un fonctionnement fluide
       dans certains  environnements  de  déploiement  courants.  Un  taux  de
       paquets  perdus  même  insignifiant  entraîne  la perte de requêtes NFS
       complètes. Le délai de dépassement (timeout) pour  les  retransmissions
       est  réglé  inférieur  à  la  seconde  afin de permettre aux clients de
       récupérer rapidement en cas de requêtes rejetées. Cela  peut  entraîner
       une surcharge du trafic réseau et du serveur.

       D’autre  part,  UDP  peut  être  assez  efficace  grâce  à des réglages
       spécifiques lorsque le MTU du réseau dépasse la taille de transfert  de
       données  de  NFS  (par  exemple  dans  les  environnements  réseau  qui
       utilisent les trames Ethernet Jumbo). Dans de tels  environnements,  il
       est  judicieux  d’adapter les réglages rsize et wsize de façon à ce que
       chaque requête de lecture ou d’écriture NFS soit contenue dans quelques
       trames  du  réseau  (voire  même  dans une seule trame). Cela réduit la
       probabilité qu’une perte d’une simple trame réseau de la taille  de  la
       MTU  entraîne  la  perte  complète  d’un  grande  requête en lecture ou
       écriture.

       TCP est le protocole de transport utilisé par défaut  dans  toutes  les
       implémentations modernes de NFS. Il est efficace dans pratiquement tous
       les environnements réseaux concevables et offre d’excellentes garanties
       contre  la  corruption  de  données  que pourrait entraîner un incident
       réseau. TCP est souvent requis pour accéder à un serveur à  travers  un
       pare-feu.

       Dans  des  conditions  normales, les réseaux rejettent des paquets bien
       plus souvent que les serveurs  NFS  ne  rejettent  de  requêtes.  C’est
       pourquoi  un  réglage  agressif  de  délai de dépassement (time-out) de
       retransmission pour NFS sur TCP est inutile. Les réglages habituels  de
       délai  de  dépassement  pour NFS sur TCP sont entre une et dix minutes.
       Après qu’un client  ait  terminé  ses  retransmissions  (la  valeur  de
       l’option retrans de mount), il considère que le réseau a subi une panne
       et tente de se reconnecter  au  serveur  grâce  à  un  nouveau  socket.
       Puisque  TCP  fiabilise le transport de données sur le réseau, rsize et
       wsize peuvent en toute sécurité permettre par  défaut  la  plus  grande
       valeur  gérée à la fois par le client et par le serveur, indépendemment
       de la taille du MTU du réseau.

   Utilisation de loption de montage mountproto
       This section applies only to NFS version 2 and version 3  mounts  since
       NFS version 4 does not use a separate protocol for mount requests.

       The  Linux  NFS  client can use a different transport for contacting an
       NFS server’s rpcbind service, its  mountd  service,  its  Network  Lock
       Manager  (NLM)  service,  and  its  NFS  service.  The exact transports
       employed by the Linux NFS client for each mount point  depends  on  the
       settings   of   the  transport  mount  options,  which  include  proto,
       mountproto, udp, and tcp.

       The client sends Network Status Manager (NSM) notifications via UDP  no
       matter what transport options are specified, but listens for server NSM
       notifications on both  UDP  and  TCP.   The  NFS  Access  Control  List
       (NFSACL) protocol shares the same transport as the main NFS service.

       If no transport options are specified, the Linux NFS client uses UDP to
       contact the server’s mountd service, and TCP to contact its NLM and NFS
       services by default.

       If the server does not support these transports for these services, the
       mount(8)  command attempts to discover what the  server  supports,  and
       then  retries  the  mount request once using the discovered transports.
       If the server does not advertise any transport supported by the  client
       or  is  misconfigured, the mount request fails.  If the bg option is in
       effect, the mount command backgrounds itself and continues  to  attempt
       the specified mount request.

       When  the  proto option, the udp option, or the tcp option is specified
       but the mountproto option is not, the specified transport  is  used  to
       contact  both  the  server’s  mountd  service  and  for the NLM and NFS
       services.

       If the mountproto option is specified but none of the proto, udp or tcp
       options  are  specified,  then  the specified transport is used for the
       initial mountd request, but the mount command attempts to discover what
       the  server  supports  for  the  NFS  protocol,  preferring TCP if both
       transports are supported.

       If both  the  mountproto  and  proto  (or  udp  or  tcp)   options  are
       specified,  then  the  transport  specified by the mountproto option is
       used for the initial mountd request, and the transport specified by the
       proto  option  (or  the udp or tcp options)  is used for NFS, no matter
       what order these options appear.  No  automatic  service  discovery  is
       performed if these options are specified.

       If any of the proto, udp, tcp, or mountproto options are specified more
       than once on the same  mount  command  line,  then  the  value  of  the
       rightmost instance of each of these options takes effect.

COHÉRENCE DES DONNÉES ET DES MÉTA-DONNÉES

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

   Cohérence de cache close-to-open
       Quand  une  application  ouvre un fichier stocké sur un serveur NFS, le
       client NFS  vérifie  qu’il  existe  toujours  sur  le  serveur  et  que
       l’utilisateur  qui  ouvre  ce  fichier  en a bien le droit, grâce à des
       requêtes GETATTR ou ACCESS. Quand l’application ferme  le  fichier,  le
       client  NFS  écrit  toutes  les  modifications  en  attente afin que le
       prochain à ouvrir ce fichier puisse en voir les changements. Cela donne
       l’opportunité  au  client NFS de prévenir l’application de toute erreur
       en écriture sur le serveur, via le  code  de  retour  de  close(2).  Ce
       système  de  vérification  à l’ouverture et de purge à la fermeture est
       connu sous le nom de cohérence de  cache  close-to-open  (close-to-open
       cache consistency).

   Faible cohérence de cache
       Il  y  a  toujours  des cas dans lesquels le cache de données du client
       contient des données incohérentes. Dans la version 3 du  protocole  NFS
       est  apparu  la  « faible  cohérence  de  cache »  (appelée aussi WCC),
       offrant une méthode efficace de vérification des attributs d’un fichier
       avant  et  après  une  requête  unique.  Cela  permet  à  un client une
       meilleure perception des modifications qui ont pu  être  réalisées  par
       les autres clients.

       Quand   un   client  génère  beaucoup  d’opérations  concomitantes  qui
       modifient le même fichier au même  moment  (par  exemple  grâce  à  des
       écritures  asynchrones  en arrière plan), il est difficile de savoir si
       le fichier a été modifié par ce client ou par un autre.

   Mémorisation (cache) des attributs
       L’utilisation de l’option noac de mount permet de réaliser la cohérence
       de  la  mémorisation  (cache)  des attributs pour de multiples clients.
       Pratiquement toutes les opérations de système de fichiers vérifient les
       informations d’attributs de fichiers. Le client garde cette information
       en mémoire (cache) pendant un certain temps afin de réduire  la  charge
       du serveur et du réseau. Quand noac est activée, le cache des attributs
       de fichier est désactivé sur le client et  chaque  opération  qui  doit
       vérifier  les  attributs des fichiers doit impérativement s’adresser au
       serveur. Ceci permet au client de voir rapidement les modification  sur
       un   fichier,   en   contrepartie  d’une  augmentation  importante  des
       opérations réseaux.

       Soyez  attentif  à  ne  pas  confondre  l’option  noac  avec  « pas  de
       mémorisation  de  données  (no  data caching) ». L’option noac de mount
       empêche la mise en cache par le client  des  méta-données  du  fichier,
       mais  il  existe  toujours  des  cas  dans lesquels des incohérences de
       données cachées peuvent survenir entre le client et le serveur.

       Le protocole NFS n’a pas été conçu pour gérer la cohérence absolue  des
       caches  pour  des grappes (clusters) de systèmes de fichiers sans qu’il
       soit nécessaire d’utiliser des types particuliers de  sérialisation  au
       niveau  applicatif. Si la cohérence absolue du cache est nécessaire aux
       clients, les applications devront utiliser le verrouillage de  fichiers
       (file  locking). D’autre part, les applications pourront aussi utiliser
       le drapeau O_DIRECT lors de l’ouverture des fichiers afin de désactiver
       totalement la mise en cache des données.

   Loption de montage sync
       Le  client  NFS gère l’option de montage sync différemment que d’autres
       systèmes de fichiers (Consultez mount(8) pour une description générique
       des  options  de  montage  sync  et async). Si ni sync ni async ne sont
       indiqués (ou si l’option async est indiquée),  le  client  NFS  retarde
       l’envoi  au  serveur  des ordres d’écriture des applications jusqu’à ce
       que l’un de ces événements surviennent :

              La saturation en mémoire  entraîne  une  demande  de  ressources
              mémoire au système.

              Une  application  purge  (flushes)  les  données d’un fichier de
              manière explicite avec sync(2), msync(2) ou fsync(3).

              Une application ferme un fichier avec close(2).

              Le fichier est verrouillé/déverrouillé grâce à fcntl(2).

       Autrement dit, dans les conditions normales d’utilisation, des  données
       écrites  par  une  application peuvent ne pas apparaître instantanément
       sur le serveur qui héberge le fichier.

       Si l’option sync est précisée pour un  point  de  montage,  tout  appel
       système  qui écrit des données dans des fichiers de ce point de montage
       entraîne la purge des données sur le serveur avant de revenir en espace
       utilisateur  (user  space). Cela offre une meilleure cohérence du cache
       des données, mais a un impact certain sur les performances.

       Les applications peuvent utiliser le drapeau  d’ouverture  O_SYNC  afin
       que  les  écritures  d’un fichier précis soient immédiatement prises en
       compte par le serveur, et ce sans l’utilisation  de  l’option  sync  de
       mount.

   Utilisation des verrous de fichiers avec NFS
       Le  Gestionnaire  de Verrous Réseaux (NLM, Network Lock Manager) est un
       protocole auxiliaire  séparé  servant  à  gérer  les  verrous  sur  les
       fichiers  dans  les  versions 2 et 3 de NFS. Pour gérer la récupération
       des verrous après le redémarrage d’un client ou du serveur,  un  second
       protocole  (connu  sous le nom de protocole Network Status Manager) est
       nécessaire. Dans la version 4 de NFS, le verrouillage des fichiers  est
       directement  implanté  dans  le protocole NFS, et les protocoles NLM et
       NSM ne sont plus utilisés.

       Dans la plupart  des  cas,  les  services  NLM  et  NSM  sont  démarrés
       automatiquement et aucune configuration additionnelle n’est requise. La
       configuration en noms de domaine complètement définis  (FQDN)  de  tous
       les  clients  NFS  est  nécessaire  pour  permettre aux serveurs NFS de
       retrouver leurs clients, afin de les prévenir en cas de redémarrage.

       NLM ne gère que l’annonce de verrouillage de fichiers. Pour verrouiller
       les  fichiers  NFS, il faut utiliser fcntl(2) avec les commandes F_GETL
       et F_SETL. Le client NFS convertit  les  verrous  de  fichiers  obtenus
       grâce à flock(2) en annonces de verrouillage.

       Lors du montage de serveurs ne gérant pas le protocole NLM ou lorsqu’on
       monte un serveur NFS à travers  un  pare-feu  qui  bloque  le  port  du
       service NLM, il faut utiliser l’option nolock de mount. Le verrouillage
       NLM doit être désactivé grâce à l’option nolock lorsqu’on  utilise  NFS
       pour  monter  /var, puisque /var contient les fichiers utilisés par NLM
       dans son implémentation sous Linux.

       L’utilisation de l’option nolock est parfois conseillée pour  améliorer
       les  performances  d’une application propriétaire qui ne tourne que sur
       un seul client mais qui utilise intensément les verrous de fichiers.

   Les caractéristiques du cache de la version 4 de NFS.
       Le comportement du cache des données et des  méta-données  des  clients
       NFS   version  4  est  identique  à  celui  des  précédentes  versions.
       Toutefois, la version 4 de NFS offre  deux  nouveaux  dispositifs  pour
       améliorer  le  comportement  du  cache :  attributs  de  changement  et
       dlgation de fichier.

       L’attribut de changement est  un  nouvel  élément  des  métadonnées  de
       fichiers  et  de  répertoires  NFS qui enregistre les modifications des
       données.  Il  se  substitue  à  l’utilisation   de   l’horodatage   des
       modifications  et  changements  du  fichier  pour offrir aux clients la
       validation du contenu  de  leur  cache.  Cependant,  ces  attributs  de
       changement  ne  sont  pas  liés  à la gestion de l’horodatage ni sur le
       client ni sur le serveur.

       La dlgation de fichier est un contrat qui lie un client NFS version 4
       et  le  serveur,  offrant  temporairement  au client le traitement d’un
       fichier comme s’il était le seul à y accéder.  Le  serveur  s’engage  à
       prévenir  le  client  (grâce  à une requête de rappel (callback)) si un
       autre client tente d’accéder à ce même fichier. Une fois qu’un  fichier
       a  été  délégué  à  un  client,  ce  client peut mémoriser (cacher) les
       données et les méta-données de ce fichier de façon agressive sans avoir
       à contacter le serveur.

       Les  délégations  de fichiers sont de deux types : lecture et criture.
       Une délégation en lecture indique que le serveur avertira le client  si
       d’autres  clients  veulent  écrire  dans  ce fichier. Une délégation en
       criture indique que le client sera prévenu des tentatives  de  lecture
       ou d’écriture.

       Les serveurs offrent les délégations de fichier sitôt qu’un fichier est
       ouvert et peuvent annuler ces  délégations  n’importe  quand  dès  lors
       qu’un  autre client désire accéder à un fichier d’une manière qui entre
       en conflit avec les délégations déjà  attribuées.  Les  délégations  de
       répertoires ne sont pas gérées.

       Afin de pouvoir gérer les alertes de délégations (callback), le serveur
       vérifie le chemin retour vers le client au moment du contact initial de
       celui-ci.  Si  le  retour  vers  le  client ne peut pas être établi, le
       serveur n’attribue  purement  et  simplement  aucune  délégation  à  ce
       client.

CONSIDÉRATIONS DE SÉCURITÉ.

       Les serveurs NFS contrôlent l’accès aux données des fichiers, mais leur
       offre de gestion de l’authentification des requêtes NFS dépend de  leur
       implémentation des RPC. Les contrôles d’accès NFS traditionnels singent
       les contrôles d’accès binaires standards offerts par  les  systèmes  de
       fichiers  locaux.  L’authentification  RPC  traditionnelle  utilise  un
       nombre pour représenter chaque utilisateur (normalement l’uid propre  à
       cet   utilisateur),  un  nombre  pour  représenter  le  groupe  de  cet
       utilisateur (le gid de l’utilisateur) et un ensemble  d’au  maximum  16
       nombres  de  groupes additionnels pour représenter les groupes auxquels
       cet utilisateur peut appartenir.

       Traditionnellement, les données du fichier et l’ID de l’utilisateur  ne
       sont  pas cryptées sur le réseau (en clair). Qui plus est, les versions
       2 et 3 de NFS utilisent des  protocoles  auxiliaires  séparés  pour  le
       montage,  le  verrouillage  et  le déverrouillage des fichiers, et pour
       renvoyer les valeurs de retour système des  clients  et  serveurs.  Ces
       protocoles auxiliaires n’utilisent pas d’authentification.

       En  plus  d’avoir  intégré  ces  deux  protocoles  auxiliaires  dans le
       protocole NFS principal, la version 4 de  NFS  offre  des  formes  plus
       avancées de contrôle d’accès, d’authentification, et de protection lors
       du transfert des données. La spécification  de  la  version  4  de  NFS
       requiert  les  ACLs  NFSv4,  l’authentification RPCGSS, et les diverses
       sécurités RPCGSS permettant le contrôle d’intégrité et le cryptage  via
       RPC.  Puisque  la  version  4  de NFS ajoute les fonctionnalités de ces
       protocoles au coeur du protocole NFS, les nouvelles caractéristiques de
       sécurité  s’appliquent  à  toutes  les  opérations  de  NFS  version 4,
       incluant donc le montage, le verrouillage des  fichiers,  et  ainsi  de
       suite.  L’authentification  RPCGSS  peut  aussi  être utilisée avec les
       versions 2 et 3 de NFS, mais ne protège pas les protocoles associés.

       L’option de montage sec indique que le  mode  de  sécurité  RPCGSS  est
       actif  sur  ce  point  de  montage  NFS. L’ajout de sec=krb5 fournit la
       preuve cryptée de l’identité de l’utilisateur pour chaque requête  RPC.
       Ce   dispositif   offre   une  vérification  forte  de  l’identité  des
       utilisateurs qui  accèdent  aux  données  du  serveur.  Notez  que  des
       configurations  supplémentaires  à  cet ajout de l’option de mount sont
       nécessaires pour activer la sécurité Kerberos.  Consultez  la  page  de
       manuel de rpc.gssd(8) pour plus de détails.

       Deux  dispositifs additionnels de la sécurité Kerberos sont supportés :
       krb5i et krb5p. Le dispositif de sécurité krb5i offre une  garantie  de
       cryptage  fort  contre la falsification des données pour chaque requête
       RPC. Le dispositif de sécurité krb5p crypte  chaque  requête  RPC  afin
       d’éviter  qu’elle  soit  exposée  pendant  son transfert sur le réseau.
       Toutefois, le cryptage ou la vérification de l’intégrité entraînent des
       baisses  de  performance.  La  gestion  similaire  d’autres  formes  de
       sécurités  par  cryptage  (telles  que  lipkey  ou  SPKM3)  sont  aussi
       disponibles.

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

   Using non-privileged source ports
       NFS  clients  usually communicate with NFS servers via network sockets.
       Each end of a socket is assigned a port value, which is simply a number
       between  1 and 65535 that distinguishes socket endpoints at the same IP
       address.  A socket is uniquely defined by a  tuple  that  includes  the
       transport protocol (TCP or UDP) and the port values and IP addresses of
       both endpoints.

       The NFS client can choose any source port value for  its  sockets,  but
       usually  chooses  a privileged port.  A privileged port is a port value
       less than 1024.  Only a process  with  root  privileges  may  create  a
       socket with a privileged source port.

       The exact range of privileged source ports that can be chosen is set by
       a pair of sysctls to avoid choosing a well-known port, such as the port
       used  by  ssh.  This means the number of source ports available for the
       NFS client, and therefore the number of socket connections that can  be
       used at the same time, is practically limited to only a few hundred.

       As  described above, the traditional default NFS authentication scheme,
       known as AUTH_SYS, relies on sending  local  UID  and  GID  numbers  to
       identify  users  making  NFS requests.  An NFS server assumes that if a
       connection comes from a privileged port, the UID and GID numbers in the
       NFS  requests  on  this  connection  have been verified by the client’s
       kernel or some other local authority.  This is an easy system to spoof,
       but on a trusted physical network between trusted hosts, it is entirely
       adequate.

       Roughly speaking, one socket is used for each NFS mount  point.   If  a
       client  could  use  non-privileged  source ports as well, the number of
       sockets allowed, and  thus  the  maximum  number  of  concurrent  mount
       points, would be much larger.

       Using  non-privileged  source  ports  may  compromise  server  security
       somewhat, since any user on AUTH_SYS mount points can now pretend to be
       any  other  when  making NFS requests.  Thus NFS servers do not support
       this by default.  They  explicitly  allow  it  usually  via  an  export
       option.

       To  retain  good  security  while  allowing  as  many  mount  points as
       possible, it is best to allow non-privileged client connections only if
       the  server  and  client  both  require  strong authentication, such as
       Kerberos.

   Montage à travers dun pare-feu
       Un pare-feu peut se trouver entre un client NFS et le serveur, ou alors
       le client ou le serveur peuvent bloquer certains de leurs propres ports
       grâce à des règles de filtrage IP. Il est toujours possible  de  monter
       un  serveur  NFS  à  travers  un  pare-feu,  bien que les mécanismes de
       découverte automatiques des  terminaisons  d’accès  (endpoints)  de  la
       commande  mount(8)  peuvent  ne  pas  fonctionner. Il vous faudra alors
       fournir des détails spécifiques à ces terminaisons d’accès  (endpoints)
       grâce aux options de mount.

       Les  serveurs NFS lancent habituellement un service (daemon) portmapper
       ou rpcbind pour annoncer aux clients les terminaisons  (endpoints)  des
       services. Les clients se servent du démon rpcbind pour déterminer :

              Le port réseau utilisé par chaque service basé sur les RPCs

              Le  protocole  de  transport utilisé par chaque service basé sur
              les RPCs

       Le démon rpcbind utilise un port bien  connu  (111)  afin  d’aider  les
       clients  à trouver la terminaison (endpoint) d’un service. Bien que NFS
       utilise souvent  un  numéro  de  port  standard  (2049),  des  services
       auxiliaires  tels que NLM peuvent choisir au hasard des numéros de port
       inutilisés.

       Les configurations habituelles des  pare-feux  bloquent  le  port  bien
       connu  de rpcbind. En l’absence du service rpcbind, l’administrateur du
       serveur définit un numéro de port pour les services liés à NFS afin que
       le pare-feu puisse permettre l’accès aux ports des services spécifiques
       NFS. Les administrateurs des clients pourront alors indiquer le  numéro
       du  port  du  service  mountd grâce à l’option mountport de la commande
       mount(8). Il peut être nécessaire d’imposer  l’utilisation  de  TCP  ou
       d’UDP si le pare-feu bloque l’un de ces transports.

   Désactiver le traitement des ACL (Access Control List).
       Solaris  permet  aux  clients  NFS  version 3 l’accès direct aux Access
       Control Lists (ACLs) POSIX stockés dans son système de fichiers  local.
       Ce  protocole  auxiliaire  propriétaire,  connu  sous le nom de NFSACL,
       offre un contrôle  d’accès  plus  riche  que  le  mode  binaire.  Linux
       implémente   ce   protocole   dans   un   but   de  compatibilité  avec
       l’implémentation NFS de Solaris. Cependant, le protocole  NFSACL  n’est
       jamais devenu une partie standard de la spécification NFS version 3.

       La  spécification  de  NFS  version  4  impose une nouvelle version des
       Access Control Lists qui sont sémantiquement plus riches que  les  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 mélange à la fois les ACLs POSIX
       et NFS version 4.

FICHIERS

       /etc/fstab     Table des systèmes de fichiers

BOGUES

       L’option générique remount n’est  pas  totalement  gérée.  Les  options
       génériques,  comme  rw  ou  ro  peuvent être modifiées grâce à l’option
       remount, mais les options spécifiques NFS ne sont  pas  toutes  gérées.
       Par  exemple,  le  transport  utilisé, ou la version NFS ne peuvent pas
       être changés par un remount. L’exécution d’un remount sur un système de
       fichiers  NFS  monté  avec  l’option  noac  peut avoir des conséquences
       inattendues. L’option noac est un mélange d’option générique,  de  sync
       et de l’option actimeo=0 spécifique à NFS.

       Le client NFS antérieur à 2.4.7 ne gérait pas NFS sur TCP.

       Le  client NFS antérieur à 2.4.20 utilisait une heuristique pour savoir
       si les données mémorisées d’un  fichier  (en  cache)  étaient  toujours
       valides  plutôt  qu’utiliser  la méthode standard de cohérence de cache
       close-to-open décrite ci-dessus.

       Depuis la version 2.4.22, Le client NFS utilise une estimation  RTT  de
       type  Van  Jacobsen  pour  définir  les  délais de dépassement de temps
       (timeout) lorsqu’il utilise NFS sur UDP.

       Le client NFS Linux antérieur à 2.6.0 ne gérait pas NFS version 4.

       Le client NFS antérieur à 2.6.8 n’utilisait les lectures  et  écritures
       synchrones   que  lorsque  les  réglages  de  rsize  et  wsize  étaient
       inférieurs à la taille des pages du système.

       Le client NFS Linux ne supporte toujours pas certaines caractéristiques
       optionnelles  du  protocole  NFS  version  4, tel que la négociation de
       sécurité, les soumissions de serveurs et les attributs nommés.

VOIR AUSSI

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

       RFC 768 concernant la spécification UDP.
       RFC 793 concernant la spécification TCP.
       RFC 1094 concernant la spécification de NFS version 2.
       RFC 1813 concernant la spécification de NFS version 3.
       RFC 1832 concernant la spécification XDR.
       RFC 1833 concernant la spécification RPC bind.
       RFC 2203 concernant la spécification du protocole de l’API GSS  RPCSEC.
       RFC 3530 concernant la spécification de NFS version 4.

TRADUCTION

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

                                2 novembre 2007