Provided by: manpages-fr-extra_20111118_all bug

NOM

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

SYNOPSIS

       /etc/fstab

DESCRIPTION

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

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

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

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

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

       Le  nom  du  serveur  peut  être  un nom d'hôte non qualifié, un nom de domaine pleinement
       qualifié (« fully qualified domain name »), une adresse IPv4, ou une adresse IPv6 entourée
       par  des  crochets.  Les  adresses  IPv6  de  liens locaux ou de sites locaux doivent être
       accompagnées d'un identifiant d'interface. Référez-vous à ipv6(7) pour des détails quant à
       l'écriture des adresse IPv6 brutes.

       Le champ fstype contient « nfs ». La valeur « nfs4 » est obsolète.

OPTIONS DE MONTAGE

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

   Options prises en charge par toutes les versions
       Les options suivantes peuvent être utilisées avec n'importe quelle version de NFS.

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

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

       timeo=n        Le  temps  en dixièmes de seconde où le client NFS attend une réponse avant
                      qu'il réessaie une requête NFS.

                      Pour NFS sur TCP, la valeur timeo est de 600 par défaut  (60 secondes).  Le
                      client  NFS effectue une progression linéaire : après chaque retransmission
                      la temporisation est augmentée de timeo jusqu'au maximum de 600 secondes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       acregmin=n     Durée minimale (en seconde) de  mémorisation  (cache)  des  attributs  d'un
                      fichier  normal  avant  leur actualisation depuis le serveur. La valeur par
                      défaut est de 3 secondes, si cette option n'est pas définie.

       acregmax=n     Durée maximale (en seconde) de  mémorisation  (cache)  des  attributs  d'un
                      fichier  normal  avant  leur actualisation depuis le serveur. La valeur par
                      défaut est de 60 secondes, si cette option n'est pas définie.

       acdirmin=n     Durée minimale (en seconde) de  mémorisation  (cache)  des  attributs  d'un
                      répertoire avant leur actualisation depuis le serveur. La valeur par défaut
                      est de 30 secondes, si cette option n'est pas définie.

       acdirmax=n     Durée maximale (en seconde) de  mémorisation  (cache)  des  attributs  d'un
                      répertoire avant leur actualisation depuis le serveur. La valeur par défaut
                      est de 60 secondes, si cette option n'est pas définie.

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

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

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

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

       retry=n        Durée, en minute, pendant  laquelle  le  montage  NFS  sera  tenté  par  la
                      commande  mount(8), en arrière-plan ou au premier plan, avant d'abandonner.
                      Si l'option n'est pas définie, la valeur par défaut pour  le  premier  plan
                      est  de  2 minutes,  et  celle pour l'arrière-plan est 10 000 minutes, soit
                      environ une semaine, à 80 minutes près. La commande mount(8) s'arrêtera dès
                      le premier échec si on lui passe la valeur 0.

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

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

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

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

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

                      Utiliser un port source non privilégié permet d'augmenter le nombre maximal
                      de points de montages permis par client, mais les serveurs NFS doivent être
                      configurés  pour permettre la connexion de clients par des ports source non
                      privilégiés.

                      Veuillez consulter la section CONSIDÉRATIONS DE SÉCURITÉ pour d'importantes
                      précisions.

       lookupcache=mode
                      Préciser  comment le noyau s'occupe du cache des entrées de répertoire pour
                      un point de montage donné. mode peut être all, none, pos ou positive. Cette
                      option est prise en charge par les noyaux 2.6.28 et suivants.

                      Le  client  NFS  Linux  garde  en cache tous les résultats des requêtes NFS
                      LOOKUP. Si le répertoire indiqué existe sur le serveur, le résultat renvoyé
                      est positif (« positive »), sinon c'est négatif (« negative »).

                      Si  cette  option  n'est  pas  précisée,  ou  si all est précisé, le client
                      suppose que les deux types d'entrées  (positif  ou  négatif)  du  cache  de
                      répertoire  sont valables jusqu'à ce que le cache de leur répertoire parent
                      expire.

                      Si pos ou positive est précisé, le client suppose que les entrées positives
                      sont  valables  jusqu'à  ce  que le cache de leur répertoire parent expire,
                      mais valide les entrées négatives avant qu'une application les utilise.

                      Si none est précisé, le client valide à nouveau les deux types d'entrées de
                      cache  de  répertoire  avant  qu'une  application puisse les utiliser. Cela
                      permet une détection rapide des fichiers qui ont été créés ou supprimés par
                      d'autres clients, mais peut avoir des répercussions sur ces applications et
                      les performances du serveur.

                      La partie COHÉRENCE DES DONNÉES  ET  DES  MÉTADONNÉES  contient  un  propos
                      détaillé sur ces échanges.

   Options pour les versions NFS 2 et 3 uniquement
       Utilisez  ces  options ainsi que les options de la sous-section précédente uniquement pour
       les systèmes de fichiers de type NFS version 2 et 3.

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

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

                      Chaque protocole de transport utilise différents réglages de retransmission
                      et  de timeo. Merci de vous référer à la description de ces deux options de
                      montage

                      En plus de contrôler la façon dont le client NFS transmet les  requêtes  au
                      serveur,  cette  option  de  mount  gère  aussi  la  façon dont la commande
                      mount(8) communique  avec  les  services  rpcbind  et  mountd  du  serveur.
                      Indiquer  un  id  réseau  qui utilise TCP entraîne l'utilisation de TCP par
                      tout le  trafic  passant  par  la  commande  mount(8)  ou  le  client  NFS.
                      Réciproquement,  indiquer  UDP  entraîne  l'utilisation  d'UDP  par tout le
                      trafic.

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

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

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

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

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

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

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

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

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

       mountproto=idreseau
                      Le nom et la famille du protocole de transport que le  client  NFS  utilise
                      pour  transmettre  ses requêtes au service mountd d'un serveur NFS quand il
                      lance cette requête de montage, puis quand il démontera ensuite ce montage.

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

                      Cette  option  peut  être  utilisée pour monter un serveur NFS à travers un
                      pare-feu qui bloque  des  transferts  spécifiques.  Utilisé  avec  l'option
                      proto, différents modes de transfert peuvent être choisis pour les requêtes
                      vers mountd et NFS. Si le serveur ne propose pas de service  pour  le  mode
                      indiqué, la requête de montage échoue.

                      Veuillez   consulter   la  section  MÉTHODES  DE  TRANSPORT  pour  plus  de
                      renseignements sur la manière dont l'option de montage mountproto interagit
                      avec l'option proto.

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

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

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

                      Des  versions  précédentes  de  NFS  ne  gèrent  pas   cette   négociation.
                      L'utilisation  de  cette  option  garantit  que pathconf(3) donnera bien la
                      longueur maximale aux applications pour ces versions.

       nfsvers=n      Le numéro de version du protocole NFS utilisé pour contacter le service NFS
                      du  serveur.  Si  le serveur ne gère pas la version demandée, la requête de
                      montage échoue. Si cette option n'est  pas  définie,  le  client  tente  de
                      trouver  une  version  adaptée  au  serveur,  en tentant successivement les
                      versions 4, 3 puis 2.

       vers=n         Cette option est  une  variante  pour  l'option  nfsvers,  compatible  avec
                      d'autres systèmes d'exploitation.

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

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

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

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

                      Les options  de  montage  intr/  nointr  sont  obsolètes  pour  des  noyaux
                      ultérieurs   au   2.6.25.  Seul  un  signal  de  terminaison  SIGKILL  peut
                      interrompre une opération NFS en cours sur ces  noyaux,  et,  si  précisée,
                      cette  option est ignorée pour assurer une compatibilité ascendante sur des
                      anciens noyaux.

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

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

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

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

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

       local_lock=mécanisme
                      Précise si le verrouillage local doit  être  utilisé  pour  les  mécanismes
                      flock,  POSIX, ou les deux. mechanism peut être all, flock, posix, or none.
                      Cette option est prise en charge par les noyaux 2.6.37 et suivants.

                      Le client Linux NFS fournit un moyen  de  poser  des  verrous  locaux.  Les
                      applications  peuvent donc verrouiller des fichiers, mais ces verrous n'ont
                      de portée que pour les applications qui tournent sur ce  même  client.  Les
                      applications distantes ne sont pas informées de ces verrous.

                      Si  cette  option  n'est  pas  précisée,  ou si none est précisé, le client
                      suppose que les verrous ne sont pas locaux.

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

                      Si  flock  est spécifié, le client suppose que seuls les verrous flock sont
                      locaux, et utilise le protocole NLM associé pour verrouiller  les  fichiers
                      quand les verrous POSIX sont utilisés.

                      Si posix est spécifié, le client suppose que les verrous POSIX sont locaux,
                      et utilise le protocole NLM associé pour verrouiller les fichiers quand les
                      verrous flock sont utilisés.

                      Pour supporter le comportement flock de façon semblable à celui des clients
                      NFS < 2.6.12, utiliser 'local_lock= flock'. Cette option est  requise  lors
                      de  l'exportation des montages NFS via Samba comme des cartes Windows Samba
                      partagé en mode verrouillé flock. Puisque les clients NFS > 2.6.12  utilise
                      flock en émulant les verrous POSIX, il y aura un conflit de verrous.

                      NOTE :   Quand   elles   sont   utilisées  ensemble,  l'option  de  montage
                      'local_lock' sera écrasée par l'option de montage 'nolock'/'lock'.

   Options pour NFS version 4 uniquement
       Utilisez ces options ainsi que les options de la première sous-section ci-dessus pour  les
       systèmes de fichiers de type NFS version 4 et plus récents.

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

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

                      Les serveurs NFS version 4 doivent prendre en charge  TCP,  donc  si  cette
                      option n'est pas précisée, le client NFS utilise le protocole TCP. Veuillez
                      vous référer à la section MÉTHODES DE TRANSPORT pour plus de détails.

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

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

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

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

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

                      Les  options  de  montage  intr/  nointr  sont  obsolètes  pour  des noyaux
                      ultérieurs  au  2.6.25.  Seul  un  signal  de  terminaison   SIGKILL   peut
                      interrompre  une  opération  NFS  en cours sur ces noyaux, et, si précisée,
                      cette option est ignorée pour assurer une compatibilité ascendante sur  des
                      anciens noyaux.

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

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

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

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

