Provided by: manpages-fr-extra_20101103_all bug

NOM

       exports - Systemes de fichiers a partager (pour NFS en mode noyau)

SYNOPSIS

       /etc/exports

DESCRIPTION

       Le  fichier  /etc/exports  sert  de  liste de controle d'acces pour les
       systemes de fichiers a partager avec les clients NFS.  Il  est  utilise
       par exportfs(8) pour informer mountd(8) et le demon serveur NFS en mode
       noyau nfsd(8).

       Le format de ce fichier est similaire a celui  du  fichier  exports  de
       SunOS.  Chaque  ligne  est  composee  d'un point de montage a partager,
       suivi d'une liste (aux elements separes par  des  espaces)  de  clients
       autorises  a  monter  le  systeme de fichiers situe en ce point. Chaque
       client de  la  liste  peut  etre  immediatement  suivi  par  une  liste
       d'options  de  partage  pour ce client (entre parentheses, les elements
       etant separes par des virgules). Aucune espace n'est toleree  entre  un
       nom de client et sa liste d'options.

       En  outre, chaque ligne peut definir (apres le nom du chemin) la valeur
       par defaut d'une ou plusieurs options, sous forme  de  tiret  (<< - >>)
       suivi  d'une liste d'options. La liste d'options est employee pour tous
       les partages qui suivent, sur cette ligne seulement.

       Les lignes blanches sont ignorees. Un << # >>  indique  un  commentaire
       s'etendant  jusqu'a  la  fin de la ligne. Les entrees peuvent s'etendre
       sur plusieurs lignes en utilisant la barre oblique inverse (antislash).
       Si un nom de partage contient des espaces, il doit etre protege par des
       apostrophes doubles  << " >>.  Vous  pouvez  aussi  utiliser  la  barre
       oblique  inverse  (antislash) suivi du code octal a trois chiffres pour
       proteger tout espace ou autre  caractere  inhabituel  dans  un  nom  de
       partage.

       Pour que soient prises en compte vos modifications sur ce fichier, vous
       devez executer << exportfs -ra >> ou redemarrer le serveur NFS.

   Formats des noms de machine
       Les clients NFS peuvent etre indiques de plusieurs facons :

       Une machine seule
              C'est le format le plus courant. Vous pouvez  indiquer  un  hote
              par son nom abrege reconnu par votre solveur de nom, par son nom
              de domaine complet, ou par son adresse IP.

       Groupes de machines
              Les groupes de machines NIS  peuvent  etre  utilises  (tels  que
              @group).  Seul  le nom court de machine de chacun des membres du
              groupe est utilise pour la verification. Les  noms  de  machines
              vides, ou ceux contenant un simple tiret (-) sont ignores.

       Caracteres jokers
              Les  noms de machine peuvent contenir les caracteres jokers * et
              ?. Cela sert a 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 a
              toute machine de n'importe quel sous-domaine de cs.toto.edu.

       Reseaux IP
              Il est aussi possible de partager des  repertoires  avec  toutes
              les  machines  d'un  (sous)  reseau IP. Il suffit d'indiquer une
              paire  adresse  IP  /  masque  de  reseau  (adresse/masque),  en
              utilisant  le  format  decimal  pointe, ou la longueur du masque
              CIDR  (on  peut  donc  ajouter  soit  << /255.255.252.0 >>  soit
              << /22 >> a l'adresse du reseau pour obtenir un sous reseau avec
              10 bits pour la partie  machine).  En  general,  les  caracteres
              jokers  ne  fonctionnent pas avec les adresses IP, bien que cela
              arrive accidentellement quand les  recherches  inverses  de  DNS
              (<< reverse DNS lookups >>) echouent.

   S'ecurit'e RPCSEC_GSS
       Il  est  possible  d'utiliser  les  chaines  speciales  << gss/krb5 >>,
       << gss/krb5i >>, ou << gss/krb5p >> pour n'accepter que les clients qui
       utilisent   la   securite  rpcsec_gss.  Toutefois,  cette  syntaxe  est
       obsolete, et sur les noyaux Linux 2.6.23 et superieurs, il faut  plutot
       utiliser l'option de partage << sec= >>.

       sec=   L'option  sec=,  suivie  d'une  liste  de  niveaux  de  securite
              (delimites par des virgules), limite le partage aux clients  qui
              utilisent  cette  securite.  Les niveaux de securite disponibles
              sont sys (pas de securite  cryptographique,  par  defaut),  krb5
              (authentification  seulement), krb5i (protection de l'integrite)
              et krb5p (protection de la confidentialite). En ce qui  concerne
              la  negociation des niveaux de securite, l'ordre est important ;
              et les niveaux preferes  doivent  etre  listes  en  premier.  La
              position de l'option sec= par rapport aux autres options n'a pas
              d'influence, sauf si ces options s'appliquent differemment selon
              le  niveau  de  securite.  Dans  ce  cas,  il faudra utiliser de
              multiples  options  sec=,  et  les  options   qui   suivent   ne
              s'appliqueront  alors  qu'a  ce  niveau  de securite. Les seules
              options  utilisables  dans  ce  cas  de  figure  sont  ro,   rw,
              no_root_squash, root_squash, et all_squash.

   Options g'en'erales
       exportfs accepte les options de partage suivantes :

       secure Cette    option   impose   l'utilisation   d'un   port   reserve
              (<< IPPORT_RESERVED >>, inferieur a 1024) comme  origine  de  la
              requete.   Cette   option   est  activee  par  defaut.  Pour  la
              desactiver, utilisez insecure.

       rw     Permettre les requetes en lecture et en ecriture sur  le  volume
              NFS.  Le  comportement  par defaut est d'interdire toute requete
              qui modifierait le systeme  de  fichiers,  mais  on  peut  aussi
              l'indiquer avec l'option ro.

       async  Permettre  au  serveur  NFS  de transgresser le protocole NFS en
              repondant aux requetes avant que tous les changements  impliques
              par  la  requete  en  cours n'aient ete effectues sur le support
              reel (par exemple, le disque dur).

              L'utilisation  de  cette  option   ameliore   generalement   les
              performances,  mais  au  risque  de  perdre  ou de corrompre des
              donnees en cas de redemarrage brutal d'un serveur,  suite  a  un
              plantage par exemple.

       sync   Ne  repondre  aux  requetes  qu'apres  l'execution  de  tous les
              changements sur le support reel (voir async plus haut).

              Dans  toutes  les  versions  de  nfs-utils  jusqu'a   la   1.0.0
              (incluse), c'etait l'option par defaut. Dans toutes les versions
              posterieures a 1.0.0, le comportement par defaut  est  sync,  et
              async  doit  etre explicitement indiquee si vous en avez besoin.
              Afin d'aider les administrateurs systemes a preter  attention  a
              cette    modification,    exportfs    affichera    un    message
              d'avertissement si ni sync ni async ne sont precisees.

       no_wdelay
              Cette option est sans effet si async est deja active. Le serveur
              NFS  va  normalement  retarder une requete d'ecriture sur disque
              s'il suspecte qu'une autre requete en ecriture liee  a  celle-ci
              est   en   cours   ou  peut  survenir  rapidement.  Cela  permet
              l'execution de plusieurs requetes d'ecriture en une seule  passe
              sur  le  disque,  ce  qui  peut  ameliorer  les performances. En
              revanche, si un serveur NFS recoit  principalement  des  petites
              requetes independantes, ce comportement peut reellement diminuer
              les performances. no_wdelay permet de desactiver  cette  option.
              On  peut  explicitement  specifier ce comportement par defaut en
              utilisant l'option wdelay.

       nohide Cette option est basee sur l'option de meme nom fournie dans  le
              NFS  d'IRIX. Normalement, si un serveur partage deux systemes de
              fichiers  dont  un  est  monte  sur  l'autre,  le  client  devra
              explicitement  monter les deux systemes de fichiers pour obtenir
              l'acces complet. S'il ne  monte  que  le  parent,  il  verra  un
              repertoire  vide  a l'endroit ou l'autre systeme de fichiers est
              monte. Ce systeme de fichiers est << cache >>.

              Definir l'option nohide sur un systeme de fichiers empechera  de
              le  cacher,  et tout client convenablement autorise pourra alors
              se deplacer du systeme de fichiers parent a celui-ci  sans  s'en
              apercevoir.

              Cependant,  quelques  clients  NFS  ne  sont pas adaptes a cette
              situation. Il est alors possible, par exemple, que deux fichiers
              d'un  systeme  de  fichier  vu comme unique aient le meme numero
              d'inoeud.

              L'option nohide ne concerne actuellement que les  partages  vers
              les  h^otes  seuls. Elle ne fonctionne pas de maniere fiable avec
              les groupes de machines,  sous-reseaux  et  ceux  utilisant  les
              caracteres jokers.

              Cette  option  peut  etre  tres pratique dans certains cas, mais
              elle doit etre utilisee  avec  parcimonie,  et  seulement  apres
              verification de la capacite du systeme client a bien gerer cette
              situation.

              Cette option peut etre desactivee explicitement avec hide.

       crossmnt
              Cette option est semblable a nohide mais elle permet aux clients
              de  se  deplacer  du  systeme  de  fichiers  marque crossmnt aux
              systemes de  fichiers  partages  montes  dessus.  Ainsi,  si  un
              systeme  de  fichiers  fils  << B >> est monte sur un systeme de
              fichiers pere << A >>, definir  l'option  crossmnt  sur  << A >>
              aura le meme effet que d'indiquer << nohide >> sur << B >>.

       no_subtree_check
              Cette  option neutralise la verification de sous-repertoires, ce
              qui a des implications subtiles au niveau de la  securite,  mais
              peut ameliorer la fiabilite dans certains cas.

              Si un sous-repertoire d'un systeme de fichiers est partage, mais
              que le systeme de fichiers  ne  l'est  pas,  alors  chaque  fois
              qu'une  requete  NFS  arrive,  le  serveur  doit  non  seulement
              verifier que le fichier accede est dans le systeme  de  fichiers
              approprie  (ce  qui  est  facile),  mais  aussi  qu'il  est dans
              l'arborescence partagee  (ce  qui  est  plus  complique).  Cette
              verification 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 donne au client. Cela peut poser probleme
              lors d'acces a des fichiers renommes alors qu'un client  est  en
              train de les utiliser (bien que dans la plupart des cas simples,
              cela continuera a fonctionner).

              La verification de sous-repertoires est egalement utilisee  pour
              s'assurer  que des fichiers situes dans des repertoires auxquels
              seul l'administrateur a acces ne sont  consultables  que  si  le
              systeme  de  fichiers  est  exporte avec l'option no_root_squash
              (voir ci-dessous), et ce, meme si les fichiers eux-memes offrent
              un acces plus genereux.

              D'une  facon  generale,  un  systeme de fichiers des repertoires
              personnels (<< home directories >>), qui est normalement partage
              a sa racine et qui va subir de multiples operations de renommage
              de   fichiers,   devrait   etre   partage   sans   controle   de
              sous-repertoires.  Un  systeme  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-repertoires pourront etre partages,  le  sera  probablement
              avec la verification des sous-repertoires.

              On  peut  explicitement  specifier ce comportement par defaut de
              verification  des   sous-repertoires   en   indiquant   l'option
              subtree_check.

              A partir de la version 1.1.0 de nfs-utils, le reglage par defaut
              sera no_subtree_check car la verification  des  sous-repertoires
              (subtree_checking)  pose  souvent plus de problemes qu'elle n'en
              resout. Si vous voulez  vraiment  activer  la  verification  des
              sous-repertoires,   vous  devez  explicitement  specifier  cette
              option dans le  fichier  exports.  Si  vous  ne  precisez  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  requetes   de
              verrouillage  (c.-a-d.  les  requetes qui utilisent le protocole
              NLM). Normalement le serveur de NFS doit exiger d'une requete de
              verrouillage   qu'elle   fournisse  une  accreditation  pour  un
              utilisateur qui a  acces  en  lecture  au  fichier.  Avec  cette
              option, aucun controle d'acces ne sera effectue.

              Les  premieres  implementations  de clients NFS n'envoyaient pas
              d'accreditations lors de requetes de verrouillage, et nombre  de
              clients  NFS  encore  utilises  sont  bases  sur  ces  anciennes
              implementations. Utilisez cette option  si  vous  constatez  que
              vous ne pouvez verrouiller que les fichiers en lecture pour tous
              (<< world readable >>).

              Par defaut, les demandes d'authentifications des requetes NLM se
              comportent  comme  si  les  options  (synonymes !)  auth_nlm  ou
              secure_locks avaient ete  fournies.  On  peut  cependant  ecrire
              explicitement ces options.

       no_acl Sur  certains  noyaux specialement modifies, et lors de partages
              de systemes de  fichiers  implementant  les  ACL,  cette  option
              indique  a  nfsd  ne pas devoiler les ACL aux clients, ainsi ils
              verront seulement un sous-ensemble de permissions reelles sur le
              systeme  de  fichiers  donne. Cette option est efficace pour des
              partages utilises par les clients NFSv2 et les  anciens  clients
              NFSv3  qui  effectuent des verifications d'acces localement. Les
              clients NFSv3 actuels utilisent l'appel  de  procedure  distante
              ACCESS   (<< ACCESS   RPC >>)   afin   d'effectuer   toutes  les
              verifications d'acces sur le serveur. Notez que l'option  no_acl
              n'a  d'effet  que sur des noyaux specifiquement modifies pour le
              gerer, et seulement lors du  partage  de  systemes  de  fichiers
              implementant  les ACL. Par defaut, le partage implemente les ACL
              (c.-a-d. par defaut, no_acl est desactivee).

       mountpoint=chemin

       mp     Cette option permet de ne partager  un  repertoire  que  si  son
              montage  a  reussi.  Si  aucun chemin n'est precise (par exemple
              mountpoint ou mp) alors le partage doit egalement etre un  point
              de  montage.  Si ce n'est pas le cas, alors le partage n'est pas
              fait. Ceci vous permet d'etre sur que le repertoire  d'un  point
              de  montage ne sera jamais partage par accident si, par exemple,
              le montage du systeme de fichiers echouait suite a une erreur de
              disque dur.

              Si   un   chemin  est  precise  (c.-a-d.  mountpoint=/chemin  ou
              mp=/chemin), le chemin indique doit etre  un  point  de  montage
              pour le partage qui est fait.

       fsid=num|root|uuid
              NFS  a  besoin  de  reconnaitre chaque systeme de fichiers qu'il
              offre en partage. Habituellement, il utilisera un UUID  pour  ce
              systeme de fichiers (si le systeme de fichiers en dispose) ou de
              l'identifiant du peripherique qui heberge ce systeme de fichiers
              (si le systeme de fichiers est stocke sur un peripherique).

              Puisque  tous  les  systemes  de  fichiers  ne sont pas toujours
              stockes sur des peripheriques, et qu'ils n'ont pas  toujours  un
              UUID,   il   sera  parfois  necessaire  d'indiquer  comment  NFS
              identifiera un systeme de fichiers. C'est le  role  de  l'option
              fsid=.

              Dans  NFSv4, un systeme de fichiers particulier est la racine de
              tous les systemes  de  fichiers  partages.  Il  est  defini  par
              fsid=root  ou  fsid=0,  qui veulent tous deux dire exactement la
              meme chose.

              Les autres systemes de fichiers peuvent etre identifies avec  un
              entier  court,  ou  un  UUID  qui  doit  comporter 32 caracteres
              hexadecimaux et une ponctuation arbitraire.

              Les versions du noyau Linux 2.6.20 et precedentes ne comprennent
              pas  les reglages UUID, l'utilisation d'un entier court est donc
              necessaire pour definir l'option fsid. La  definition  conjointe
              d'un  petit  nombre  et  d'un  UUID  est  possible pour une meme
              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  a ce partage se verra proposer le
              choix d'une autre adresse de systeme 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  necessaire  qu'il  s'agisse  d'un systeme de fichiers
              different. 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 possibilites lui sera proposee (Notez que le  mecanisme
              effectif  de  replication  du systeme de fichiers doit etre gere
              ailleurs).

   Correspondance d'ID utilisateur (<< User ID Mapping >>)
       nfsd base son controle d'acces aux fichiers de la machine  serveur  sur
       l'UID et le GID fournis dans chaque requete RPC de NFS. Le comportement
       attendu par un utilisateur est de pouvoir acceder a ses fichiers sur le
       serveur  de  la  meme  facon  qu'il y accede sur un systeme de fichiers
       normal. Ceci exige que les memes UID et  GID  soient  utilises  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 egalement traite comme le superutilisateur lors de
       l'acces a des fichiers du  serveur  NFS.  A  cet  effet,  l'UID  0  est
       normalement  transforme  (<< mapped >>)  en  utilisateur different : le
       pretendu  utilisateur  anonyme  ou  UID  nobody.  C'est  le   mode   de
       fonctionnement  par defaut (appele << root squashing >>), qui peut etre
       desactive grace a no_root_squash.

       Par defaut, exportfs choisit un UID et un GID  de  65534  pour  l'acces
       << squash >>.  Ces  valeurs  peuvent  egalement  etre  definies par les
       options anonuid et anongid.  Pour finir, vous pouvez faire correspondre
       toutes  les  requetes  des  utilisateurs  a  l'UID anonyme en indiquant
       l'option all_squash.

       Voici la liste complete des options de correspondance (<< mapping >>) :

       root_squash
              Transformer les requetes d'UID/GID 0 en l'UID/GID anonyme. Notez
              que  ceci  ne  s'applique  a aucun autre UID ou GID qui pourrait
              egalement etre sensible, tel que l'utilisateur bin ou le  groupe
              staff par exemple.

       no_root_squash
              Desactiver  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   repertoires   FTP  publics  partages  en  NFS,  les
              repertoires  de  spool  de  news,  etc.  L'option  inverse   est
              no_all_squash, qui est celle par defaut.

       anonuid et anongid
              Ces  options definissent explicitement l'UID et le GID du compte
              anonyme. Cette option est principalement utile pour des  clients
              PC/NFS, dans le cas ou vous souhaiteriez que toutes les requetes
              semblent provenir d'un seul et meme utilisateur.  Consultez  par
              exemple  la  ligne definissant le partage pour /home/joe dans la
              section EXEMPLES ci-dessous, qui attribue toutes les requetes  a
              l'utilisateur  150  (qui  est  cense etre celui de l'utilisateur
              Joe).

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)

       La premiere ligne exporte l'ensemble du systeme de  fichiers  vers  les
       machines  << master >>  et << trusty >>. En plus des droits d'ecriture,
       toute transformation d'UID est desactivee pour l'hote << trusty >>. Les
       deuxieme  et troisieme lignes montrent des exemples de noms de machines
       avec caracteres jokers, et de groupes de machines  (c'est  le  sens  de
       << @trusted >>).  La  quatrieme  ligne montre une entree pour le client
       PC/NFS, presente plus haut. La cinquieme ligne  partage  un  repertoire
       public  de  FTP, a toutes les machines dans le monde, en effectuant les
       requetes sous le compte anonyme. L'option insecure permet  l'acces  aux
       clients  dont  l'implementation  NFS  n'utilise pas un port reserve. La
       derniere ligne partage un repertoire  en  lecture  et  ecriture  a  une
       machine  << server >>  ainsi qu'a un groupe de machines << @trusted >>,
       et en lecture seule pour le groupe de  machines  << @external >>,  tous
       les trois ayant l'option << sync >> activee.

FICHIERS

       /etc/exports

VOIR AUSSI

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

TRADUCTION

       Cette  page  de  manuel  a  ete  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.