Provided by: manpages-fr_4.27.0-1_all 
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 entretenu 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.
Pour que soient prises en compte vos modifications sur ce fichier, exécutez exportfs -ra ou redémarrez le
serveur NFS.
Formats des noms de machine
Les clients NFS peuvent être indiqués de plusieurs façons :
Une machine seule
Vous pouvez indiquer un hôte, soit par un nom abrégé reconnu par le mécanisme de résolution, soit
par le nom de domaine pleinement qualifié, soit par une adresse IPv4, ou soit par une adresse
IPV6. Les adresses IPv6 ne doivent pas être entre crochets dans /etc/exports pour ne pas être
confondues avec les caractères 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 joker 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.
Sécurité de la couche de transport (TLS)
Le serveur NFS de Linux permet l'utilisation de RPC avec TLS (RFC 9289) pour protéger le trafic entre lui
et ses clients. Autrement, les administrateurs peuvent sécuriser le trafic NFS en utilisant un VPN, un
tunnel SSH ou un mécanisme similaire d'une manière transparente au serveur.
Pour activer l'utilisation de RPC avec TLS, l'administrateur du serveur doit installer et configurer
tlshd pour gérer les requêtes d'établissement de connexion de sécurité de la couche de transport à partir
du noyau local. Les clients peuvent ensuite choisir d'utiliser RPC avec TLS ou de continuer à opérer sans
lui.
Les administrateurs peuvent exiger l'utilisation de RPC avec TLS pour protéger l'accès aux partages
individuels, ce qui est particulièrement utile lorsqu'on utilise des variantes sans sécurité chiffrée
telles que sec=sys. L'option xprtsec= suivie d'une liste non ordonnée, séparée par des deux-points, de
politiques de sécurité peut restreindre l'accès au partage aux seuls clients qui ont négocié la sécurité
de la couche de transport. Actuellement, les politiques de sécurité de la couche de transport
comprennent :
none Le serveur permet aux clients d'accéder au partage sans utiliser la sécurité de la couche de
transport.
tls Le serveur permet aux clients qui ont négocié une session RPC avec TLS sans authentification du
pair (seulement la confidentialité) d'accéder au partage. Les clients ne sont pas obligés de
fournir un certificat X.509 lors de l'établissement de la session avec la sécurité de la couche de
transport.
mtls Le serveur permet aux clients qui ont négocié une session RPC avec TLS avec authentification du
pair d'accéder au partage. Le serveur exige que les clients fournissent un certificat X.509 lors
de l'établissement de la session avec la sécurité de la couche de transport.
Si RPC avec TLS est configuré et activé et si l'option xprtsec=n'est pas spécifiée, la configuration par
défaut pour un partage est xprtsec=none:tls:mtls. Avec cette configuration, le serveur permet aux clients
d'utiliser n'importe quel mécanisme de sécurité de la couche de transport.
Options générales
exportfs accepte les options de partage suivantes :
secure Cette option impose que les requêtes qui n'utilisent pas gss aient comme origine un port Internet
inférieur au port réservé (« IPPORT_RESERVED ») 1024. Cette option est activée par défaut. Pour la
désactiver, utilisez insecure. NOTE : les noyaux anciens (antérieurs à la version amont 4.17)
appliquent aussi cette exigence aux requêtes gss.
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.
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, les sous-réseaux et ceux utilisant les
caractères jokers.
Cette option peut être très pratique dans certains cas, mais elle doit être utilisée avec
parcimonie, et seulement après vérification de la capacité du système client à bien gérer cette
situation.
Cette option peut être désactivée explicitement pour NFSv2 et NFSv3 avec hide.
Cette option n'est pas pertinente quand NFSv4 est utilisé. NFSv4 ne dissimule jamais les systèmes
de fichiers subordonnés. Tous les systèmes de fichiers partagés seront visibles où cela est prévu
lors de l'utilisation de NFSv4.
crossmnt
Cette option est semblable à nohide, mais elle permet aux clients d'accéder à tous les systèmes de
fichiers montés sur un système de fichiers marqué crossmnt. Ainsi, si un système de fichiers
enfant « B » est monté sur un système de fichiers parent « A », définir l'option crossmnt à « A »
aura le même effet que d'indiquer « nohide » sur « B ».
Avec nohide, le système de fichiers enfant doit être explicitement partagé. Avec crossmnt, ce
n'est pas le cas. Si un enfant d'un fichier crossmnt n'est pas explicitement partagé, il sera
implicitement partagé avec les mêmes options de partage que le parent, sauf pour fsid=. Cela rend
impossible de ne pas partager un enfant d'un système de fichiers crossmnt. Si certains des
systèmes de fichiers subordonnés d'un parent, mais pas tous, sont destinés à être partagés, ils
doivent être explicitement partagés et le parent ne doit ne pas avoir crossmnt configuré.
L'option nocrossmnt peut explicitement désactiver crossmnt si elle a été définie précédemment.
Cela est rarement utile.
subtree_check
Cette option active la vérification de sous-répertoires, ce qui peut avoir des bénéfices subtils
au niveau de la sécurité, mais peut réduire 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éral.
Pour plus d’informations sur les implications au niveau de la sécurité, reportez-vous à la section
Partage de sous-répertoires
D'une façon générale, un système de fichiers du répertoire personnel (« home directory »), qui est
normalement partagé à sa racine et qui va subir de multiples opérations de renommage de fichiers,
doit être partagé sans contrôle des 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.
La désactivation par défaut de la vérification des sous-répertoires peut être explicitement
demandée avec l'option no_subtree_check.
Avant la version 1.1.0 de nfs-utils, le réglage par défaut était subtree_check. Depuis la
version 1.1.0, le réglage par défaut est no_subtree_check, car la vérification des
sous-répertoires 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'est-à-dire 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'est-à-dire 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
Cette option désactive la gestion des requêtes READDIRPLUS. Quand elle est positionnée, les
requêtes 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 à 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).
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 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 Cette option active l'utilisation de l'extension pNFS si le niveau du protocole est égal ou
supérieur à NFSv4.1 et si le système de fichiers prend en charge les partages pNFS. Avec pNFS, les
clients peuvent contourner le serveur et réaliser des E/S directement sur les périphériques de
stockage. Le comportement par défaut peut être requis explicitement avec l'option no_pnfs.
security_label
Avec cette option positionnée, les clients qui utilisent NFSv4.2 ou une version ultérieure seront
capables de définir et de récupérer des étiquettes de sécurité (comme celles utilisées par
SELinux). Cela ne fonctionnera que si tous les clients utilisent une politique de sécurité
cohérente. Notez que les noyaux anciens ne prenaient pas en compte cette option de partage et
activaient plutôt les étiquettes de sécurité par défaut.
reexport=auto-fsidnum|predefined-fsidnum
Cette option est une aide quand un partage NFS est repartagé. Dans la mesure où le serveur NFS a
besoin d'un identifiant unique pour chacun des systèmes de fichiers partagés et qu'un partage NFS
ne peut en fournir un, un fsid manuel est nécessaire. Dès que crossmnt est utilisé, l'assignation
manuelle d'un fsid ne fonctionne plus. C'est là que cette option devient pratique. Elle assignera
automatiquement un fsid numérique aux partages NFS. Les relations entre le fsid et le chemin sont
stockées dans une base de données SQLite. predefined-fsidnum présume les numéros de fsid
pré-alloués et ne vérifie qu'eux. Cette option dépend aussi du noyau, une version 5.19 au moins du
noyau est nécessaire. Dans la mesure ou reexport= peut automatiquement allouer et assigner des
fsid numériques, il n'est plus possible d'avoir des fsid numériques dans d'autres partages dès que
cette option est utilisée dans au moins une entrée de partage.
L'association entre les numéros de fsid et les chemins est stockée dans une base de données
SQLite. Ne modifiez ni ne supprimez la base de données à moins que vous ne sachiez exactement ce
que vous faites. predefined-fsidnum est utile quand vous avez utilisé auto-fsidnum auparavant et
que vous ne voulez pas stocker davantage d'entrées.
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 associé (« mapped ») à un 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
Associer 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).
Partage de sous-répertoires
Normalement, vous ne devriez partager que la racine d'un système de fichiers. Le serveur NFS vous
permettra aussi de partager un sous-répertoire d'un système de fichiers ; cependant cela présente des
inconvénients.
D'abord, il peut être possible à un utilisateur malveillant d’accéder aux fichiers sur le système de
fichiers en dehors du sous-répertoire exporté, en devinant le descripteur de fichier de ces autres
fichiers. Dans certains cas, un utilisateur malveillant peut aussi avoir la capacité d'accéder à des
fichiers dans d'autres systèmes de fichiers qui n'ont pas été exportés en remplaçant le sous-répertoire
exporté par un lien symbolique vers un autre répertoire. Le seul moyen d'éviter cela est d'utiliser
l'option subtree_check, ce qui peut provoquer d'autres problèmes.
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-répertoires et si des partages de
sous-répertoires imbriqués modifient les options security_label ou sec=, les clients NFSv4 ne verront
normalement que les options du partage parent. Aussi quand les options de sécurité diffèrent, un client
malveillant peut utiliser des attaques en devinant le descripteur de fichier pour accéder aux fichiers
d'un sous-répertoire en utilisant les options d'un autre.
Tables d'exportation supplémentaire
Après avoir lu /etc/exports, exportfs lit les fichiers dans le répertoire des tables d'exportation
supplémentaires /etc/exports.d.. Seuls les fichiers dont le nom se termine par .exports sont pris en
compte. Les fichiers qui commencent par un point (.) sont ignorés. Le format des tables d'exportation
supplémentaires est le même 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 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), tlshd(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>, Cédric Boutillier <cedric.boutillier@gmail.com> et Jean-Pierre Giraud <jean-
pierregiraud@neuf.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 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)