SYSTÈME DE FICHIERS DE TYPE nfs4

       Le  type  nfs4  de système de fichiers est une ancienne syntaxe précisant l'utilisation de
       NFSv4. Il peut toujours être utilisé avec  toutes  les  options  spécifiques  à  NFSv4,  à
       l'exception de l'option de montage nfsvers

FICHIER DE CONFIGURATION DU MONTAGE

       Si la commande de montage est configurée pour, toutes les options de montage décrites dans
       la section  précédente  peuvent  être  configurées  dans  le  fichier  /etc/nfsmount.conf.
       Référez-vous à nfsmount.conf(5) pour plus de détails.

EXEMPLES

       Pour  réaliser  le  montage d'un partage en NFS version 2, il faut préciser que le type du
       système de fichiers est nfs et indiquer l'option de montage nfsvers=2.  Pour  réaliser  un
       montage  en  NFS version 3, il faut préciser que le type du système de fichiers est nfs et
       indiquer l'option de montage nfsvers=3. Pour réaliser un montage en NFS version 4, il faut
       préciser que le type du système de fichiers est nfs, avec l'option de montage nfsver=4, ou
       demander le système de fichiers nfs4.

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

               serveur:/export /mnt  nfs   defaults                      0 0

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

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

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

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

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

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

       Cet exemple montre comment utiliser une adresse brute non locale IPv6.

               [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0

MÉTHODES DE TRANSPORT.

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

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

       Anciennement, les clients NFS se servaient uniquement du transport  UDP  pour  transmettre
       des  requêtes  aux  serveurs.  Bien  que  son implémentation soit simple, NFS sur UDP a de
       nombreuses  limitations  qui  l'empêchent  d'obtenir  de   bonnes   performances   et   un
       fonctionnement  fluide  dans  certains  environnements de déploiement courants. Un taux de
       paquets perdus même insignifiant entraîne la perte de requêtes  NFS  complètes.  On  règle
       alors  généralement  le  délai  de  dépassement (« timeout ») à une valeur inférieure à la
       seconde afin que les clients puissent récupérer rapidement en cas  de  requêtes  rejetées.
       Cela peut entraîner une surcharge du trafic réseau et du serveur.

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

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

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

   Utilisation de l'option de montage mountproto
       Cette section s'applique uniquement aux versions 2 et  3  du  protocole  mount  car  NFS 4
       n'utilise pas un protocole de montage séparé.

       Le  client  Linux  peut  utiliser  différents modes de transfert pour contacter le service
       rpcbind d'un serveur, son service mountd, son gestionnaire de verrou réseau (NLM)  et  son
       service  NFS. Le mode de transport utilisé par le client NFS de Linux pour chaque point de
       montage dépend des options passées à mount, qui incluent proto, mountproto udp et tcp.

       Le client envoie des notifications au  gestionnaire  réseau  de  statut  (NSM :  « network
       status manager ») via UDP, quel que soit le mode de transfert précisé. Il écoute cependant
       les notifications NSM du serveur à la fois sur UDP et TCP. Le protocole gérant la liste de
       contrôle  d'accès  à  NFS  (NFACL :  « nfs  access control list ») utilise le même mode de
       transfert que le service NFS principal.

       Si aucune option n'est précisée quant au mode de transfert, le client  NFS  Linux  utilise
       UDP  pour contacter le service mountd du server, et TCP pour contacter ses services NLM et
       NFS par défaut.

       Si le serveur ne gère pas ces modes de transfert pour ces services, la  commande  mount(8)
       essaye  de  trouver  quel mode est pris en charge par le serveur, et essaye une fois de se
       reconnecter avec ce mode. Si le serveur ne propose aucun mode géré par le  client  ou  est
       mal  configuré,  la  requête  de  montage échoue. Si l'option bg a été passée, la commande
       mount passe en arrière-plan et continue d'essayer la requête de montage demandée.

       Quand l'une des options proto, udp ou tcp est passée mais que mountproto ne l'est pas,  le
       mode  de  transfert  demandé  est  utilisé  à  la fois pour contacter le service mountd du
       serveur et ses services NLM et NFS.

       Si l'option mountproto est passée mais que ni proto, ni udp et ni tcp n'est  passée  alors
       le  mode demandé est utilisé pour la requête mount initiale, mais la commande mount essaye
       de découvrir quel mode de transfert est pris en charge pour le protocole NFS, et préférera
       TCP si les deux modes sont implémentés.

       Si  mountproto  et  proto  (ou udp ou tcp) sont passés en même temps, le mode de transport
       indiqué à l'option mountproto est utilisé pour la requête initiale de mountd, et  le  mode
       indiqué  à  proto  (ou  udp  ou  tcp)  est  utilisé pour NFS, quel que soit l'ordre de ces
       options. Le programme ne cherchera pas à trouver les services si ces options sont données.

       Si l'une des options proto, udp, tcp ou mountproto est passée plus  d'une  fois  dans  une
       même commande, alors la valeur retenue sera celle la plus à droite.

COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES

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

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

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

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

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

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

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

   Mettre en cache les entrées répertoires
       Le  client  NFS Linux garde en cache les résultats d'une requête NFS LOOKUP. Si la requête
       pointe sur un répertoire existant sur le serveur, le résultat sera noté positif. Sinon, si
       le  répertoire n'existe pas (c'est-à-dire si le serveur retourne ENOENT), le résultat sera
       noté négatif.

       Afin de détecter l'ajout ou la suppression de répertoires sur le serveur,  le  client  NFS
       Linux  regarde  la date de modification (« mtime ») du répertoire. Si le client détecte un
       changement dans cette date, le client supprime tous les résultats LOOKUP encore  en  cache
       concernant ce répertoire. Comme la date de modification est un attribut conservé en cache,
       il est possible qu'un peu de temps se passe avant que le client  remarque  le  changement.
       Référez-vous  aux descriptions des options de montage acdirmin, acdirmax et noac pour plus
       d'information quant à la manière dont le temps de modification est mis en cache.

       Mettre en cache les entrées des répertoires améliore les performances des applications qui
       ne  partagent  pas  de  fichiers  avec des applications sur un autre client. L'utilisation
       d'informations  en  cache  sur  des  répertoires,  cependant,  peut  interférer  avec  des
       applications  qui  tournent  simultanément sur de nombreux clients et qui doivent détecter
       rapidement la création ou la suppression de  fichiers.  L'option  de  montage  lookupcache
       permet de personnaliser certains comportements de mise en cache de répertoires.

       Avant  la  version 2.6.28 du noyau, le client NFS Linux cherchait uniquement les résultats
       de recherches positifs.  Cela  permettait  aux  applications  de  détecter  rapidement  de
       nouvelles  entrées  de  répertoires  créées  par d'autres clients, tout en fournissant une
       partie des bénéfices dus à la mise en cache. Si  une  application  dépend  de  cet  ancien
       comportement, vous pouvez utiliser l'option lookupcache=positive.

       Si  le client ignore son cache et valide toutes les requêtes de recherche avec le serveur,
       il peut alors détecter immédiatement toute création ou suppression de  répertoire  par  un
       autre client. Vous pouvez forcer ce comportement avec l'option lookupcache=none. L'absence
       de mise en cache des répertoires entraîne une augmentation du nombre de requêtes  NFS,  et
       donc  une  perte de performances. Empêcher la recherche sur le cache devrait permettre une
       moindre perte au niveau des performances que d'utiliser noac, et n'a aucun  effet  sur  la
       manière dont le client NFS met en cache les attributs d'un fichier.

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

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

              Une  application  met  à  jour  (« flush »)  les  données  d'un  fichier de manière
              explicite avec sync(2), msync(2) ou fsync(3).

              Une application ferme un fichier avec close(2).

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

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

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

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

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

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

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

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

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

   Les caractéristiques du cache de la version 4 de NFS.
       Le  comportement  du  cache  des  données et des métadonnées des clients NFS version 4 est
       identique à celui des précédentes versions. Toutefois, la  version 4  de  NFS  offre  deux
       nouveaux  dispositifs pour améliorer le comportement du cache : attributs de changement et
       délégation 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 délégation de fichier est un contrat qui lie un client NFS  version 4  et  le  serveur,
       offrant  temporairement  au client le traitement d'un fichier comme s'il était le seul à y
       accéder. Le serveur s'engage à prévenir le client (grâce  à  une  requête  de  rappel,  ou
       « callback ») si un autre client tente d'accéder à ce même fichier. Une fois qu'un fichier
       a été délégué à un client, ce client peut mémoriser (mettre en cache) les données  et  les
       métadonnées de ce fichier de façon agressive sans avoir à contacter le serveur.

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

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

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

