Provided by: manpages-fr-extra_20111118_all bug

NOM

       exports - Liste des répertoires partagés par le serveur NFS

DESCRIPTION

       Le  fichier /etc/exports du serveur NFS contient une liste des systèmes de fichiers locaux
       accessibles  pour  les  clients  NFS.  Le  contenu  de  ce  fichier   est   maintenu   par
       l'administrateur système.

       Chaque  système  de  fichiers dans cette liste est suivi d'une liste d'options et d'une de
       contrôle d'accès. La liste est utilisée par exportfs(8) pour renseigner mountd(8).

       Le format de ce fichier est similaire à celui du fichier exports de  SunOS.  Chaque  ligne
       est composée d'un point de montage à partager, suivi d'une liste (aux éléments séparés par
       des espaces) de clients autorisés à monter le système  de  fichiers  situé  en  ce  point.
       Chaque client de la liste peut être immédiatement suivi par une liste d'options de partage
       pour ce client (entre parenthèses, les éléments étant séparés par  des  virgules).  Aucune
       espace n'est tolérée entre un nom de client et sa liste d'options.

       En outre, chaque ligne peut définir (après le nom du chemin) la valeur par défaut d'une ou
       plusieurs options, sous forme de tiret (« - »)  suivi  d'une  liste  d'options.  La  liste
       d'options est employée pour tous les partages qui suivent, sur cette ligne seulement.

       Les  lignes  blanches sont ignorées. Un « # » indique un commentaire s'étendant jusqu'à la
       fin de la ligne. Les entrées peuvent s'étendre sur plusieurs lignes en utilisant la  barre
       oblique  inverse  (antislash).  Si  un  nom  de partage contient des espaces, il doit être
       protégé par des apostrophes doubles « " ». Vous pouvez aussi  utiliser  la  barre  oblique
       inverse  (antislash)  suivi  du  code  octal à trois chiffres pour protéger tout espace ou
       autre caractère inhabituel dans un nom de partage.

       Pour que soient prises en compte vos modifications sur ce  fichier,  vous  devez  exécuter
       exportfs -ra ou redémarrer le serveur NFS.

   Formats des noms de machine
       Les clients NFS peuvent être indiqués de plusieurs façons :

       Une machine seule
              Vous  pouvez  indiquer  un hôte, soit par un nom abrégé reconnu par le mécanisme de
              résolution, soit par le nom de domaine pleinement qualifié, soit  par  une  adresse
              IPv4,  ou  soit  par  une adresse IPV6. Les adresses IPv6 ne doivent pas être entre
              crochets dans /etc/exports pour ne pas être confondues avec les  caractères  jokers
              de classe correspondants.

       Réseaux IP
              Il  est  aussi  possible  de partager des répertoires avec toutes les machines d'un
              (sous) réseau IP. Il suffit d'indiquer une paire adresse  IP  /  masque  de  réseau
              (adresse/masque),  en  utilisant le format décimal pointé, ou la longueur du masque
              CIDR. On peut donc ajouter soit « /255.255.252.0 » soit « /22 » à l'adresse IPv4 du
              réseau  pour  obtenir  un  sous-réseau  avec  10 bits  pour  la partie machine. Les
              adresses IPv6 doivent utiliser une longueur de masque contiguës et ne  doivent  pas
              être  à  l'intérieur  des  crochets pour éviter la confusion avec les caractères de
              classe jokers. En général, les caractères  jokers  ne  fonctionnent  pas  avec  les
              adresses IP, bien que cela arrive accidentellement quand les recherches inverses de
              DNS (« reverse DNS lookups ») échouent.

       Caractères jokers
              Les noms de machine peuvent contenir les caractères  jokers  *  et  ?,  ou  peuvent
              contenir  des  listes de classes de caractères entre [crochets]. Cela sert à rendre
              le fichier exports plus compact. Par  exemple,  *.cs.toto.edu  indique  toutes  les
              machines  du  domaine  cs.toto.edu.  Puisque les jokers peuvent aussi remplacer les
              points dans un nom de domaine, ce motif  correspondra  aussi  à  toute  machine  de
              n'importe quel sous-domaine de cs.toto.edu.

       Groupes de machines
              Les  groupes  de  machines NIS peuvent être utilisés (tels que @group). Seul le nom
              court de machine de chacun des membres du groupe est utilisé pour la  vérification.
              Les noms de machines vides, ou ceux contenant un simple tiret (-) sont ignorés.

       Anonymement
              Ceci  est spécifié par un simple caractère * ( ne pas le confondre avec le wildcard
              entré précédemment) qui correspondra à tous les clients.

       Si un client correspond à  plusieurs  des  configurations  ci-dessus,  alors  la  première
       correspondance  dans  l'ordre  de  la  liste  ci-dessus  a la priorité - indépendamment de
       l'ordre d'apparition sur la ligne d'exportation. Toutefois, si un client correspond à plus
       d'une  spécification  (par  exemple deux groupes réseau), alors la première correspondance
       dans l'ordre d'apparition sur la ligne d'exportation a la priorité.

   Sécurité RPCSEC_GSS
       Il  est  possible  d'utiliser  les  chaînes  spéciales  « gss/krb5 »,  « gss/krb5i »,   ou
       « gss/krb5p »  pour  n'accepter  que  les  clients  qui  utilisent la sécurité rpcsec_gss.
       Toutefois, cette syntaxe est obsolète, et sur les noyaux Linux 2.6.23  et  supérieurs,  il
       faut plutôt utiliser l'option de partage « sec= ».

       sec=   L'option  sec=,  suivie  d'une  liste  de  niveaux  de  sécurité (délimités par des
              virgules), limite le partage aux clients qui utilisent cette sécurité. Les  niveaux
              de  sécurité  disponibles  sont  sys (pas de sécurité cryptographique, par défaut),
              krb5 (authentification seulement),  krb5i  (protection  de  l'intégrité)  et  krb5p
              (protection  de  la confidentialité). En ce qui concerne la négociation des niveaux
              de sécurité, l'ordre est important ; et les niveaux préférés doivent être listés en
              premier.  La  position  de  l'option  sec=  par  rapport aux autres options n'a pas
              d'influence, sauf si ces options  s'appliquent  différemment  selon  le  niveau  de
              sécurité. Dans ce cas, il faudra utiliser de multiples options sec=, et les options
              qui suivent ne s'appliqueront alors qu'à ce niveau de sécurité. Les seules  options
              utilisables  dans  ce  cas  de  figure sont ro, rw, no_root_squash, root_squash, et
              all_squash.

   Options générales
       exportfs accepte les options de partage suivantes :

       secure Cette option impose l'utilisation d'un port réservé (« IPPORT_RESERVED », inférieur
              à  1024)  comme origine de la requête. Cette option est activée par défaut. Pour la
              désactiver, utilisez insecure.

       rw     Permettre les requêtes en lecture et en écriture sur le volume NFS. Le comportement
              par  défaut  est  d'interdire toute requête qui modifierait le système de fichiers,
              mais on peut aussi l'indiquer avec l'option ro.

       async  Permettre au serveur NFS de transgresser le protocole NFS en répondant aux requêtes
              avant  que  tous  les  changements  impliqués  par  la requête en cours n'aient été
              effectués sur le support réel (par exemple, le disque dur).

              L'utilisation de cette option  améliore  généralement  les  performances,  mais  au
              risque  de  perdre  ou  de  corrompre des données en cas de redémarrage brutal d'un
              serveur, suite à un plantage par exemple.

       sync   Ne répondre aux requêtes qu'après  l'exécution  de  tous  les  changements  sur  le
              support réel (voir async plus haut).

              Dans  toutes  les  versions  de  nfs-utils  jusqu'à la 1.0.0 (incluse), async était
              l'option par défaut. Dans toutes les versions postérieures à 1.0.0, le comportement
              par  défaut  est  sync,  et  async doit être explicitement indiquée si vous en avez
              besoin. Afin d'aider les  administrateurs  systèmes  à  prêter  attention  à  cette
              modification,  exportfs affichera un message d'avertissement si ni sync ni async ne
              sont précisées.

       no_wdelay
              Cette option est sans effet si async est déjà active. Le serveur NFS va normalement
              retarder  une  requête  d'écriture sur disque s'il suspecte qu'une autre requête en
              écriture liée à celle-ci est en cours ou  peut  survenir  rapidement.  Cela  permet
              l'exécution  de  plusieurs requêtes d'écriture en une seule passe sur le disque, ce
              qui peut améliorer  les  performances.  En  revanche,  si  un  serveur  NFS  reçoit
              principalement  des petites requêtes indépendantes, ce comportement peut réellement
              diminuer les performances. no_wdelay permet de désactiver  cette  option.  On  peut
              explicitement forcer ce comportement par défaut en utilisant l'option wdelay.

       nohide Cette  option  est  basée  sur  l'option  de  même  nom fournie dans le NFS d'IRIX.
              Normalement, si un serveur partage deux systèmes de fichiers dont un est monté  sur
              l'autre,  le  client  devra explicitement monter les deux systèmes de fichiers pour
              obtenir l'accès complet. S'il ne monte que le parent, il verra un répertoire vide à
              l'endroit  où  l'autre  système  de  fichiers est monté. Ce système de fichiers est
              « caché ».

              Définir l'option nohide sur un système de fichiers empêchera de le cacher, et  tout
              client  convenablement  autorisé  pourra  alors  se déplacer du système de fichiers
              parent à celui-ci sans s'en apercevoir.

              Cependant, quelques clients NFS ne sont pas adaptés à cette situation. Il est alors
              possible,  par  exemple, que deux fichiers d'un système de fichiers vu comme unique
              aient le même numéro d'inœud.

              L'option nohide ne concerne actuellement que les partages  vers  les  hôtes  seuls.
              Elle ne fonctionne pas de manière fiable avec les groupes de machines, sous-réseaux
              et ceux utilisant les caractères jokers.

              Cette option peut être très  pratique  dans  certains  cas,  mais  elle  doit  être
              utilisée avec parcimonie, et seulement après vérification de la capacité du système
              client à bien gérer cette situation.

              Cette option peut être désactivée explicitement avec hide.

       crossmnt
              Cette option est semblable à nohide mais elle permet aux clients de se déplacer  du
              système  de  fichiers  marqué  crossmnt  aux  systèmes  de fichiers partagés montés
              dessus. Ainsi, si un système de fichiers fils « B » est monté  sur  un  système  de
              fichiers  père  « A »,  définir  l'option crossmnt sur « A » aura le même effet que
              d'indiquer « nohide » sur « B ».

       no_subtree_check
              Cette  option  neutralise  la  vérification  de  sous-répertoires,  ce  qui  a  des
              implications  subtiles  au  niveau de la sécurité, mais peut améliorer la fiabilité
              dans certains cas.

              Si un sous-répertoire d'un système de fichiers est partagé, mais que le système  de
              fichiers ne l'est pas, alors chaque fois qu'une requête NFS arrive, le serveur doit
              non seulement vérifier que le fichier  accédé  est  dans  le  système  de  fichiers
              approprié  (ce  qui  est facile), mais aussi qu'il est dans l'arborescence partagée
              (ce qui est plus compliqué). Cette vérification s'appelle subtree_check.

              Pour ce faire, le serveur doit ajouter quelques informations sur  l'emplacement  du
              fichier  dans  le  « filehandle » (descripteur de fichier) qui est donné au client.
              Cela peut poser problème lors d'accès à des fichiers renommés  alors  qu'un  client
              est  en  train  de  les  utiliser  (bien  que dans la plupart des cas simples, cela
              continuera à fonctionner).

              La vérification de sous-répertoires est également utilisée pour s'assurer  que  des
              fichiers situés dans des répertoires auxquels seul l'administrateur a accès ne sont
              consultables que si le système de fichiers est partagé avec l'option no_root_squash
              (voir  ci-dessous),  et  ce,  même  si les fichiers eux-mêmes offrent un accès plus
              généreux.

              D'une façon générale, un système de fichiers  des  répertoires  personnels  (« home
              directories »),  qui  est  normalement  partagé  à  sa  racine  et  qui va subir de
              multiples opérations de renommage de fichiers, devrait être partagé  sans  contrôle
              de sous-répertoires. Un système de fichiers principalement en lecture seule, et qui
              donc ne verra que peu de modifications de  noms  de  fichiers  (/usr  ou  /var  par
              exemple)  et  pour  lequel  des  sous-répertoires  pourront  être partagés, le sera
              probablement avec la vérification des sous-répertoires.

              On peut explicitement  forcer  ce  comportement  par  défaut  de  vérification  des
              sous-répertoires en indiquant l'option subtree_check.

              À   partir   de   la  version 1.1.0  de  nfs-utils,  le  réglage  par  défaut  sera
              no_subtree_check car la vérification des sous-répertoires  (subtree_checking)  pose
              souvent  plus  de problèmes qu'elle n'en résout. Si vous voulez vraiment activer la
              vérification des sous-répertoires, vous devez explicitement indiquer  cette  option
              dans  le  fichier  exports.  Si vous ne précisez rien, exportfs vous avertira de la
              modification.

       insecure_locks

       no_auth_nlm
              Cette option (les deux noms sont synonymes) indique au serveur NFS de ne pas exiger
              l'authentification des requêtes de verrouillage (c.-à-d. les requêtes qui utilisent
              le protocole NLM). Normalement le serveur de  NFS  doit  exiger  d'une  requête  de
              verrouillage qu'elle fournisse une accréditation pour un utilisateur qui a accès en
              lecture au fichier. Avec cette option, aucun contrôle d'accès ne sera effectué.

              Les premières implémentations de clients NFS n'envoyaient pas d'accréditations lors
              de  requêtes  de  verrouillage, et nombre de clients NFS encore utilisés sont basés
              sur ces anciennes implémentations. Utilisez cette option si vous constatez que vous
              ne pouvez verrouiller que les fichiers en lecture pour tous (« world readable »).

              Par  défaut,  les demandes d'authentifications des requêtes NLM se comportent comme
              si les options (synonymes !) auth_nlm ou secure_locks avaient été fournies. On peut
              cependant écrire explicitement ces options.

       no_acl Sur  certains  noyaux  spécialement  modifiés,  et  lors de partages de systèmes de
              fichiers implémentant les ACL, cette option indique à nfsd ne pas dévoiler les  ACL
              aux  clients,  ainsi  ils verront seulement un sous-ensemble de permissions réelles
              sur le système de fichiers donné. Cette  option  est  efficace  pour  des  partages
              utilisés  par  les  clients  NFSv2  et les anciens clients NFSv3 qui effectuent des
              vérifications d'accès localement. Les clients NFSv3 actuels  utilisent  l'appel  de
              procédure   distante   ACCESS   (« ACCESS   RPC »)   afin  d'effectuer  toutes  les
              vérifications d'accès sur le serveur. Notez que l'option no_acl n'a d'effet que sur
              des  noyaux  spécifiquement modifiés pour le gérer, et seulement lors du partage de
              systèmes de fichiers implémentant les ACL. Par défaut, le  partage  implémente  les
              ACL (c.-à-d. par défaut, no_acl est désactivée).

       mountpoint=chemin

       mp     Cette  option  permet  de ne partager un répertoire que si son montage a réussi. Si
              aucun chemin n'est précisé (par exemple mountpoint ou mp)  alors  le  partage  doit
              également  être un point de montage. Si ce n'est pas le cas, alors le partage n'est
              pas fait. Ceci vous permet d'être sûr que le répertoire d'un point  de  montage  ne
              sera jamais partagé par accident si, par exemple, le montage du système de fichiers
              échouait suite à une erreur de disque dur.

              Si un chemin est précisé (c.-à-d.  mountpoint=/chemin  ou  mp=/chemin),  le  chemin
              indiqué doit être un point de montage pour le partage qui est fait.

       fsid=num|root|uuid
              NFS  a  besoin  de  reconnaître  chaque système de fichiers qu'il offre en partage.
              Habituellement, il utilisera un UUID pour ce système de fichiers (si le système  de
              fichiers  en dispose) ou de l'identifiant du périphérique qui héberge ce système de
              fichiers (si le système de fichiers est stocké sur un périphérique).

              Puisque tous les systèmes  de  fichiers  ne  sont  pas  toujours  stockés  sur  des
              périphériques,  et  qu'ils  n'ont  pas toujours un UUID, il sera parfois nécessaire
              d'indiquer comment NFS identifiera  un  système  de  fichiers.  C'est  le  rôle  de
              l'option fsid=.

              Dans  NFSv4,  un système de fichiers particulier est la racine de tous les systèmes
              de fichiers partagés. Il est défini par fsid=root ou fsid=0, qui veulent tous  deux
              dire exactement la même chose.

              Les autres systèmes de fichiers peuvent être identifiés avec un entier court, ou un
              UUID qui doit comporter 32 caractères hexadécimaux et une ponctuation arbitraire.

              Les versions du noyau Linux 2.6.20 et précédentes ne comprennent pas  les  réglages
              UUID,  l'utilisation  d'un  entier  court est donc nécessaire pour définir l'option
              fsid. La définition conjointe d'un petit nombre et d'un UUID est possible pour  une
              même  configuration,  ce  qui  rend  possible  l'utilisation  avec  d'anciens ou de
              nouveaux noyaux.

       refer=chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]
              Un client qui se connecte à ce partage se  verra  proposer  le  choix  d'une  autre
              adresse de système de fichiers parmi celles fournies dans cette liste (Notez que le
              serveur doit absolument avoir un point de montage sur cette destination, bien qu'il
              ne  soit  pas  nécessaire qu'il s'agisse d'un système de fichiers différent. Ainsi,
              mount --bind /chemin /chemin suffit).

       replicas=chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]
              Si le client demande d'autres adresses pour ce partage, cette liste de possibilités
              lui  sera  proposée  (Notez  que le mécanisme effectif de réplication du système de
              fichiers doit être géré ailleurs).

   Correspondance d'ID utilisateur  User ID Mapping »)
       nfsd base son contrôle d'accès aux fichiers de la machine serveur  sur  l'UID  et  le  GID
       fournis  dans chaque requête RPC de NFS. Le comportement attendu par un utilisateur est de
       pouvoir accéder à ses fichiers sur le serveur de la même  façon  qu'il  y  accède  sur  un
       système  de  fichiers  normal.  Ceci exige que les mêmes UID et GID soient utilisés sur le
       client et la machine serveur. Ce n'est pas toujours vrai, ni toujours souhaitable.

       Bien souvent, il n'est pas souhaitable que l'administrateur  d'une  machine  cliente  soit
       également  traité comme le superutilisateur lors de l'accès à des fichiers du serveur NFS.
       À cet effet, l'UID 0 est normalement transformé (« mapped ») en utilisateur différent : le
       prétendu  utilisateur  anonyme  ou  UID nobody. C'est le mode de fonctionnement par défaut
       (appelé « root squashing »), qui peut être désactivé grâce à no_root_squash.

       Par défaut, exportfs choisit un UID et un  GID  de  65534  pour  l'accès  « squash ».  Ces
       valeurs  peuvent  également  être définies par les options anonuid et anongid. Enfin, vous
       pouvez faire correspondre toutes les demandes  des  utilisateurs  avec  l'UID  anonyme  en
       indiquant l'option all_squash.

       Voici la liste complète des options de correspondance (« mapping ») :

       root_squash
              Transformer  les  requêtes  d'UID/GID  0  en  l'UID/GID  anonyme. Notez que ceci ne
              s'applique à aucun autre UID ou GID qui pourrait également être sensible,  tel  que
              l'utilisateur bin ou le groupe staff par exemple.

       no_root_squash
              Désactiver  la  transformation du superutilisateur. Cette option est principalement
              utile pour les clients sans disque dur.

       all_squash
              Transformer tous les UID/GID en l'utilisateur anonyme. Utile pour  les  répertoires
              FTP  publics  partagés  en  NFS,  les  répertoires  de spool de news, etc. L'option
              inverse est no_all_squash, qui est celle par défaut.

       anonuid et anongid
              Ces options définissent explicitement l'UID et le  GID  du  compte  anonyme.  Cette
              option  est  principalement  utile  pour  des  clients  PC/NFS, dans le cas où vous
              souhaiteriez  que  toutes  les  requêtes  semblent  provenir  d'un  seul  et   même
              utilisateur.  Consultez  par exemple la ligne définissant le partage pour /home/joe
              dans  la  section  EXEMPLES  ci-dessous,  qui  attribue  toutes  les   requêtes   à
              l'utilisateur 150 (qui est censé être celui de l'utilisateur Joe).

   Tables d'exportation supplémentaire
       Après  avoir  lu  /etc/exports,  exportfs  lit  les fichiers dans le répertoire des tables
       d'exportation supplémentaires /etc/exports.d.. exportfs concerne seulement un fichier dont
       le  nom  se  termine  par  .  exports  et  qui  ne  commence  pas  par  . comme un fichier
       d'exportation supplémentaire. Un fichier dont le nom ne satisfait pas  à  cette  condition
       est  simplement  ignoré. Le format des tables d'exportation supplémentaire est le même que
       /etc/exports.

