Provided by: manpages-fr-extra_20151231_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 maintenu par
l'administrateur système.
Chaque système de fichiers dans cette liste est suivi d'une liste d'options et d'une liste
de contrôle d'accès. La liste est utilisée par exportfs(8) pour renseigner mountd(8).
Le format de ce fichier est similaire à celui du fichier exports de SunOS. Chaque ligne
est composée d'un point de montage à partager, suivi d'une liste (aux éléments séparés par
des espaces) de clients autorisés à monter le système de fichiers situé en ce point.
Chaque client de la liste peut être immédiatement suivi par une liste d'options de partage
pour ce client (entre parenthèses, les éléments étant séparés par des virgules). Aucune
espace n'est tolérée entre un nom de client et sa liste d'options.
En outre, chaque ligne peut définir (après le nom du chemin) la valeur par défaut d'une ou
plusieurs options, sous forme de tiret (« - ») suivi d'une liste d'options. La liste
d'options est employée pour tous les partages qui suivent, sur cette ligne seulement.
Les lignes blanches sont ignorées. Un « # » indique un commentaire s'étendant jusqu'à la
fin de la ligne. Les entrées peuvent s'étendre sur plusieurs lignes en utilisant la barre
oblique inverse (antislash). Si un nom de partage contient des espaces, il doit être
protégé par des apostrophes doubles « " ». Vous pouvez aussi utiliser la barre oblique
inverse (antislash) suivi du code octal à trois chiffres pour protéger tout espace ou
autre caractère inhabituel dans un nom de partage.
Pour que soient prises en compte vos modifications sur ce fichier, vous devez exécuter
exportfs -ra ou redémarrer 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 wildcard
entré précédemment) qui correspondra à tous les clients.
Si un client correspond à plusieurs des configurations ci-dessus, alors la première
correspondance dans l'ordre de la liste ci-dessus a la priorité - indépendamment de
l'ordre d'apparition sur la ligne d'exportation. Toutefois, si un client correspond à plus
d'une spécification (par exemple deux groupes réseau), alors la première correspondance
dans l'ordre d'apparition sur la ligne d'exportation a la priorité.
Sécurité RPCSEC_GSS
Il est possible d'utiliser les chaînes spéciales « gss/krb5 », « gss/krb5i », ou
« gss/krb5p » pour n'accepter que les clients qui utilisent la sécurité rpcsec_gss.
Toutefois, cette syntaxe est obsolète, et sur les noyaux Linux 2.6.23 et supérieurs, il
faut plutôt utiliser l'option de partage « sec= ».
sec= L'option sec=, suivie d'une liste de niveaux de sécurité (délimités par des
virgules), limite le partage aux clients qui utilisent cette sécurité. Les niveaux
de sécurité disponibles sont sys (pas de sécurité cryptographique, par défaut),
krb5 (authentification seulement), krb5i (protection de l'intégrité) et krb5p
(protection de la confidentialité). En ce qui concerne la négociation des niveaux
de sécurité, l'ordre est important ; et les niveaux préférés doivent être listés en
premier. La position de l'option sec= par rapport aux autres options n'a pas
d'influence, sauf si ces options s'appliquent différemment selon le niveau de
sécurité. Dans ce cas, il faudra utiliser de multiples options sec=, et les options
qui suivent ne s'appliqueront alors qu'à ce niveau de sécurité. Les seules options
utilisables dans ce cas de figure sont ro, rw, no_root_squash, root_squash, et
all_squash.
Options générales
exportfs accepte les options de partage suivantes :
secure Cette option impose l'utilisation d'un port réservé (« IPPORT_RESERVED », inférieur
à 1024) comme origine de la requête. Cette option est activée par défaut. Pour la
désactiver, utilisez insecure.
rw Permettre les requêtes en lecture et en écriture sur le volume NFS. Le comportement
par défaut est d'interdire toute requête qui modifierait le système de fichiers,
mais on peut aussi l'indiquer avec l'option ro.
async Permettre au serveur NFS de transgresser le protocole NFS en répondant aux requêtes
avant que tous les changements impliqués par la requête en cours n'aient été
effectués sur le support réel (par exemple, le disque dur).
L'utilisation de cette option améliore généralement les performances, mais au
risque de perdre ou de corrompre des données en cas de redémarrage brutal d'un
serveur, suite à un plantage par exemple.
sync Ne répondre aux requêtes qu'après l'exécution de tous les changements sur le
support réel (voir async plus haut).
Dans toutes les versions de nfs-utils jusqu'à la 1.0.0 (incluse), async était
l'option par défaut. Dans toutes les versions postérieures à 1.0.0, le comportement
par défaut est sync, et async doit être explicitement indiquée si vous en avez
besoin. Afin d'aider les administrateurs systèmes à prêter attention à cette
modification, exportfs affichera un message d'avertissement si ni sync ni async ne
sont précisées.
no_wdelay
Cette option est sans effet si async est déjà active. Le serveur NFS va normalement
retarder une requête d'écriture sur disque s'il suspecte qu'une autre requête en
écriture liée à celle-ci est en cours ou peut survenir rapidement. Cela permet
l'exécution de plusieurs requêtes d'écriture en une seule passe sur le disque, ce
qui peut améliorer les performances. En revanche, si un serveur NFS reçoit
principalement des petites requêtes indépendantes, ce comportement peut réellement
diminuer les performances. no_wdelay permet de désactiver cette option. On peut
explicitement forcer ce comportement par défaut en utilisant l'option wdelay.
nohide Cette option est basée sur l'option de même nom fournie dans le NFS d'IRIX.
Normalement, si un serveur partage deux systèmes de fichiers dont un est monté sur
l'autre, le client devra explicitement monter les deux systèmes de fichiers pour
obtenir l'accès complet. S'il ne monte que le parent, il verra un répertoire vide à
l'endroit où l'autre système de fichiers est monté. Ce système de fichiers est
« caché ».
Définir l'option nohide sur un système de fichiers empêchera de le cacher, et tout
client convenablement autorisé pourra alors se déplacer du système de fichiers
parent à celui-ci sans s'en apercevoir.
Cependant, quelques clients NFS ne sont pas adaptés à cette situation. Il est alors
possible, par exemple, que deux fichiers d'un système de fichiers vu comme unique
aient le même numéro d'inœud.
L'option nohide ne concerne actuellement que les partages vers les hôtes seuls.
Elle ne fonctionne pas de manière fiable avec les groupes de machines, sous-réseaux
et ceux utilisant les caractères jokers.
Cette option peut être très pratique dans certains cas, mais elle doit être
utilisée avec parcimonie, et seulement après vérification de la capacité du système
client à bien gérer cette situation.
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
implications subtiles au niveau de la sécurité, mais peut améliorer la fiabilité
dans certains cas.
Si un sous-répertoire d'un système de fichiers est partagé, mais que le système de
fichiers ne l'est pas, alors chaque fois qu'une requête NFS arrive, le serveur doit
non seulement vérifier que le fichier accédé est dans le système de fichiers
approprié (ce qui est facile), mais aussi qu'il est dans l'arborescence partagée
(ce qui est plus compliqué). Cette vérification s'appelle subtree_check.
Pour ce faire, le serveur doit ajouter quelques informations sur l'emplacement du
fichier dans le « filehandle » (descripteur de fichier) qui est donné au client.
Cela peut poser problème lors d'accès à des fichiers renommés alors qu'un client
est en train de les utiliser (bien que dans la plupart des cas simples, cela
continuera à fonctionner).
La vérification de sous-répertoires est également utilisée pour s'assurer que des
fichiers situés dans des répertoires auxquels seul l'administrateur a accès ne sont
consultables que si le système de fichiers est partagé avec l'option no_root_squash
(voir ci-dessous), et ce, même si les fichiers eux-mêmes offrent un accès plus
généreux.
D'une façon générale, un système de fichiers des répertoires personnels (« home
directories »), qui est normalement partagé à sa racine et qui va subir de
multiples opérations de renommage de fichiers, devrait être partagé sans contrôle
de sous-répertoires. Un système de fichiers principalement en lecture seule, et qui
donc ne verra que peu de modifications de noms de fichiers (/usr ou /var par
exemple) et pour lequel des sous-répertoires pourront être partagés, le sera
probablement avec la vérification des sous-répertoires.
On peut explicitement forcer ce comportement par défaut de vérification des
sous-répertoires en indiquant l'option subtree_check.
À partir de la version 1.1.0 de nfs-utils, le réglage par défaut sera
no_subtree_check car la vérification des sous-répertoires (subtree_checking) pose
souvent plus de problèmes qu'elle n'en résout. Si vous voulez vraiment activer la
vérification des sous-répertoires, vous devez explicitement indiquer cette option
dans le fichier exports. Si vous ne précisez rien, exportfs vous avertira de la
modification.
insecure_locks
no_auth_nlm
Cette option (les deux noms sont synonymes) indique au serveur NFS de ne pas exiger
l'authentification des requêtes de verrouillage (c.-à-d. les requêtes qui utilisent
le protocole NLM). Normalement le serveur de NFS doit exiger d'une requête de
verrouillage qu'elle fournisse une accréditation pour un utilisateur qui a accès en
lecture au fichier. Avec cette option, aucun contrôle d'accès ne sera effectué.
Les premières implémentations de clients NFS n'envoyaient pas d'accréditations lors
de requêtes de verrouillage, et nombre de clients NFS encore utilisés sont basés
sur ces anciennes implémentations. Utilisez cette option si vous constatez que vous
ne pouvez verrouiller que les fichiers en lecture pour tous (« world readable »).
Par défaut, les demandes d'authentification des requêtes NLM se comportent comme si
les options (synonymes !) auth_nlm ou secure_locks avaient été fournies. On peut
cependant écrire explicitement ces options.
mountpoint=chemin
mp Cette option permet de ne partager un répertoire que si son montage a réussi. Si
aucun chemin n'est précisé (par exemple mountpoint ou mp) alors le partage doit
également être un point de montage. Si ce n'est pas le cas, alors le partage n'est
pas fait. Ceci vous permet d'être sûr que le répertoire d'un point de montage ne
sera jamais partagé par accident si, par exemple, le montage du système de fichiers
échouait suite à une erreur de disque dur.
Si un chemin est précisé (c.-à-d. mountpoint=/chemin ou mp=/chemin), le chemin
indiqué doit être un point de montage pour le partage qui est fait.
fsid=num|root|uuid
NFS a besoin de reconnaître chaque système de fichiers qu'il offre en partage.
Habituellement, il utilisera un UUID pour ce système de fichiers (si le système de
fichiers en dispose) ou de l'identifiant du périphérique qui héberge ce système de
fichiers (si le système de fichiers est stocké sur un périphérique).
Puisque tous les systèmes de fichiers ne sont pas toujours stockés sur des
périphériques, et qu'ils n'ont pas toujours un UUID, il sera parfois nécessaire
d'indiquer comment NFS identifiera un système de fichiers. C'est le rôle de
l'option fsid=.
Dans NFSv4, un système de fichiers particulier est la racine de tous les systèmes
de fichiers partagés. Il est défini par fsid=root ou fsid=0, qui veulent tous deux
dire exactement la même chose.
Les autres systèmes de fichiers peuvent être identifiés avec un entier court, ou un
UUID qui doit comporter 32 caractères hexadécimaux et une ponctuation arbitraire.
Les versions du noyau Linux 2.6.20 et précédentes ne comprennent pas les réglages
UUID, l'utilisation d'un entier court est donc nécessaire pour définir l'option
fsid. La définition conjointe d'un petit nombre et d'un UUID est possible pour une
même configuration, ce qui rend possible l'utilisation avec d'anciens ou de
nouveaux noyaux.
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 d'ID utilisateur (« User ID Mapping »)
nfsd base son contrôle d'accès aux fichiers de la machine serveur sur l'UID et le GID
fournis dans chaque requête RPC de NFS. Le comportement attendu par un utilisateur est de
pouvoir accéder à ses fichiers sur le serveur de la même façon qu'il y accède sur un
système de fichiers normal. Ceci exige que les mêmes UID et GID soient utilisés sur le
client et la machine serveur. Ce n'est pas toujours vrai, ni toujours souhaitable.
Bien souvent, il n'est pas souhaitable que l'administrateur d'une machine cliente soit
également traité comme le superutilisateur lors de l'accès à des fichiers du serveur NFS.
À cet effet, l'UID 0 est normalement transformé (« mapped ») en utilisateur différent : le
prétendu utilisateur anonyme ou UID nobody. C'est le mode de fonctionnement par défaut
(appelé « root squashing »), qui peut être désactivé grâce à no_root_squash.
Par défaut, exportfs choisit un UID et un GID de 65534 pour l'accès « squash ». Ces
valeurs peuvent également être définies par les options anonuid et anongid. Enfin, vous
pouvez faire correspondre toutes les demandes des utilisateurs avec l'UID anonyme en
indiquant l'option all_squash.
Voici la liste complète des options de correspondance (« mapping ») :
root_squash
Transformer les requêtes d'UID/GID 0 en l'UID/GID anonyme. Notez que ceci ne
s'applique à aucun autre UID ou GID qui pourrait également être sensible, tel que
l'utilisateur bin ou le groupe staff par exemple.
no_root_squash
Désactiver la transformation du superutilisateur. Cette option est principalement
utile pour les clients sans disque dur.
all_squash
Transformer tous les UID/GID en l'utilisateur anonyme. Utile pour les répertoires
FTP publics partagés en NFS, les répertoires de spool de news, etc. L'option
inverse est no_all_squash, qui est celle par défaut.
anonuid et anongid
Ces options définissent explicitement l'UID et le GID du compte anonyme. Cette
option est principalement utile pour des clients PC/NFS, dans le cas où vous
souhaiteriez que toutes les requêtes semblent provenir d'un seul et même
utilisateur. Consultez par exemple la ligne définissant le partage pour /home/joe
dans la section EXEMPLES ci-dessous, qui attribue toutes les requêtes à
l'utilisateur 150 (qui est censé être celui de l'utilisateur Joe).
Tables d'exportation supplémentaire
Après avoir lu /etc/exports, exportfs lit les fichiers dans le répertoire des tables
d'exportation supplémentaires /etc/exports.d.. exportfs considère seulement un fichier
dont le nom se termine par . exports et qui ne commence pas par . comme un fichier
d'exportation supplémentaire. Un fichier dont le nom ne satisfait pas à cette condition
est simplement ignoré. Le format des tables d'exportation supplémentaire est le même que
/etc/exports.
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)
/foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
/build buildhost[0-9].local.domain(rw)
La première ligne partage l'ensemble du système de fichiers vers les machines « master »
et « trusty ». En plus des droits d'écriture, toute transformation d'UID est désactivée
pour l'hôte « trusty ». Les deuxième et troisième lignes montrent des exemples de noms de
machines avec caractères jokers, et de groupes de machines (c'est le sens de
« @trusted »). La quatrième ligne montre une entrée pour le client PC/NFS, présenté plus
haut. La cinquième ligne partage un répertoire public de FTP, à toutes les machines dans
le monde, en effectuant les requêtes sous le compte anonyme. L'option insecure permet
l'accès aux clients dont l'implémentation NFS n'utilise pas un port réservé. La sixième
ligne partage un répertoire en lecture et écriture à une machine « server » ainsi qu'à un
groupe de machines « @trusted », et en lecture seule pour le groupe de machines
« @external », tous les trois ayant l'option « sync » activée. La septième ligne partage
un répertoire aux deux sous-réseaux IPv6 et IPv4. La huitième ligne montre une utilisation
d'un caractère joker de classe.
FICHIERS
/etc/exports /etc/exports.d
VOIR AUSSI
exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8).
TRADUCTION
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.
31 décembre 2009 exports(5)