Provided by: manpages-fr_4.13-4_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 liste
       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.

       To apply changes to this file, run exportfs -ra or restart the NFS server.

   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 de
              classe jokers 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.

              The option can be explicitly disabled for NFSv2 and NFSv3 with hide.

              This  option  is  not  relevant  when  NFSv4  is use. NFSv4 never hides subordinate
              filesystems. Any filesystem that is exported will be visible  where  expected  when
              using NFSv4.

       crossmnt
              This option is similar to nohide but it makes it possible for clients to access all
              filesystems mounted on a  filesystem  marked  with  crossmnt.  Thus  when  a  child
              filesystem  "B"  is  mounted on a parent "A", setting crossmnt on "A" has a similar
              effect to setting "nohide" on B.

              With nohide the child filesystem needs to be explicitly exported. With crossmnt  it
              need not. If a child of a crossmnt file is not explicitly exported, then it will be
              implicitly exported with the same export options as the parent, except  for  fsid=.
              This  makes  it  impossible to not export a child of a crossmnt filesystem. If some
              but not all subordinate filesystems of a parent are to be exported, then they  must
              be explicitly exported and the parent should not have crossmnt set.

              The nocrossmnt option can explictly disable crossmnt if it was previously set. This
              is rarely useful.

       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'authentification 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.

       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.

       nordirplus
              This option will  disable  READDIRPLUS  request  handling.  When  set,  READDIRPLUS
              requests from NFS clients return NFS3ERR_NOTSUPP, and clients fall back on READDIR.
              This option affects only NFSv3 clients.

       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).

       pnfs   This option allows enables the use of pNFS extension if protocol level  is  NFSv4.1
              or  higher,  and the filesystem supports pNFS exports. With pNFS clients can bypass
              the server and perform  I/O  directly  to  storage  devices.  The  default  can  be
              explicitly requested with the no_pnfs option.

   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
       After reading /etc/exports exportfs reads files in the /etc/exports.d directory  as  extra
       export  tables.  Only  files ending in .exports are considered. Files beginning with a dot
       are ignored. The format for extra export tables is the same as /etc/exports

EXEMPLE

       # 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

       La  traduction  française  de  cette  page  de  manuel  a  été  créée  par  Valéry  Perrin
       <valery.perrin.debian@free.fr>,   Sylvain   Cherrier   <sylvain.cherrier@free.fr>,  Thomas
       Huriaux <thomas.huriaux@gmail.com>, Dominique Simen <dominiquesimen@hotmail.com>,  Nicolas
       Sauzède    <nsauzede@free.fr>,    Romain    Doumenc   <rd6137@gmail.com>,   David   Prévot
       <david@tilapin.org>,   Denis   Mugnier    <myou72@orange.fr>    et    Cédric    Boutillier
       <cedric.boutillier@gmail.com>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General
       Public  License  version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à debian-l10n-french@lists.debian.org ⟨⟩.

                                         31 décembre 2009                              exports(5)