EXEMPLES

       # exemple de fichier /etc/exports
       /               master(rw) trusty(rw,no_root_squash)
       /projects       proj*.local.domain(rw)
       /usr            *.local.domain(ro) @trusted(rw)
       /home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
       /pub            *(ro,insecure,all_squash)
       /srv/www        -sync,rw server @trusted @external(ro)
       /foo            2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
       /build          buildhost[0-9].local.domain(rw)

       La première ligne partage l'ensemble du système de fichiers vers les  machines  « master »
       et  « trusty ».  En  plus des droits d'écriture, toute transformation d'UID est désactivée
       pour l'hôte « trusty ». Les deuxième et troisième lignes montrent des exemples de noms  de
       machines   avec   caractères  jokers,  et  de  groupes  de  machines  (c'est  le  sens  de
       « @trusted »). La quatrième ligne montre une entrée pour le client PC/NFS,  présenté  plus
       haut.  La  cinquième ligne partage un répertoire public de FTP, à toutes les machines dans
       le monde, en effectuant les requêtes sous le  compte  anonyme.  L'option  insecure  permet
       l'accès  aux  clients  dont l'implémentation NFS n'utilise pas un port réservé. La sixième
       ligne partage un répertoire en lecture et écriture à une machine « server » ainsi qu'à  un
       groupe  de  machines  « @trusted »,  et  en  lecture  seule  pour  le  groupe  de machines
       « @external », tous les trois ayant l'option « sync » activée. La septième  ligne  partage
       un répertoire aux deux sous-réseaux IPv6 et IPv4. La huitième ligne montre une utilisation
       d'un caractère joker de classe.

FICHIERS

       /etc/exports /etc/exports.d

VOIR AUSSI

       exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8).

TRADUCTION

       Cette page de manuel a été traduite et 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> depuis 2006. Veuillez signaler toute erreur de traduction par  un  rapport
       de bogue sur le paquet manpages-fr-extra.

                                         31 décembre 2009                              exports(5)