exports - Liste des répertoires partagés par le serveur NFS
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.
To apply changes to this file, run
exportfs -ra or restart the NFS
server.
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é.
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.
exportfs accepte les options de partage suivantes :
- secure
- This option requires that requests not using gss originate
on an Internet port less than IPPORT_RESERVED (1024). This option is on by
default. To turn it off, specify insecure. (NOTE: older kernels
(before upstream kernel version 4.17) enforced this requirement on gss
requests as well.)
- 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).
In releases of nfs-utils up to and including 1.0.0, the async option
was the default. In all releases after 1.0.0, sync is the default,
and async must be explicitly requested if needed.
- 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.
The option can be explicitly disabled for NFSv2 and NFSv3 with hide.
This option is not relevant when NFSv4 is use. NFSv4 never hides subordinate
filesystems. Any filesystem that is exported will be visible where
expected when using NFSv4.
- crossmnt
- This option is similar to nohide but it makes it
possible for clients to access all filesystems mounted on a filesystem
marked with crossmnt. Thus when a child filesystem "B" is
mounted on a parent "A", setting crossmnt on "A" has a
similar effect to setting "nohide" on B.
With nohide the child filesystem needs to be explicitly exported.
With crossmnt it need not. If a child of a crossmnt file is
not explicitly exported, then it will be implicitly exported with the same
export options as the parent, except for fsid=. This makes it
impossible to not export a child of a crossmnt filesystem.
If some but not all subordinate filesystems of a parent are to be
exported, then they must be explicitly exported and the parent should not
have crossmnt set.
The nocrossmnt option can explictly disable crossmnt if it was
previously set. This is rarely useful.
- 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.
- nordirplus
- This option will disable READDIRPLUS request handling. When
set, READDIRPLUS requests from NFS clients return NFS3ERR_NOTSUPP, and
clients fall back on READDIR. This option affects only NFSv3 clients.
-
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).
- pnfs
- This option enables the use of the pNFS extension if the
protocol level is NFSv4.1 or higher, and the filesystem supports pNFS
exports. With pNFS clients can bypass the server and perform I/O directly
to storage devices. The default can be explicitly requested with the
no_pnfs option.
- security_label
- With this option set, clients using NFSv4.2 or higher will
be able to set and retrieve security labels (such as those used by
SELinux). This will only work if all clients use a consistent security
policy. Note that early kernels did not support this export option, and
instead enabled security labels by default.
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).
Normally you should only export only the root of a filesystem. The NFS server
will also allow you to export a subdirectory of a filesystem, however, this
has drawbacks:
First, it may be possible for a malicious user to access files on the filesystem
outside of the exported subdirectory, by guessing filehandles for those other
files. The only way to prevent this is by using the
no_subtree_check
option, which can cause other problems.
Second, export options may not be enforced in the way that you would expect. For
example, the
security_label option will not work on subdirectory
exports, and if nested subdirectory exports change the
security_label
or
sec= options, NFSv4 clients will normally see only the options on
the parent export. Also, where security options differ, a malicious client may
use filehandle-guessing attacks to access the files from one subdirectory
using the options from another.
After reading
/etc/exports exportfs reads files in the
/etc/exports.d directory as extra export tables. Only files ending in
.exports are considered. Files beginning with a dot are ignored. The
format for extra export tables is the same as
/etc/exports
# 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.
/etc/exports /etc/exports.d
exportfs(8),
netgroup(5),
mountd(8),
nfsd(8),
showmount(8).
La traduction française de cette page de manuel a été
créée par Valéry Perrin
<
[email protected]>, Sylvain Cherrier
<
[email protected]>, Thomas Huriaux
<
[email protected]>, Dominique Simen
<
[email protected]>, Nicolas Sauzède
<
[email protected]>, Romain Doumenc <
[email protected]>, David
Prévot <
[email protected]>, Denis Mugnier
<
[email protected]> et Cédric Boutillier
<
[email protected]>
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 à
[email protected]