CONSIDÉRATIONS DE SÉCURITÉ.

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

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

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

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

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

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

   Utiliser un port source non privilégié
       Le  client  NFS  communique  normalement  avec  le serveur par des tuyaux réseaux (network
       sockets). À chaque bout du tuyau est associé un port, qui est un simple nombre entre 1  et
       65535,  ce  qui  permet de distinguer des tuyaux pointant sur la même adresse IP. Un tuyau
       est identifié de manière unique par un n-uplet comprenant le protocole de passage (TCP  ou
       UDP) et les ports et adresses IP de chaque bout.

       Le  client NFS peut choisir n'importe quel port d'origine pour ses tuyaux, mais il choisit
       en général un port privilégié (c'est-à-dire avec une valeur inférieure à  1024).  Seul  un
       processus  tournant  avec des droits du superutilisateur peut créer un tuyau à partir d'un
       port privilégié.

       La fourchette des ports potentiellement choisis est configurée par une  paire  de  sysctls
       pour  éviter  l'utilisation  de  ports bien connus, tel celui de SSH. Cela signifie que le
       nombre de ports source potentiels pour le client NFS, et donc pour le nombre de connexions
       par tuyau disponible à un moment donné est en pratique de l'ordre d'une centaine.

       Comme  décrit  plus haut, le schéma d'authentification NFS traditionnel (connu sous le nom
       d'AUTH_SYS), compte sur l'envoi d'UID et de GID locaux pour identifier les utilisateurs  à
       l'origine  de requêtes. Un serveur NFS suppose que si une connexion provient d'un port non
       privilégié, les numéros UID et GID de la requête NFS ont déjà été vérifiés par le noyau du
       client ou tout autre programme système local. Ce système est facile à contourner, mais sur
       un réseau sécurisé d'ordinateurs de confiance, c'est parfaitement adapté.

       En gros, un tuyau est utilisé pour chaque point de montage NFS. Si un  client  peut  aussi
       utiliser  un  port source non privilégié, le nombre de tuyaux autorisés (et donc le nombre
       maximal de points de montages en parallèles) sera beaucoup plus important.

       Utiliser un port source non privilégié  peut  quelque  peu  compromettre  la  sécurité  du
       serveur, car n'importe quel utilisateur d'un point de montage sur AUTH_SYS peut maintenant
       se faire passer pour un autre comme source de la requête. C'est pourquoi les serveurs  NFS
       ne le prennent pas en charge par défaut. En règle générale, ils l'autorisent explicitement
       à l'aide d'une option de partage.

       Pour garder un bon niveau de sécurité tout en ouvrant un maximum de points de montages, il
       est  préférable d'autoriser les connexions clients sur un port non privilégié seulement si
       le serveur et le client utilisent  tous  deux  une  authentification  forte,  comme  celle
       fournie par Kerberos.

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

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

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

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

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

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

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

       La spécification de NFS version 4 impose une nouvelle version des Access Control Lists qui
       sont  sémantiquement  plus  riches que les ACL POSIX. Les ACL de NFS version 4 ne sont pas
       totalement compatibles avec les ACL POSIX. De ce fait, des traductions entre les deux sont
       obligatoires dans un environnement qui mélange à la fois les ACL POSIX et NFS version 4.

OPTION DE REMONTAGE

       Les options de montage générique comme rw et sync peuvent être modifiées par les points de
       montage utilisant l'option remount. Voir mount(8) pour plus d'information sur les  options
       génériques de montage.

       Sauf  quelques  exceptions,  les  options  spécifiques à NFS ne peuvent pas être modifiées
       pendant un remontage. Par example, le transport sous-jacent ou la version NFS  ne  peuvent
       pas être changés par un remontage.

       Effectuer  un remontage sur un système de fichiers NFS monté avec l'option noac peut avoir
       des conséquences inattendues. L'option noac est une combinaison de l'option générique sync
       et de l'option spécifique NFS actimeo=0.

   Démontage après remontage
       Pour  les  points  de  montage  qui  utilisent  NFS  versions 2  ou 3, la sous-commande de
       démontage NFS dépend de la connaissance de  l'ensemble  initial  des  options  de  montage
       utilisées  pour  effectuer l'opération MNT. Ces options sont stockées sur le disque par la
       sous-commande de montage NFS, et peuvent être effacées par un remontage.

       Afin de s'assurer que les options de montage enregistrées ne sont pas effacées  lors  d'un
       remontage,  il  faut  spécifier au remontage le répertoire de montage local, ou le serveur
       hôte et le chemin d'exportation, mais pas les deux. Par exemple,

            mount -o remount,ro /mnt

       fusionne l'option de montage ro avec les options  de  montage  déjà  enregistrées  sur  le
       disque pour le serveur NFS monté dans /mnt.

FICHIERS

       /etc/fstab     Table des systèmes de fichiers

BOGUES

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

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

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

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

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

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

VOIR AUSSI

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

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

TRADUCTION

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

                                         2 novembre 2007                                   NFS(5)