Provided by:
manpages-fr-extra_20101103_all 
NOM
exports - Systemes de fichiers a partager (pour NFS en mode noyau)
SYNOPSIS
/etc/exports
DESCRIPTION
Le fichier /etc/exports sert de liste de controle d'acces pour les
systemes de fichiers a partager avec les clients NFS. Il est utilise
par exportfs(8) pour informer mountd(8) et le demon serveur NFS en mode
noyau nfsd(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, vous
devez executer << exportfs -ra >> ou redemarrer le serveur NFS.
Formats des noms de machine
Les clients NFS peuvent etre indiques de plusieurs facons :
Une machine seule
C'est le format le plus courant. Vous pouvez indiquer un hote
par son nom abrege reconnu par votre solveur de nom, par son nom
de domaine complet, ou par son adresse IP.
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.
Caracteres jokers
Les noms de machine peuvent contenir les caracteres jokers * et
?. 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.
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 du reseau pour obtenir un sous reseau avec
10 bits pour la partie machine). 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.
S'ecurit'e 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.
Options g'en'erales
exportfs accepte les options de partage suivantes :
secure Cette option impose l'utilisation d'un port reserve
(<< IPPORT_RESERVED >>, inferieur a 1024) comme origine de la
requete. Cette option est activee par defaut. Pour la
desactiver, utilisez insecure.
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), c'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.
Afin d'aider les administrateurs systemes a preter attention a
cette modification, exportfs affichera un message
d'avertissement si ni sync ni async ne sont precisees.
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 specifier 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 fichier vu comme unique aient le meme numero
d'inoeud.
L'option nohide ne concerne actuellement que les partages vers
les h^otes seuls. Elle ne fonctionne pas de maniere fiable avec
les groupes de machines, 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 avec hide.
crossmnt
Cette option est semblable a nohide mais elle permet aux clients
de se deplacer du systeme de fichiers marque crossmnt aux
systemes de fichiers partages montes dessus. Ainsi, si un
systeme de fichiers fils << B >> est monte sur un systeme de
fichiers pere << A >>, definir l'option crossmnt sur << A >>
aura le meme effet que d'indiquer << nohide >> sur << B >>.
no_subtree_check
Cette option neutralise la verification de sous-repertoires, ce
qui a des implications subtiles au niveau de la securite, mais
peut ameliorer 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 exporte avec l'option no_root_squash
(voir ci-dessous), et ce, meme si les fichiers eux-memes offrent
un acces plus genereux.
D'une facon generale, un systeme de fichiers des repertoires
personnels (<< home directories >>), qui est normalement partage
a sa racine et qui va subir de multiples operations de renommage
de fichiers, devrait etre partage sans controle de
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.
On peut explicitement specifier ce comportement par defaut de
verification des sous-repertoires en indiquant l'option
subtree_check.
A partir de la version 1.1.0 de nfs-utils, le reglage par defaut
sera no_subtree_check car la verification des sous-repertoires
(subtree_checking) pose souvent plus de problemes qu'elle n'en
resout. Si vous voulez vraiment activer la verification des
sous-repertoires, vous devez explicitement specifier cette
option dans le fichier exports. Si vous ne precisez 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 requetes de
verrouillage (c.-a-d. 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'authentifications 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.
no_acl Sur certains noyaux specialement modifies, et lors de partages
de systemes de fichiers implementant les ACL, cette option
indique a nfsd ne pas devoiler les ACL aux clients, ainsi ils
verront seulement un sous-ensemble de permissions reelles sur le
systeme de fichiers donne. Cette option est efficace pour des
partages utilises par les clients NFSv2 et les anciens clients
NFSv3 qui effectuent des verifications d'acces localement. Les
clients NFSv3 actuels utilisent l'appel de procedure distante
ACCESS (<< ACCESS RPC >>) afin d'effectuer toutes les
verifications d'acces sur le serveur. Notez que l'option no_acl
n'a d'effet que sur des noyaux specifiquement modifies pour le
gerer, et seulement lors du partage de systemes de fichiers
implementant les ACL. Par defaut, le partage implemente les ACL
(c.-a-d. par defaut, no_acl est desactivee).
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.-a-d. 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.
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).
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).
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 transforme (<< mapped >>) en 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. Pour finir, vous pouvez faire correspondre
toutes les requetes des utilisateurs a l'UID anonyme en indiquant
l'option all_squash.
Voici la liste complete des options de correspondance (<< mapping >>) :
root_squash
Transformer 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).
EXEMPLES
# exemple de fichier /etc/exports
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub *(ro,insecure,all_squash)
/srv/www -sync,rw server @trusted @external(ro)
La premiere ligne exporte 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
derniere 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.
FICHIERS
/etc/exports
VOIR AUSSI
exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8).
TRADUCTION
Cette page de manuel a ete 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.