Provided by: manpages-fr-extra_20080921_all bug

NOM

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

SYNOPSIS

       /etc/fstab

DESCRIPTION

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

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

       Dans le cas des montages de systèmes de fichiers NFS, une ligne dans le
       fichier /etc/fstab indique le nom du serveur, le chemin  du  répertoire
       partagé  à monter, le répertoire local qui sera le point de montage, le
       type de système de fichiers à monter et la liste des options de montage
       qui  indique  la  façon  dont  le  système de fichiers sera monté et 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.

   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=netid    Protocole de transport utilisé par le  client  NFS  pour
                      transmettre  les  requêtes aux serveur NFS pour ce point
                      de montage. netid peut être soit udp soit tcp. Chacun de
                      ces  protocoles de transport 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.

       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.

       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=netid    Protocole de transport utilisé par le client NFS pour la
                      transmission des requêtes au serveur NFS pour  ce  point
                      de  montage.  netid  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.

       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.

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.

   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), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)

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

TRADUCTION

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

                                2 novembre 2007                         NFS(5)