exports(5) File Formats Manual exports(5) NOM exports - Liste des repertoires partages par le serveur NFS DESCRIPTION Le fichier /etc/exports du serveur NFS contient une liste des systemes de fichiers locaux accessibles pour les clients NFS. Le contenu de ce fichier est entretenu par l'administrateur systeme. Chaque systeme de fichiers dans cette liste est suivi d'une liste d'options et d'une liste de controle d'acces. La liste est utilisee par exportfs(8) pour renseigner mountd(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, executez exportfs -ra ou redemarrez le serveur NFS. Formats des noms de machine Les clients NFS peuvent etre indiques de plusieurs facons : Une machine seule Vous pouvez indiquer un hote, soit par un nom abrege reconnu par le mecanisme de resolution, soit par le nom de domaine pleinement qualifie, soit par une adresse IPv4, ou soit par une adresse IPV6. Les adresses IPv6 ne doivent pas etre entre crochets dans /etc/exports pour ne pas etre confondues avec les caracteres de classe jokers correspondants. 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 IPv4 du reseau pour obtenir un sous-reseau avec 10 bits pour la partie machine. Les adresses IPv6 doivent utiliser une longueur de masque contigues et ne doivent pas etre a l'interieur des crochets pour eviter la confusion avec les caracteres de classe jokers. 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. Caracteres jokers Les noms de machine peuvent contenir les caracteres jokers * et ?, ou peuvent contenir des listes de classes de caracteres entre [crochets]. 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. 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. Anonymement Ceci est specifie par un simple caractere * ( ne pas le confondre avec le joker entre precedemment) qui correspondra a tous les clients. Si un client correspond a plusieurs des configurations ci-dessus, alors la premiere correspondance dans l'ordre de la liste ci-dessus a la priorite - independamment de l'ordre d'apparition sur la ligne d'exportation. Toutefois, si un client correspond a plus d'une specification (par exemple deux groupes reseau), alors la premiere correspondance dans l'ordre d'apparition sur la ligne d'exportation a la priorite. Securite 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. Securite de la couche de transport (TLS) Le serveur NFS de Linux permet l'utilisation de RPC avec TLS (RFC 9289) pour proteger le trafic entre lui et ses clients. Autrement, les administrateurs peuvent securiser le trafic NFS en utilisant un VPN, un tunnel SSH ou un mecanisme similaire d'une maniere transparente au serveur. Pour activer l'utilisation de RPC avec TLS, l'administrateur du serveur doit installer et configurer tlshd pour gerer les requetes d'etablissement de connexion de securite de la couche de transport a partir du noyau local. Les clients peuvent ensuite choisir d'utiliser RPC avec TLS ou de continuer a operer sans lui. Les administrateurs peuvent exiger l'utilisation de RPC avec TLS pour proteger l'acces aux partages individuels, ce qui est particulierement utile lorsqu'on utilise des variantes sans securite chiffree telles que sec=sys. L'option xprtsec= suivie d'une liste non ordonnee, separee par des deux-points, de politiques de securite peut restreindre l'acces au partage aux seuls clients qui ont negocie la securite de la couche de transport. Actuellement, les politiques de securite de la couche de transport comprennent : none Le serveur permet aux clients d'acceder au partage sans utiliser la securite de la couche de transport. tls Le serveur permet aux clients qui ont negocie une session RPC avec TLS sans authentification du pair (seulement la confidentialite) d'acceder au partage. Les clients ne sont pas obliges de fournir un certificat X.509 lors de l'etablissement de la session avec la securite de la couche de transport. mtls Le serveur permet aux clients qui ont negocie une session RPC avec TLS avec authentification du pair d'acceder au partage. Le serveur exige que les clients fournissent un certificat X.509 lors de l'etablissement de la session avec la securite de la couche de transport. Si RPC avec TLS est configure et active et si l'option xprtsec=n'est pas specifiee, la configuration par defaut pour un partage est xprtsec=none:tls:mtls. Avec cette configuration, le serveur permet aux clients d'utiliser n'importe quel mecanisme de securite de la couche de transport. Options generales exportfs accepte les options de partage suivantes : secure Cette option impose que les requetes qui n'utilisent pas gss aient comme origine un port Internet inferieur au port reserve (<< IPPORT_RESERVED >>) 1024. Cette option est activee par defaut. Pour la desactiver, utilisez insecure. NOTE : les noyaux anciens (anterieurs a la version amont 4.17) appliquent aussi cette exigence aux requetes gss. 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), async 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. 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 forcer 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 fichiers vu comme unique aient le meme numero d'inoeud. L'option nohide ne concerne actuellement que les partages vers les hotes seuls. Elle ne fonctionne pas de maniere fiable avec les groupes de machines, les 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 pour NFSv2 et NFSv3 avec hide. Cette option n'est pas pertinente quand NFSv4 est utilise. NFSv4 ne dissimule jamais les systemes de fichiers subordonnes. Tous les systemes de fichiers partages seront visibles ou cela est prevu lors de l'utilisation de NFSv4. crossmnt Cette option est semblable a nohide, mais elle permet aux clients d'acceder a tous les systemes de fichiers montes sur un systeme de fichiers marque crossmnt. Ainsi, si un systeme de fichiers enfant << B >> est monte sur un systeme de fichiers parent << A >>, definir l'option crossmnt a << A >> aura le meme effet que d'indiquer << nohide >> sur << B >>. Avec nohide, le systeme de fichiers enfant doit etre explicitement partage. Avec crossmnt, ce n'est pas le cas. Si un enfant d'un fichier crossmnt n'est pas explicitement partage, il sera implicitement partage avec les memes options de partage que le parent, sauf pour fsid=. Cela rend impossible de ne pas partager un enfant d'un systeme de fichiers crossmnt. Si certains des systemes de fichiers subordonnes d'un parent, mais pas tous, sont destines a etre partages, ils doivent etre explicitement partages et le parent ne doit ne pas avoir crossmnt configure. L'option nocrossmnt peut explicitement desactiver crossmnt si elle a ete definie precedemment. Cela est rarement utile. subtree_check Cette option active la verification de sous-repertoires, ce qui peut avoir des benefices subtils au niveau de la securite, mais peut reduire 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 partage avec l'option no_root_squash (voir ci-dessous), et ce meme si les fichiers eux-memes offrent un acces plus general. Pour plus d'informations sur les implications au niveau de la securite, reportez-vous a la section Partage de sous-repertoires D'une facon generale, un systeme de fichiers du repertoire personnel (<< home directory >>), qui est normalement partage a sa racine et qui va subir de multiples operations de renommage de fichiers, doit etre partage sans controle des 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. La desactivation par defaut de la verification des sous-repertoires peut etre explicitement demandee avec l'option no_subtree_check. Avant la version 1.1.0 de nfs-utils, le reglage par defaut etait subtree_check. Depuis la version 1.1.0, le reglage par defaut est no_subtree_check, car la verification des sous-repertoires pose souvent plus de problemes qu'elle n'en resout. Si vous voulez vraiment activer la verification des sous-repertoires, vous devez explicitement indiquer cette option dans le fichier exports. Si vous ne precisez rien, exportfs vous avertira de la modification. sign_fh This option enforces signing filehandles on the export. If the server has been configured with a secret key for such purpose, filehandles will include a hash to verify the filehandle was created by the server in order to guard against filehandle guessing attacks which can bypass path-name based access restrictions. Note that for NFSv3 some exported filesystems may exceed the maximum filehandle size when the signing hash is added. 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'est-a-dire 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'authentification 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. 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'est-a-dire 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. nordirplus Cette option desactive la gestion des requetes READDIRPLUS. Quand elle est positionnee, les requetes READDIRPLUS de clients NFS renvoient NFS3ERR_NOTSUPP et les clients se replient sur READDIR. Cette option affecte seulement les clients NFSv3. 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). Cette option n'affecte que les clients NFSv4. Les autres clients ignorent toutes les parties << refer= >>. 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). pnfs Cette option active l'utilisation de l'extension pNFS si le niveau du protocole est egal ou superieur a NFSv4.1 et si le systeme de fichiers prend en charge les partages pNFS. Avec pNFS, les clients peuvent contourner le serveur et realiser des E/S directement sur les peripheriques de stockage. Le comportement par defaut peut etre requis explicitement avec l'option no_pnfs. security_label Avec cette option positionnee, les clients qui utilisent NFSv4.2 ou une version ulterieure seront capables de definir et de recuperer des etiquettes de securite (comme celles utilisees par SELinux). Cela ne fonctionnera que si tous les clients utilisent une politique de securite coherente. Notez que les noyaux anciens ne prenaient pas en compte cette option de partage et activaient plutot les etiquettes de securite par defaut. reexport=auto-fsidnum|predefined-fsidnum This option helps when a NFS share is re-exported. Since the NFS server needs a unique identifier for each exported filesystem and a NFS share cannot provide such, usually a manual fsid is needed. As soon crossmnt is used manually assigning fsid won't work anymore. This is where this option becomes handy. It will automatically assign a numerical fsid to exported NFS shares. The fsid and path relations are stored in a SQLite database. If auto-fsidnum is selected, the fsid is also automatically allocated. predefined-fsidnum assumes pre-allocated fsid numbers and will just look them up. This option depends also on the kernel, you will need at least kernel version 5.19. Since reexport= can automatically allocate and assign numerical fsids, it is no longer possible to have numerical fsids in other exports as soon this option is used in at least one export entry. L'association entre les numeros de fsid et les chemins est stockee dans une base de donnees SQLite. Ne modifiez ni ne supprimez la base de donnees a moins que vous ne sachiez exactement ce que vous faites. predefined-fsidnum est utile quand vous avez utilise auto-fsidnum auparavant et que vous ne voulez pas stocker davantage d'entrees. 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 associe (<< mapped >>) a un 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. Enfin, vous pouvez faire correspondre toutes les demandes des utilisateurs avec l'UID anonyme en indiquant l'option all_squash. Voici la liste complete des options de correspondance (<< mapping >>) : root_squash Associer 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). Partage de sous-repertoires Normalement, vous ne devriez partager que la racine d'un systeme de fichiers. Le serveur NFS vous permettra aussi de partager un sous-repertoire d'un systeme de fichiers ; cependant cela presente des inconvenients. D'abord, il peut etre possible a un utilisateur malveillant d'acceder aux fichiers sur le systeme de fichiers en dehors du sous-repertoire exporte, en devinant le descripteur de fichier de ces autres fichiers. Dans certains cas, un utilisateur malveillant peut aussi avoir la capacite d'acceder a des fichiers dans d'autres systemes de fichiers qui n'ont pas ete exportes en remplacant le sous-repertoire exporte par un lien symbolique vers un autre repertoire. Le seul moyen d'eviter cela est d'utiliser l'option subtree_check, ce qui peut provoquer d'autres problemes. Ensuite, les options de partage peuvent ne pas s'appliquer comme vous vous y attendiez. Par exemple, l'option security_label ne fonctionnera pas sur des partages de sous-repertoires et si des partages de sous-repertoires imbriques modifient les options security_label ou sec=, les clients NFSv4 ne verront normalement que les options du partage parent. Aussi quand les options de securite different, un client malveillant peut utiliser des attaques en devinant le descripteur de fichier pour acceder aux fichiers d'un sous-repertoire en utilisant les options d'un autre. Tables d'exportation supplementaire Apres avoir lu /etc/exports, exportfs lit les fichiers dans le repertoire des tables d'exportation supplementaires /etc/exports.d.. Seuls les fichiers dont le nom se termine par .exports sont pris en compte. Les fichiers qui commencent par un point (.) sont ignores. Le format des tables d'exportation supplementaires est le meme que celui de /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 premiere ligne partage 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 sixieme 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. La septieme ligne partage un repertoire aux deux sous-reseaux IPv6 et IPv4. La huitieme ligne montre une utilisation d'un caractere joker de classe. FICHIERS /etc/exports /etc/exports.d VOIR AUSSI exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8), tlshd(8). TRADUCTION La traduction francaise de cette page de manuel a ete creee par Valery Perrin , Sylvain Cherrier , Thomas Huriaux , Dominique Simen , Nicolas Sauzede , Romain Doumenc , David Prevot , Denis Mugnier , Cedric Boutillier et Jean-Pierre Giraud Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . 31 decembre 2009 exports(5)