Provided by: manpages-fr-extra_20080921_all bug

NOM

       exports - Systèmes de fichiers à partager (pour NFS en mode noyau)

SYNOPSIS

       /etc/exports

DESCRIPTION

       Le  fichier  /etc/exports  sert  de  liste de contrôle d’accès pour les
       systèmes de fichiers à partager avec les clients NFS.  Il  est  utilisé
       par exportfs(8) pour informer mountd(8) et le démon serveur NFS en mode
       noyau nfsd(8).

       Le format de ce fichier est similaire à celui  du  fichier  exports  de
       SunOS.  Chaque ligne correspond à 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). Aucun espace n’est toléré entre un nom de client et sa liste
       d’options.

       En outre, chaque ligne peut définir (après le nom du chemin) le réglage
       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 la prise en compte de vos modifications sur ce fichier, vous devez
       exécuter exportfs -ra ou re-démarrer le serveur NFS.

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

       Une machine seule
              C’est  le  format  le plus courant. Vous pouvez indiquer un hôte
              par son nom abrégé reconnu par votre résolveur de nom,  par  son
              nom de domaine complet, ou par son adresse IP.

       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.

       Caractères jokers
              Les noms de machine peuvent contenir les caractères jokers *  et
              ?.  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.

       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 du réseau pour obtenir un sous réseau avec  10  bits
              pour  la  partie  machine). 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.

   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 (délimitée par  des  virgules)
              de  niveaux  de  sécurité,  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 confidentialité). En ce qui concerne la
              négociation des niveaux de sécurité, l’ordre est important,  les
              niveaux préférés devant être listés les premiers. 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.  On  peut spécifier
              explicitement ce comportement par défaut en  utilisant  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), c’était l’option par défaut. Dans toutes les versions
              suivantes, 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
              soit  en  cours  ou  puisse  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  spécifier 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
              de  ce  système  de  fichiers  apparemment  unique aient le même
              numéro d’inode.

              L’option nohide ne concerne actuellement que les  partages  vers
              les  htes  seuls.  Elle ne s’applique pas aux partages vers 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 du bon comportement du système client à 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 subtiles implications au niveau de la  sécurité,  mais
              peut améliorer la fiabilité dans certains cas.

              Si  un  sous-répertoire dans 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    exporté    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  spécifier 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   activer   la   vérification   des
              sous-répertoires  comme  auparavant  , vous devrez explicitement
              indiquer ce choix dans le fichier exports. Si vous n’indiquez ni
              l’une  ni  l’autre  option,  exportfs  vous préviendra que cette
              modification est en suspens.

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

              On  peut  explicitement  spécifier ce comportement par défaut de
              demande d’accréditation pour les requêtes NLM en  indiquant  les
              options synonymes auth_nlm ou secure_locks.

       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 dispose d’un tel
              UUID) 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  de  spécifier  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 dID 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.  Pour finir, vous pouvez faire correspondre  toutes
       les  requêtes  des  utilisateurs  à 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).

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 première ligne exporte 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
       dernière ligne partage un répertoire en lecture-écriture à une  machine
       « server » ainsi qu’à un groupe de machines « @trusted », et en lecture
       seule pour le groupe de machines « @trusted »,  tous  les  trois  ayant
       l’option « sync » activée.

FICHIERS

       /etc/exports

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.