Provided by:
manpages-fr-extra_20101103_all 
NOM
nfs - Format de fstab et options pour les systemes de fichiers nfs et
nfs4
SYNOPSIS
/etc/fstab
DESCRIPTION
NFS est un protocole standard de l'Internet cree par Sun Microsystem en
1984. NFS a ete developpe pour permettre le partage de fichiers entre
des systemes connectes a un reseau local. Le client NFS de Linux gere
trois versions du protocole : NFS version 2 [RFC1094], NFS version 3
[RFC1813], et NFS version 4 [RFC3530].
La commande mount(8) lie un systeme de fichiers au point de montage
donne dans l'espace de noms hierarchise du systeme. Le fichier
/etc/fstab decrit la facon dont mount(8) doit recreer la hierarchie de
l'espace de noms du systeme de fichiers a partir de systemes de
fichiers independants (dont ceux partages par des serveurs NFS).
Chacune des lignes du fichier /etc/fstab decrit un unique systeme de
fichiers, son point de montage, et un ensemble d'options par defaut
pour ce point de montage.
Dans le cas des montages de systemes de fichiers NFS, une ligne dans le
fichier /etc/fstab indique le nom du serveur, le chemin du repertoire
partage a monter, le repertoire local qui sera le point de montage, le
type de systeme de fichiers a monter et la liste des options de montage
qui indique la facon dont le systeme de fichiers sera monte et quel
sera le comportement du client NFS lorsqu'il accedera aux fichiers du
point de montage. Le cinquieme et le sixieme champs de chaque ligne ne
sont pas utilises par NFS, et par consequent contiennent par convention
la valeur zero. Par exemple :
serveur:chemin /point_de_montage type_de_fs option,option,... 0
0
Le nom du serveur et le chemin de partage sont separes par un deux
points, tandis que les options de montage sont separees par des
virgules. Les champs restants sont separes par des espaces ou des
tabulations.
Le nom du serveur peut etre un nom d'hote non qualifie, un nom de
domaine pleinement qualifie (<< fully qualified domain name >>), une
adresse IPv4, ou une adresse IPv6 entouree par des crochets. Les
adresses IPv6 de liens locaux ou de sites locaux doivent etre
accompagnees d'un identifiant d'interface. Referez-vous a ipv6(7) pour
des details quant a l'ecriture des adresse IPv6 brutes.
Le champ fstype contient soit << nfs >> (versions 2 ou 3 du montage
NFS) ou << nfs4 >> (version 4 du protocole). Les systemes de fichier
nfs et nfs4 ont des options de montage similaires, decrites ci-dessous.
OPTIONS DE MONTAGE
Reportez-vous a mount(8) pour la description des options de montage
generiques disponibles pour tous les systemes de fichiers. Si vous
n'avez pas besoin d'indiquer d'options de montage particulieres,
utilisez l'option generique defaults dans /etc/fstab.
Options valides pour les syst`emes de fichiers nfs ou nfs4
L'utilisation de ces options est valable a la fois pour les systemes de
fichiers nfs et nfs4. Cela entraine le meme comportement et les memes
valeurs par defaut pour les deux systemes de fichiers.
soft / hard Definit le comportement de recuperation du client NFS
lorsqu'une requete NFS ne repond pas (<< time out >>).
Si aucune option n'est indiquee (ou si c'est l'option
hard qui a ete choisie), les requetes NFS sont retentees
indefiniment. Si par contre l'option soft a ete choisie,
le client NFS levera un echec apres l'envoi de retrans
retransmissions, entrainant alors le retour d'une erreur
a l'application appelante.
NB : Un delai expire << soft >> peut provoquer dans
certains cas des erreurs de donnees non signalees. C'est
pourquoi l'option soft doit etre utilisee uniquement si
la reactivite du client est plus importante que
l'integrite des donnees. L'utilisation de NFS avec TCP
ou l'augmentation de la valeur de l'option retrans peut
diminuer les risques lies a l'utilisation de l'option
soft.
timeo=n Temps d'attente (en dixiemes de seconde) du client NFS
avant de re-emettre la requete NFS. Si cette option
n'est pas definie, les requetes sont re-emises toutes
les 60 secondes dans le cas de NFS sur TCP. Le client
NFS ne fait aucune verification du delai d'expiration
dans le cas de NFS sur TCP.
Cependant, dans le cas de NFS sur UDP, le client utilise
un algorithme evolutif pour estimer la valeur appropriee
de depassement de temps (<< timeout >>) pour les types
de requetes frequemment utilisees (les requetes READ et
WRITE par exemple), mais utilise le reglage timeo pour
les requetes moins courantes (comme FSINFO). Si l'option
timeo n'est pas definie, les types de requetes moins
courantes sont re-emises apres 1,1 secondes. Apres
chaque re-emission, le client NFS double la valeur de
depassement de temps pour cette requete, jusqu'a
atteindre un maximum de 60 secondes.
retrans=n Nombre de tentatives de re-emission de la requete avant
que le client NFS n'enclenche une action de
recuperation. Si l'option retrans n'est pas definie, le
client NFS essaye chaque requete trois fois.
Le client NFS genere un message << le serveur ne repond
pas >> apres retrans tentatives, puis enclenche la
recuperation (qui depend de l'activation de l'option
hard de mount).
rsize=n Nombre maximum d'octets pour chaque requete reseau en
LECTURE que peut recevoir le client NFS lorsqu'il lit
les donnees d'un fichier sur le serveur NFS. La taille
reelle de la charge utile de donnees pour chaque requete
NFS en LECTURE est plus petite ou egale au reglage
rsize. La plus grande charge utile geree par le client
NFS Linux est de 1 048 576 octets (un mega-octet).
La valeur de rsize est un entier positif multiple de
1024. Les valeurs de rsize inferieures a 1024 sont
remplacees par 4096, et celles superieures a 1 048 576
sont remplacees par 1 048 576. Si la valeur indiquee est
bien dans la plage geree, mais qu'elle n'est pas un
multiple de 1024, elle sera arrondie au multiple de 1024
inferieur le plus proche.
Si la valeur de rsize n'est pas definie, ou si la valeur
de rsize depasse le maximum qu'a la fois le client et le
serveur peuvent gerer, le client et le serveur negocient
la plus grande valeur de rsize qu'ils puissent gerer
ensemble.
L'option rsize de mount telle qu'elle a ete definie sur
la ligne de commande lors du mount(8) apparait dans le
fichier /etc/mtab. D'autre part, la valeur reelle de
rsize negociee entre le client et le serveur est
indiquee dans le fichier /proc/mounts.
wsize=n Nombre maximum d'octets par requete d'ECRITURE reseau
que le client NFS peut envoyer quand il ecrit des
donnees dans un fichier sur un serveur NFS. La taille
reelle de la charge utile de donnees pour chaque requete
NFS en ECRITURE est plus petite ou egale au reglage
wsize. La plus grande charge utile geree par le client
NFS Linux est de 1 048 576 octets (un mega-octet).
Comme pour rsize, la valeur de wsize est un entier
positif multiple de 1024. Les valeurs de wsize
inferieures a 1024 sont remplacees par 4096, et celles
superieures a 1 048 576 par 1 048 576. Si la valeur
definie est bien dans l'etendue valide mais qu'elle
n'est pas multiple de 1024, elle est arrondie au
multiple de 1024 inferieur le plus proche.
Si la valeur de wsize n'est pas definie, ou si la valeur
wsize indiquee est superieure au maximum que soit le
client soit le serveur peut gerer, le client et le
serveur negocient la plus grande valeur de wsize qu'ils
peuvent tous les deux gerer.
L'option wsize de mount telle qu'elle a ete indiquee sur
la ligne de commande du mount(8) apparait dans le
fichier /etc/mtab. D'autre part, la valeur reelle de
wsize negociee par le client et le serveur est indiquee
dans le fichier /proc/mounts.
ac / noac Definir si le client peut memoriser (cache) les
attributs des fichiers. Si aucune option n'est indiquee
(ou si c'est ac qui est choisi), le client memorise les
attributs des fichiers.
Afin d'ameliorer les performances, les clients NFS
memorisent (mettent en cache) les attributs des
fichiers. Toutes les quelques secondes, un client NFS
verifie les attributs de chaque fichier de la version du
serveur afin de se mettre a jour. Les modifications qui
interviennent pendant ces petits intervalles restent
inapercues tant que le client n'a pas relance sa
verification sur le serveur. L'option noac empeche la
memorisation des attributs de fichiers par le client, ce
qui permet aux applications de detecter plus rapidement
les modifications des fichiers sur le serveur.
En plus d'empecher le client de memoriser les attributs
des fichiers, l'option noac force l'ecriture
synchronisee pour les applications afin que les
modifications sur un fichier soient immediatement
visibles sur le serveur. De cette facon, les autres
clients peuvent rapidement detecter les nouvelles
ecritures lors de la verification des attributs du
fichier.
L'usage de l'option noac offre une plus grande coherence
du cache aux clients NFS qui accedent aux memes
fichiers, mais au prix d'une penalisation significative
des performances. C'est pour cette raison qu'une
utilisation judicieuse des blocages (locking) de
fichiers est de preference recommandee. La section
COH'ERENCE DES DONN'EES ET DES M'ETA-DONN'EES contient une
presentation detaillee de ces approches.
acregmin=n Fixer (en secondes) la duree minimale de memorisation
(cache) des attributs d'un fichier normal avant leur
actualisation depuis le serveur. La valeur par defaut
est de 3 secondes, si cette option n'est pas definie.
acregmax=n Fixer (en secondes) la duree maximale de memorisation
(cache) des attributs d'un fichier normal avant leur
actualisation depuis le serveur. La valeur par defaut
est de 60 secondes, si cette option n'est pas definie.
acdirmin=n Fixer (en secondes) la duree minimale de memorisation
(cache) des attributs d'un repertoire avant leur
actualisation depuis le serveur. La valeur par defaut
est de 30 secondes, si cette option n'est pas definie.
acdirmax=n Fixer (en secondes) la duree maximale de memorisation
(cache) des attributs d'un repertoire avant leur
actualisation depuis le serveur. La valeur par defaut
est de 60 secondes, si cette option n'est pas definie.
actimeo=n L'utilisation de actimeo fixe toutes les durees
acregmin, acregmax, acdirmin et bacdirmax a la meme
valeur. Si cette option n'est pas definie, le client
utilisera les valeurs par defaut de chacune des options,
telles que decrites ci-dessus.
bg / fg Determine le comportement de la commande mount(8) dans
le cas d'un echec d'une tentative de montage d'un
partage. L'option fg entraine l'arret de mount(8) avec
un statut d'erreur si la moindre partie de la requete de
montage depasse le temps alloue ou echoue d'une
quelconque autre maniere. C'est ce que l'on appelle le
montage en << premier plan (foreground) >>, et c'est le
comportement par defaut si ni fg ni bg n'est indique.
Si l'option bg est indiquee, un depassement du temps
alloue (timeout) ou un echec entrainera la creation d'un
fils (fork) qui continuera a essayer de monter le
partage. Le pere s'interrompt immediatement en renvoyant
un code de sortie a zero. C'est ce que l'on appelle le
montage en << arriere-plan (background) >>.
Si le repertoire servant de point de montage local
n'existe pas, la commande mount(8) se comporte comme si
la requete etait restee sans reponse (timeout). Cela
permet aux montages NFS imbriques definis dans
/etc/fstab de s'executer dans n'importe quel ordre lors
de l'initialisation du systeme, meme si certains
serveurs NFS ne sont pas encore disponibles. On peut
aussi gerer ces problemes grace a un auto-monteur
(consultez automount(8) pour plus de details).
retry=n Fixer la duree, en minutes, pendant laquelle le montage
NFS sera tente par la commande mount(8), en arriere-plan
ou en avant-plan, avant d'abandonner. Si l'option n'est
pas definie, la valeur par defaut pour l'avant-plan est
de 2 minutes, et celle pour l'arriere-plan est
10 000 minutes, soit environ une semaine, a 80 minutes
pres. La commande mount(8) s'arretera des le premier
echec si on lui passe la valeur 0.
sec=mode Le type de securite RPCGSS a utiliser pour acceder aux
fichiers de ce point de montage. Si l'option sec n'est
pas definie, ou si sec=sys est choisie, le client NFS
utilise le type de securite AUTH_SYS pour toute requete
NFS sur ce point de montage. Les types de securite geres
sont none, krb5, krb5i, krb5p, lkey, lkeyi, lkeyp, spkm,
spkmi et spkmp. Consultez la section CONSID'ERATIONS DE
S'ECURIT'E.
sharecache / nosharecache
Determiner comment le client partage ses caches de
donnees et d'attributs de fichiers lorsqu'un meme
partage est monte plus d'une fois en meme temps.
L'utilisation d'un seul cache reduit les besoins en
memoire sur le client et presente aux applications un
contenu identique lorsque le meme fichier partage est
accede via differents points de montage.
Si aucune des options n'est indiquee, ou si l'option
sharecache est demandee, un seul cache est utilise pour
tous les points de montage qui accedent au meme partage.
Si l'option nosharecache est indiquee, ce point de
montage obtient un cache unique. Notez que lorsque les
caches des donnees et des attributs sont partages, les
options de montage du premier point de montage
s'appliquent pour les futurs montages concurrents de ce
meme partage.
En ce qui concerne le noyau 2.6.18, le comportement
defini par nosharecache est le comportement historique
normal. Ceci est considere comme dangereux pour les
donnees puisque de multiples copies memorisees du meme
fichier sur le meme client peuvent se desynchroniser
suite a une mise a jour locale d'une des copies.
resvport / noresvport
Indique si le client NFS doit utiliser un port source
privilegie quand il communique avec un serveur NFS pour
ce point de montage. Si cette option n'est pas precisee,
ou si l'option resvport est precisee, le client NFS
utilise un port source privilegie. Si l'option
noresvport est activee, le client NFS utilise un port
source non privilegie. Cette option est permise par les
noyaux 2.6.28 et suivants.
Utiliser un port source non privilegie permet
d'augmenter le nombre maximum de points de montages
permis par client, mais les serveurs NFS doivent etre
configures pour permettre la connexion de client par des
ports sources non privilegies.
Merci de vous referer a la section CONSID'ERATIONS DE
S'ECURIT'E pour d'importants details.
lookupcache=mode
Precise comment le noyau s'occupe du cache des entrees
de repertoire pour un point de montage donne. mode peut
etre all, none, pos ou positive. Cette option est prise
en charge par les noyaux 2.6.28 et suivants.
Le client NFS Linux garde en cache tous les resultats
des requetes NFS LOOKUP. Si le repertoire indique existe
sur le serveur, le resultat renvoye est positif
(<< positive >>), sinon c'est n'egatif (<< negative >>).
Si cette option n'est pas precisee, ou si all est
precise, le client suppose que les deux types de cache
repertoires sont valides jusqu'a ce que le cache de leur
repertoire parent expire.
Si pos ou positive est precise, le client suppose que
les entrees positives sont valides jusqu'a ce que le
cache de leur repertoire parent expire, mais valide les
entrees negatives avant qu'une application les utilise.
Si none est precise, le client valide a nouveau les deux
types de cache d'entrees repertoires avant qu'une
application puisse les utiliser. Cela permet une
detection rapide des fichiers qui ont ete crees ou
supprimes par d'autres clients, mais peut avoir des
repercussions sur ces applications et les performances
du serveur.
La partie COH'ERENCE DES DONN'EES ET DES M'ETA-DONN'EES
contient un propos detaille sur ces echanges.
Options valides pour le syst`eme de fichiers nfs
Utilisez ces options ainsi que les options de la sous-section
precedente pour monter des systemes de fichiers de type nfs.
proto=idreseau Le nom et la famille du protocole de transport
qu'utilise le client NFS pour transmettre ses requetes
au serveur NFS pour ce point de montage. Si un serveur
NFS a en meme temps une adresse IPv4 et une IPv6,
l'utilisation d'un identifiant reseau idreseau
entrainera le choix d'IPv4 ou d'IPv6 pour communiquer
avec ce serveur.
Si la prise en charge de TI-RPC est compilee dans la
commande mont.nfs, idreseau est un identifiant reseau
valide liste dans /etc/netconfig. Sinon idreseaupeut
valoir << tcp >>, << udp >> ou << rdma >> et IPv4 sera
utilise.
Chaque protocole de transport utilise differents
reglages de retransmission et de timeo. Merci de vous
referer a la description de ces deux options de montage
En plus de controler la facon dont le client NFS
transmet les requetes au serveur, cette option de mount
gere aussi la facon dont la commande mount(8) communique
avec les services rpcbind et mountd du serveur. Indiquer
un id reseau qui utilise TCP entraine l'utilisation de
TCP par tout le trafic passant par la commande mount(8)
ou le client NFS. Reciproquement, indiquer UDP entraine
l'utilisation d'UDP par tout le trafic.
Si l'option proto de mount n'est pas definie, la
commande mount(8) decouvrira quels protocoles sont
acceptes par le serveur et choisira un transport
approprie pour chacun des services. Consultez la section
M'ETHODES DE TRANSPORT pour plus de details.
udp L'option udp est une variante pour proto=udp, compatible
avec d'autres systemes d'exploitation.
tcp L'option tcp est une variante pour proto=tcp, compatible
avec d'autres systemes d'exploitation.
port=n Valeur numerique du port du service NFS sur le serveur.
Si le service NFS du serveur n'est pas accessible sur le
port indique, la requete de montage echoue.
Si cette option n'est pas definie, ou si le port indique
est 0, le client NFS utilise le numero du port du
service NFS publie par le service rpcbind du serveur. La
requete de montage echoue si le service rpcbind du
serveur n'est pas accessible, si le service NFS du
serveur n'est pas enregistre dans son service rpcbind,
ou si le service NFS du serveur n'est pas accessible sur
le port publie.
mountport=n Valeur numerique du port de mountd sur le serveur. Si le
service mountd du serveur n'est pas present sur le port
indique, la requete de montage echoue.
Si cette option n'est pas definie, ou si le port indique
est 0, la commande mount(8) utilise le numero du port du
service mountd publie par le service rpcbind du serveur.
La requete de montage echoue si le service rpcbind du
serveur n'est pas accessible, si le service mountd du
serveur n'est pas enregistre dans son service rpcbind,
ou si le service mountd du serveur n'est pas accessible
sur le port publie.
Cette option peut etre utilisee pour les montages sur un
serveur NFS a travers un pare-feu qui bloque le
protocole rpcbind.
mountproto=idreseau
Le nom et la famille du protocole de transport que le
client NFS utilise pour transmettre ses requetes au
service mountd d'un serveur NFS quand il lance cette
requete de montage, puis quand il demontera ensuite ce
montage.
Si la prise en charge pour TI-RPC est compilee dans la
commande mount.nfs, idreseau peut etre un identifiant
reseau valide parmi ceux listes dans /etc/netconfig.
Sinon, idreseau doit valoir << tcp >> ou << udp >>, et
IPv4 sera utilise.
Cette option peut etre utilisee pour monter un serveur
NFS a travers un pare-feu qui bloque des transferts
specifiques. Utilise avec l'option proto, differents
modes de transfert peuvent etre choisis pour les
requetes vers mountd et NFS. Si le serveur ne propose
pas de service pour le mode indique, la requete de
montage echoue.
Merci de vous reporter a la partie M'ETHODES DE TRANSPORT
pour plus de renseignement sur la maniere dont l'option
de montage mountproto interagit avec l'option proto.
mounthost=nom Le nom d'hote de la machine qui execute le mountd. Si
cette option n'est pas definie, la commande mount(8)
considere que le service mountd est assure par la
machine qui offre le service NFS.
mountvers=n Numero de version des RPC utilise pour contacter le
mountd du serveur. Si cette option n'est pas definie, le
client utilise un numero de version approprie a la
version du NFS contacte. Cette option est utile quand de
nombreux services NFS sont offerts par un seul et meme
serveur.
namlen=n La taille maximum du nom du chemin composant ce montage.
Si cette option n'est pas definie, la taille maximum est
negociee avec le serveur. Dans la plupart des cas, cette
taille maximum est 255 caracteres.
Des versions precedentes de NFS ne gerent pas cette
negociation. L'utilisation de cette option garantit que
pathconf(3) donnera bien la longueur maximum aux
applications pour ces versions.
nfsvers=n Le numero de version du protocole NFS utilise pour
contacter le service NFS du serveur. Le client NFS de
Linux gere les versions 2 et 3 du protocole NFS
lorsqu'il utilise un systeme de fichiers de type nfs. Si
le serveur ne gere pas la version demandee, la requete
de montage echoue. Si cette option n'est pas definie, le
client tente l'utilisation de la version 3, puis negocie
la version NFS avec le serveur si la gestion de la
version 3 n'est pas disponible.
vers=n Cette option est une variante pour l'option nfsvers,
compatible avec d'autres systemes d'exploitation.
lock / nolock Indiquer s'il faut utiliser le protocole auxiliaire NLM
pour verrouiller les fichiers sur le serveur. Si aucune
option n'est indiquee (ou si c'est lock qui est choisi),
le verrouillage NLM est active pour ce point de montage.
Si on utilise l'option nolock, les applications peuvent
verrouiller les fichiers, mais ces verrous n'ont de
portee que pour les applications qui tournent sur ce
meme client. Les applications distantes ne sont pas
informees de ces verrous.
Le blocage NLM doit etre desactive lors de l'utilisation
de l'option nolock si /var est monte via NFS, parce que
/var contient des fichiers utilises par l'implementation
de NLM sous Linux. L'usage de nolock est aussi requis
lors des montages de partages de serveurs NFS ne gerant
pas le protocole NLM.
intr / nointr Indiquer si les signaux peuvent interrompre les
operations sur le fichier pour ce point de montage. Si
aucune option n'est indiquee (ou si nointr est choisi),
les signaux n'interrompent pas les operations NFS sur
les fichiers. Si intr est indique, les appels systemes
renvoient EINTR si une operation NFS en cours est
interrompue par un signal.
L'utilisation de l'option intr est preferable a celle de
l'option soft car le risque de corruption des donnees
est moins important.
Les options de montage intr/ nointr sont obsoletes pour
des noyaux ulterieurs au 2.6.25. Seul un signal de
terminaison SIGKILL peut interrompre une operation NFS
en cours sur ces noyaux, et, si precisee, cette option
est ignoree pour assurer une compatibilite ascendante
sur des anciens noyaux.
cto / nocto Indiquer s'il faut utiliser la semantique de coherence
de cache close-to-open. Si aucune option n'est indiquee
(ou si c'est cto qui est choisi), le client utilise la
semantique de coherence de cache close-to-open. Si c'est
l'option nocto qui est choisie, le client utilise une
heuristique non standard pour savoir quand les fichiers
ont change sur le serveur.
L'utilisation de l'option nocto peut ameliorer les
performances des montages en lecture seule, mais devrait
etre limitee au cas ou les donnees sur le serveur ne
changent qu'occasionnellement. La section COHERENCE DES
DONNEES ET DES META-DONNEES expose le comportement de
cette option en details.
acl / noacl Indiquer s'il faut utiliser le protocole auxiliaire
NFSACL sur ce point de montage. Le protocole auxiliaire
NFSACL est un protocole proprietaire mis en uvre dans
Solaris et qui gere les listes de controle d'acces (les
ACLs). NSFACL n'est jamais devenu un element standard de
la specification du protocole NFS.
Si ni acl ni noacl ne sont precisees, le client NFS
negocie avec le serveur afin de savoir si le protocole
NFSACL est actif, et l'utilise dans ce cas. La
desactivation du protocole auxiliaire NFSACL est parfois
rendu necessaire quand la negociation pose des problemes
sur le client ou sur le serveur. Consultez la section
CONSID'ERATIONS DE S'ECURIT'E pour plus de details.
rdirplus / nordirplus
Indiquer s'il faut utiliser les requetes READDIRPLUS de
NFS version 3. Si cette option n'est pas definie, le
client NFS utilisera les requetes READDIRPLUS sur les
montages en NFS version 3 pour la lecture des petits
repertoires. Certaines applications sont plus efficaces
si le client n'utilise que des requetes READDIR pour
tous les repertoires.
Options valides pour le syst`eme de fichiers nfs4
Utilisez ces options ainsi que les options de la premiere sous-section
ci-dessus pour monter des systemes de fichiers de type nfs4.
proto=idreseau Le nom et la famille du protocole de transport
qu'utilise le client NFS pour transmettre ses requetes
au serveur NFS pour ce point de montage. Si un serveur
NFS a en meme temps une adresse IPv4 et une IPv6,
l'utilisation d'un identifiant reseau idreseau
entrainera le choix d'IPv4 ou d'IPv6 pour communiquer
avec ce serveur.
Si la prise en charge pour TI-RPC est compilee dans la
commande mount.nfs, idreseau peut etre un identifiant
reseau valide parmi ceux listes dans /etc/netconfig.
Sinon, idreseau doit valoir << tcp >> ou << udp >>, et
IPv4 sera utilise.
Les serveurs NFS version 4 doivent respecter TCP, donc
si cette option n'est pas precisee, le client NFS
utilise le protocole TCP. Merci de vous referer a la
section M'ETHODES DE TRANSPORT pour plus de details.
port=n Valeur numerique du port du service NFS sur le serveur.
Si le service NFS du serveur n'est pas accessible sur le
port indique, la requete de montage echoue.
Si cette option de montage n'est pas definie, le client
NFS utilisera le numero de port standard de NFS (2049)
sans verifier de prime abord le service rpcbind du
serveur. Cette option permet a un client NFS version 4
de contacter un serveur NFS version 4 a travers un
pare-feu qui bloquerait les requetes rpcbind.
Si la valeur du port indiquee est 0, le client NFS
utilisera le numero de port du service NFS publie par le
service rpcbind du serveur. La requete de montage
echouera si le service rpcbind du serveur n'est pas
disponible, si le service NFS du serveur n'est pas
enregistre dans son service rpcbind, ou si le service
NFS du serveur n'est pas accessible sur le port publie.
intr / nointr Indiquer si les signaux peuvent interrompre les
operations sur les fichiers pour ce point de montage. Si
aucune option n'est indiquee (ou si intr est choisi),
les appels systemes renvoient EINTR si une operation NFS
en cours est interrompue par un signal. Si nointr est
indique, les signaux n'interrompent pas les operations
NFS.
L'utilisation de l'option intr est preferable a celle de
l'option soft car le risque de corruption des donnees
est moins important.
Les options de montage intr/ nointr sont obsoletes pour
des noyaux ulterieurs au 2.6.25. Seul un signal de
terminaison SIGKILL peut interrompre une operation NFS
en cours sur ces noyaux, et, si precisee, cette option
est ignoree pour assurer une compatibilite ascendante
sur des anciens noyaux.
cto / nocto Indiquer s'il faut utiliser la semantique de coherence
du cache close-to-open pour les repertoires NFS de ce
point de montage. Si ni cto ni nocto ne sont indiquees,
la semantique de coherence du cache close-to-open sera
utilise par defaut pour les repertoires.
La politique de mise en cache des donnees des fichiers
n'est pas concernee par cette option. La section
COH'ERENCE DES DONN'EES ET DES M'ETA-DONN'EES decrit le
comportement de cette option en details.
clientaddr=n.n.n.n
Indiquer une seule adresse IPv4 en quatre parties
separees par des points, ou une adresse IPv6 qui n'est
pas un lien local. Le client NFS signalera alors que les
serveurs peuvent envoyer des requetes NFSv4 de rappel
sur les fichiers de ce point de montage. Si le serveur
ne peut pas etablir de connexion de rappel
(<< callback >>) sur ces clients, les performances
peuvent etre degradees ou les acces a ces fichiers
temporairement suspendus.
Si cette option n'est pas indiquee, la commande mount(8)
essaie de decouvrir automatiquement une adresse de
rappel (<< callback >>) appropriee. La procedure de
decouverte automatique n'est cependant pas parfaite.
Dans le cas d'interfaces reseau multiples, de directives
de routages speciales ou de typologie reseau atypique,
l'adresse exacte a utiliser pour les rappels peut ne pas
etre triviale a determiner.
FICHIER DE CONFIGURATION DU MONTAGE
Si la commande de montage est configuree pour, toutes les options de
montage decrites dans la section precedente peuvent etre configurees
dans le fichier /etc/nfsmount.conf. Referez-vous a nfsmount.conf(5)
pour plus de details.
EXEMPLES
Pour realiser le montage d'un partage en NFS version 2, il faut
preciser que le type du systeme de fichiers est nfs et indiquer
l'option de montage nfsvers=2. Pour realiser un montage en NFS
version 3, il faut preciser que le type du systeme de fichiers est nfs
et indiquer l'option de montage nfsvers=3. Pour realiser un montage en
NFS version 4, il faut preciser que le type du systeme de fichiers est
nfs4. L'option de montage nfsvers n'est alors pas accepte.
L'exemple de fichier /etc/fstab qui suit permet a la commande mount de
negocier des valeurs par defaut convenables pour le comportement NFS.
server:/export /mnttnfstdefaults 0 0
Voici un exemple, issu du fichier /etc/fstab, concernant un montage NFS
version 2 en UDP.
server:/export /mnttnfstnfsvers=2,proto=udp 0 0
Essayez cet exemple afin de realiser un montage NFS version 4 en TCP,
utilisant l'authentification reciproque de Kerberos 5.
server:/export /mnttnfs4 sec=krb5 0 0
Cet exemple peut servir a realiser le montage de /usr grace a NFS.
server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
Cet exemple montre comment utiliser une adresse brute non locale IPv6.
[fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
M'ETHODES DE TRANSPORT.
Les clients NFS envoient leurs requetes aux serveurs NFS grace aux
appels de procedures distantes (<< Remote Procedure Calls >>), les
RPCs. Le client RPC decouvre automatiquement les entrees du service
distant, gere l'authentification requete par requete, ajuste les
parametres des requetes afin de gerer l'ordre des octets sur le client
et le serveur (<< endianess >>), et se charge de la retransmission des
requetes qui pourraient s'etre perdues dans le reseau ou sur le
serveur. Les requetes et les reponses RPC circulent sur un protocole de
transport reseau.
Dans la plupart des cas, la commande mount(8), le client NFS et le
serveur NFS peuvent negocier automatiquement les valeurs adequates de
taille pour les transferts de donnees et de transport pour un point de
montage. Cependant, dans certains cas, il peut etre efficace d'indiquer
explicitement ces valeurs grace aux options de montage.
Anciennement, les clients NFS se servaient uniquement du transport UDP
pour transmettre des requetes aux serveurs. Bien que son implementation
soit simple, NFS sur UDP a de nombreuses limitations qui l'empechent
d'obtenir de bonnes performances et un fonctionnement fluide dans
certains environnements de deploiement courants. Un taux de paquets
perdus meme insignifiant entraine la perte de requetes NFS completes.
On regle alors generalement le delai de depassement (<< timeout >>) a
une valeur inferieure a la seconde afin que les clients puissent
recuperer rapidement en cas de requetes rejetees. Cela peut entrainer
une surcharge du trafic reseau et du serveur.
Cependant, UDP peut etre assez efficace grace a des reglages
specifiques lorsque le MTU du reseau depasse la taille de transfert de
donnees de NFS (par exemple dans les environnements reseau qui
utilisent les trames Ethernet Jumbo). Dans ces cas, il est judicieux
d'adapter les reglages rsize et wsize de facon a ce que chaque requete
de lecture ou d'ecriture NFS soit contenue dans quelques trames du
reseau (voire meme dans une seule trame). Cela reduit la probabilite
qu'une perte d'une simple trame reseau de la taille de la MTU entraine
la perte complete d'un grande requete en lecture ou ecriture.
TCP est le protocole de transport utilise par defaut dans toutes les
implementations modernes de NFS. Il est efficace dans pratiquement tous
les environnements reseau concevables et offre d'excellentes garanties
contre la corruption de donnees que pourrait entrainer un incident
reseau. TCP est souvent requis pour acceder a un serveur a travers un
pare-feu.
Dans des conditions normales, les reseaux rejettent des paquets bien
plus souvent que les serveurs NFS ne rejettent de requetes. C'est
pourquoi un reglage agressif de delai de depassement (<< time-out >>)
de retransmission pour NFS sur TCP est inutile. Les reglages habituels
de delai de depassement pour NFS sur TCP varient entre une et dix
minutes. Apres qu'un client a termine ses retransmissions (la valeur de
l'option retrans de mount), il considere que le reseau a subi une panne
et tente de se reconnecter au serveur grace a une nouvelle interface de
connexion (<< socket >>). Puisque TCP fiabilise le transport de donnees
sur le reseau, rsize et wsize peuvent en toute securite permettre par
defaut la plus grande valeur geree a la fois par le client et par le
serveur, independamment de la taille du MTU du reseau.
Utilisation de l'option de montage mountproto
Cette section s'applique uniquement aux versions 2 et 3 du protocole
mount car NFS 4 n'utilise pas un protocole de montage separe.
Le client Linux peut utiliser differents modes de transfert pour
contacter le service rpcbind d'un serveur, son service mountd, son
gestionnaire de verrou reseau (NLM) et son service NFS. Le mode de
transport utilise par le client NFS de Linux pour chaque point de
montage depend des options passees a mount, qui incluent proto,
mountproto udp et tcp.
Le client envoie des notifications au gestionnaire reseau de statut
(NSM : << network status manager >>) via UDP, quel que soit le mode de
transfert precise. Il ecoute cependant les notifications NSM du serveur
a la fois sur UDP et TCP. Le protocole gerant la liste de controle
d'acces a NFS (NFACL : << nfs access control list >>) utilise le meme
mode de transfert que le service NFS principal.
Si aucune option n'est precisee quant au mode de transfert, le client
NFS Linux utilise UDP pour contacter le service mountd du server, et
TCP pour contacter ses services NLM et NFS par defaut.
Si le serveur ne gere pas ces modes de transfert pour ces services, la
commande mount(8) essaye de trouver quel mode est pris en charge par le
serveur, et essaye une fois de se reconnecter avec ce mode. Si le
serveur ne propose aucun mode gere par le client ou est mal configure,
la requete de montage echoue. Si l'option bg a ete passee, la commande
mount passe en arriere-plan et continue d'essayer la requete de montage
demandee.
Quand l'une des options proto, udp ou tcp est passee mais que
mountproto ne l'est pas, le mode de transfert demande est utilise a la
fois pour contacter le service mountd du serveur et ses services NLM et
NFS.
Si l'option mountproto est passee mais que ni proto, ni udp et ni tcp
n'est passee alors le mode demande est utilise pour la requete mount
initiale, mais la commande mount essaye de decouvrir quel mode de
transfert est pris en charge pour le protocole NFS, et preferera TCP si
les deux modes sont implementes.
Si mountproto et proto (ou udp ou tcp) sont passes en meme temps, le
mode de transport indique a l'option mountproto est utilise pour la
requete initiale de mountd, et le mode indique a proto (ou udp ou tcp)
est utilise pour NFS, quel que soit l'ordre de ces options. Le
programme ne cherchera pas a trouver les services si ces options sont
donnees.
Si l'une des options proto, udp, tcp ou mountproto est passee plus
d'une fois dans une meme commande, alors la valeur retenue sera celle
la plus a droite.
COH'ERENCE DES DONN'EES ET DES M'ETA-DONN'EES
Certains systemes de fichiers en grappes (cluster) recents offrent une
coherence absolue du cache a leurs clients. La coherence parfaite de
cache aux clients NFS << disparates >> est difficile a obtenir, surtout
sur les reseaux de grandes tailles (WAN). Dans ce cas, NFS est regle
pour la plus faible coherence de cache qui satisfait les contraintes de
la plupart des types de partage de fichiers. Habituellement, le partage
de fichiers est totalement sequentiel : le premier client A ouvre un
fichier, ecrit quelque chose dedans, puis le ferme. Ensuite, un client
B ouvre ce meme fichier, puis lit les modifications.
Coh'erence de cache << close-to-open >>
Quand une application ouvre un fichier stocke sur un serveur NFS, le
client NFS verifie qu'il existe toujours sur le serveur et que
l'utilisateur qui ouvre ce fichier en a bien le droit, grace a des
requetes GETATTR ou ACCESS. Quand l'application ferme le fichier, le
client NFS ecrit toutes les modifications en attente afin que le
prochain a ouvrir ce fichier puisse en voir les changements. Cela donne
l'opportunite au client NFS de prevenir l'application de toute erreur
en ecriture sur le serveur, via le code de retour de close(2). Ce
systeme de verification a l'ouverture et de purge a la fermeture est
connu sous le nom de coherence de cache << close-to-open >>
(close-to-open cache consistency).
Faible coh'erence de cache
Il y a toujours des cas dans lesquels le cache de donnees du client
contient des donnees incoherentes. Dans la version 3 du protocole NFS
est apparu la << faible coherence de cache >> (appelee aussi WCC),
offrant une methode efficace de verification des attributs d'un fichier
avant et apres une requete unique. Cela permet a un client une
meilleure perception des modifications qui ont pu etre realisees par
les autres clients.
Quand un client genere beaucoup d'operations concomitantes qui
modifient le meme fichier au meme moment (par exemple grace a des
ecritures asynchrones en arriere-plan), il est difficile de savoir si
le fichier a ete modifie par ce client ou par un autre.
M'emorisation (cache) des attributs
L'utilisation de l'option noac de mount permet de realiser la coherence
de la memorisation (cache) des attributs pour de multiples clients.
Pratiquement toutes les operations de systeme de fichiers verifient les
informations d'attributs de fichiers. Le client garde cette information
en memoire (cache) pendant un certain temps afin de reduire la charge
du serveur et du reseau. Quand noac est activee, le cache des attributs
de fichier est desactive sur le client et chaque operation qui doit
verifier les attributs des fichiers doit imperativement s'adresser au
serveur. Ceci permet au client de voir rapidement les modifications sur
un fichier, en contrepartie d'une augmentation importante des
operations reseaux.
Soyez attentif a ne pas confondre l'option noac avec << pas de
memorisation de donnees (no data caching) >>. L'option noac de mount
empeche la mise en cache par le client des meta-donnees du fichier,
mais il existe toujours des cas dans lesquels des incoherences de
donnees cachees peuvent survenir entre le client et le serveur.
Le protocole NFS n'a pas ete concu pour gerer la coherence absolue des
caches pour des grappes (clusters) de systemes de fichiers sans qu'il
soit necessaire d'utiliser des types particuliers de serialisation au
niveau applicatif. Si la coherence absolue du cache est necessaire aux
clients, les applications devront utiliser le verrouillage de fichiers
(file locking). D'autre part, les applications pourront aussi utiliser
le drapeau O_DIRECT lors de l'ouverture des fichiers afin de desactiver
totalement la mise en cache des donnees.
Mettre en cache les entr'ees r'epertoires
Le client NFS Linux garde en cache les resultats d'une requete NFS
LOOKUP. Si la requete pointe sur un repertoire existant sur le serveur,
le resultat sera note positif. Sinon, si le repertoire n'existe pas
(c'est-a-dire si le serveur retourne ENOENT), le resultat sera note
n'egatif.
Afin de detecter l'ajout ou la suppression de repertoires sur le
serveur, le client NFS Linux regarde la date de modification
(<< mtime >>) du repertoire. Si le client detecte un changement dans
cette date, le client supprime tous les resultats LOOKUP encore en
cache concernant ce repertoire. Comme la date de modification est un
attribut conserve en cache, il est possible qu'un peu de temps se passe
avant que le client remarque le changement. Referez-vous aux
descriptions des options de montage acdirmin, acdirmax et noac pour
plus d'information quant a la maniere dont le temps de modification est
mis en cache.
Mettre en cache les entrees des repertoires ameliore les performances
des applications qui ne partagent pas de fichiers avec des applications
sur un autre client. L'utilisation d'informations en cache sur des
repertoires, cependant, peut interferer avec des applications qui
tournent simultanement sur de nombreux clients et qui doivent detecter
rapidement la creation ou la suppression de fichiers. L'option de
montage lookupcache permet de personnaliser certains comportements de
mise en cache de repertoires.
Avant la version 2.6.28 du noyau, le client NFS Linux cherchait
uniquement les resultats de recherches positifs. Cela permettait aux
applications de detecter rapidement de nouvelles entrees de repertoires
creees par d'autres clients, tout en fournissant une partie des
benefices dus a la mise en cache. Si une application depend de cet
ancien comportement, vous pouvez utiliser l'option
lookupcache=positive.
Si le client ignore son cache et valide toutes les requetes de
recherche avec le serveur, il peut alors detecter immediatement toute
creation ou suppression de repertoire par un autre client. Vous pouvez
forcer ce comportement avec l'option lookupcache=none. L'absence de
mise en cache des repertoires entraine une augmentation du nombre de
requetes NFS, et donc une perte de performances. Empecher la recherche
sur le cache devrait permettre une moindre perte au niveau des
performances que d'utiliser noac, et n'a aucun effet sur la maniere
dont le client NFS met en cache les attributs d'un fichier.
L'option de montage sync
Le client NFS gere l'option de montage sync differemment que d'autres
systemes de fichiers (consultez mount(8) pour une description generique
des options de montage sync et async). Si ni sync ni async ne sont
indiques (ou si l'option async est indiquee), le client NFS retarde
l'envoi au serveur des ordres d'ecriture des applications jusqu'a ce
que l'un de ces evenements survienne :
La saturation en memoire entraine une demande de ressources
memoire au systeme.
Une application met a jour (<< flush >>) les donnees d'un
fichier de maniere explicite avec sync(2), msync(2) ou fsync(3).
Une application ferme un fichier avec close(2).
Le fichier est verrouille/deverrouille grace a fcntl(2).
Autrement dit, dans les conditions normales d'utilisation, des donnees
ecrites par une application peuvent ne pas apparaitre instantanement
sur le serveur qui heberge le fichier.
Si l'option sync est precisee pour un point de montage, tout appel
systeme qui ecrit des donnees dans des fichiers de ce point de montage
entraine la purge des donnees sur le serveur avant de revenir en espace
utilisateur (<< user space >>). Cela offre une meilleure coherence du
cache des donnees, mais a un impact certain sur les performances.
Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin
que les ecritures d'un fichier precis soient immediatement prises en
compte par le serveur, et ce sans l'utilisation de l'option sync de
mount.
Utilisation des verrous de fichiers avec NFS
Le Gestionnaire de Verrous Reseaux (NLM, Network Lock Manager) est un
protocole auxiliaire separe servant a gerer les verrous sur les
fichiers dans les versions 2 et 3 de NFS. Pour gerer la recuperation
des verrous apres le redemarrage d'un client ou du serveur, un second
protocole (connu sous le nom de protocole Network Status Manager) est
necessaire. Dans la version 4 de NFS, le verrouillage des fichiers est
directement implante dans le protocole NFS, et les protocoles NLM et
NSM ne sont plus utilises.
Dans la plupart des cas, les services NLM et NSM sont demarres
automatiquement et aucune configuration additionnelle n'est requise. La
configuration en noms de domaine completement definis (FQDN) de tous
les clients NFS est necessaire pour permettre aux serveurs NFS de
retrouver leurs clients, afin de les prevenir en cas de redemarrage.
NLM ne gere que l'annonce de verrouillage de fichiers. Pour verrouiller
les fichiers NFS, il faut utiliser fcntl(2) avec les commandes F_GETL
et F_SETL. Le client NFS convertit les verrous de fichiers obtenus
grace a flock(2) en annonces de verrouillage.
Lors du montage de serveurs ne gerant pas le protocole NLM ou lorsqu'on
monte un serveur NFS a travers un pare-feu qui bloque le port du
service NLM, il faut utiliser l'option nolock de mount. Le verrouillage
NLM doit etre desactive grace a l'option nolock lorsqu'on utilise NFS
pour monter /var, puisque /var contient les fichiers utilises par NLM
dans son implementation sous Linux.
L'utilisation de l'option nolock est parfois conseillee pour ameliorer
les performances d'une application proprietaire qui ne tourne que sur
un seul client mais qui utilise intensement les verrous de fichiers.
Les caract'eristiques du cache de la version 4 de NFS.
Le comportement du cache des donnees et des meta-donnees des clients
NFS version 4 est identique a celui des precedentes versions.
Toutefois, la version 4 de NFS offre deux nouveaux dispositifs pour
ameliorer le comportement du cache : attributs de changement et
d'el'egation de fichier.
L'attribut de changement est un nouvel element des meta-donnees de
fichiers et de repertoires NFS qui enregistre les modifications des
donnees. Il se substitue a l'utilisation de l'horodatage des
modifications et changements du fichier pour offrir aux clients la
validation du contenu de leur cache. Cependant, ces attributs de
changement ne sont pas lies a la gestion de l'horodatage ni sur le
client ni sur le serveur.
La d'el'egation de fichier est un contrat qui lie un client NFS version 4
et le serveur, offrant temporairement au client le traitement d'un
fichier comme s'il etait le seul a y acceder. Le serveur s'engage a
prevenir le client (grace a une requete de rappel, ou << callback >>)
si un autre client tente d'acceder a ce meme fichier. Une fois qu'un
fichier a ete delegue a un client, ce client peut memoriser (mettre en
cache) les donnees et les meta-donnees de ce fichier de facon agressive
sans avoir a contacter le serveur.
Il y a deux types de delegations : lecture et 'ecriture. Une delegation
en lecture indique que le serveur avertira le client si d'autres
clients veulent ecrire dans ce fichier. Une delegation en 'ecriture
indique que le client sera prevenu des tentatives de lecture ou
d'ecriture.
Les serveurs offrent les delegations de fichier sitot qu'un fichier est
ouvert et peuvent annuler ces delegations n'importe quand des lors
qu'un autre client desire acceder a un fichier d'une maniere qui entre
en conflit avec les delegations deja attribuees. Les delegations de
repertoires ne sont pas gerees.
Afin de pouvoir gerer les alertes de delegations (<< delegation
callback >>), le serveur verifie le chemin retour vers le client au
moment du contact initial de celui-ci. Si le retour vers le client ne
peut pas etre etabli, le serveur n'attribue purement et simplement
aucune delegation a ce client.
CONSID'ERATIONS DE S'ECURIT'E.
Les serveurs NFS controlent l'acces aux donnees des fichiers, mais leur
offre de gestion de l'authentification des requetes NFS depend de leur
implementation des RPC. Les controles d'acces NFS traditionnels singent
les controles d'acces binaires standards offerts par les systemes de
fichiers locaux. L'authentification RPC traditionnelle utilise un
nombre pour representer chaque utilisateur (normalement l'uid propre a
cet utilisateur), un nombre pour representer le groupe de cet
utilisateur (le gid de l'utilisateur) et un ensemble d'au maximum 16
nombres de groupes additionnels pour representer les groupes auxquels
cet utilisateur peut appartenir.
Traditionnellement, les donnees du fichier et l'ID de l'utilisateur ne
sont pas chiffrees sur le reseau (en clair). Qui plus est, les versions
2 et 3 de NFS utilisent des protocoles auxiliaires separes pour le
montage, le verrouillage et le deverrouillage des fichiers, et pour
renvoyer les valeurs de retour systeme des clients et serveurs. Ces
protocoles auxiliaires n'utilisent pas d'authentification.
En plus d'avoir integre ces deux protocoles auxiliaires dans le
protocole NFS principal, la version 4 de NFS offre des formes plus
avancees de controle d'acces, d'authentification, et de protection lors
du transfert des donnees. La specification de la version 4 de NFS
requiert les ACLs NFSv4, l'authentification RPCGSS, et les diverses
securites RPCGSS permettant le controle d'integrite et le chiffrement
via RPC. Puisque la version 4 de NFS ajoute les fonctionnalites de ces
protocoles au cur du protocole NFS, les nouvelles caracteristiques de
securite s'appliquent a toutes les operations de NFS version 4,
incluant donc le montage, le verrouillage des fichiers, et ainsi de
suite. L'authentification RPCGSS peut aussi etre utilisee avec les
versions 2 et 3 de NFS, mais ne protege pas les protocoles associes.
L'option de montage sec indique que le mode de securite RPCGSS est
actif sur ce point de montage NFS. L'ajout de sec=krb5 fournit la
preuve chiffree de l'identite de l'utilisateur pour chaque requete RPC.
Ce dispositif offre une verification forte de l'identite des
utilisateurs qui accedent aux donnees du serveur. Notez que des
configurations supplementaires a cet ajout de l'option de mount sont
necessaires pour activer la securite Kerberos. Consultez la page de
manuel de rpc.gssd(8) pour plus de details.
Deux dispositifs additionnels de la securite Kerberos sont pris en
charge : krb5i et krb5p. Le dispositif de securite krb5i offre une
garantie de chiffrement fort contre la falsification des donnees pour
chaque requete RPC. Le dispositif de securite krb5p chiffre chaque
requete RPC afin d'eviter qu'elle soit exposee pendant son transfert
sur le reseau. Toutefois, le chiffrement ou la verification de
l'integrite entrainent des baisses de performance. La gestion similaire
d'autres formes de securites par chiffrement (telles que lipkey ou
SPKM3) sont aussi disponibles.
Le protocole NFS version 4 permet aux clients et aux serveurs la
negociation de multiples dispositifs de securite lors du processus de
montage. Cependant, Linux n'implemente pas encore une telle
negociation. Le client Linux indique un seul dispositif de securite au
moment du montage qui restera ensuite actif pour toute la duree du
montage. Si le serveur ne gere pas ce dispositif, la requete de montage
initiale est refusee par le serveur.
Utiliser un port source non privil'egi'e
Le client NFS communique normalement avec le serveur par des tuyaux
reseaux (network sockets). A chaque bout du tuyau est associe un port,
qui est un simple chiffre entre 1 et 65535, ce qui permet de distinguer
des tuyaux pointant sur la meme adresse IP. Un tuyau est identifie de
maniere unique par un n-uplet comprenant le protocole de passage (TCP
ou UDP) et les ports et adresses IP de chaque bout.
Le client NFS peut choisir n'importe quel port d'origine pour ses
tuyaux, mais il choisit en general un port privil'egi'e (ie avec une
valeur inferieure a 1024). Seul un processus tournant avec des droits
d'administrateur (root) peut creer un tuyau a partir d'un port
privilegie.
La fourchette des ports potentiellement choisis est configuree par une
paire de systcls pour eviter l'utilisation de ports bien connus, tel
celui de ssh. Cela signifie que le nombre de ports sources potentiels
pour le client NFS, et donc pour le nombre de connexions par tuyau
disponible a un moment donnee est en pratique de l'ordre d'une
centaine.
Comme decrit plus haut, le schema d'authentification NFS traditionnel
(connu sous le nom d'AUTH_SYS), compte sur l'envoi d'UID et de GID
locaux pour identifier les utilisateurs a l'origine de requetes. Un
serveur NFS suppose que si une connexion provient d'un port non
privilegie, les numeros UID et GID de la requete NFS ont deja ete
verifies par le noyau du client ou tout autre programme systeme local.
Ce systeme est facile a contourner, mais sur un reseau securise
d'ordinateurs de confiance, c'est parfaitement adapte.
En gros, un tuyau est utilise pour chaque point de montage NFS. Si un
client peut aussi utiliser un port source non privilegie, le nombre de
tuyaux autorises (et donc le nombre maximum de points de montages en
paralleles) sera beaucoup plus important.
Utiliser un port source non privilegie peut quelque peu compromettre la
securite du serveur, car n'importe quel utilisateur d'un point de
montage sur AUTH_SYS peut maintenant se faire passer pour un autre
comme source de la requete. C'est pourquoi les serveurs NFS ne le
prennent pas en charge par defaut. En regle generale, ils l'autorisent
explicitement a l'aide d'une option de partage.
Pour garder un bon niveau de securite tout en ouvrant un maximum de
points de montages, il est preferable d'autoriser les connexions
clients sur un port non privilegie seulement si le serveur et le client
utilisent tous deux une authentification forte, comme celle fournie par
Kerberos.
Montage `a travers d'un pare-feu
Un pare-feu peut se trouver entre un client NFS et le serveur, ou alors
le client ou le serveur peuvent bloquer certains de leurs propres ports
grace a des regles de filtrage IP. Il est toujours possible de monter
un serveur NFS a travers un pare-feu, bien que les mecanismes de
decouverte automatiques des terminaisons d'acces (<< endpoints >>) de
la commande mount(8) peuvent ne pas fonctionner. Il vous faudra alors
fournir des details specifiques a ces terminaisons d'acces
(<< endpoints >>) grace aux options de mount.
Les serveurs NFS lancent habituellement un service (daemon) portmapper
ou rpcbind pour annoncer aux clients les terminaisons (endpoints) des
services. Les clients se servent du demon rpcbind pour determiner :
Le port reseau utilise par chaque service base sur les RPCs
Le protocole de transport utilise par chaque service base sur
les RPCs
Le demon rpcbind utilise un port bien connu (111) afin d'aider les
clients a trouver la terminaison (endpoint) d'un service. Bien que NFS
utilise souvent un numero de port standard (2049), des services
auxiliaires tels que NLM peuvent choisir au hasard des numeros de port
inutilises.
Les configurations habituelles des pare-feux bloquent le port bien
connu de rpcbind. En l'absence du service rpcbind, l'administrateur du
serveur definit un numero de port pour les services lies a NFS afin que
le pare-feu puisse permettre l'acces aux ports des services specifiques
NFS. Les administrateurs des clients pourront alors indiquer le numero
du port du service mountd grace a l'option mountport de la commande
mount(8). Il peut etre necessaire d'imposer l'utilisation de TCP ou
d'UDP si le pare-feu bloque l'un de ces transports.
D'esactiver le traitement des ACL (Access Control List).
Solaris permet aux clients NFS version 3 l'acces direct aux Access
Control Lists (ACLs) POSIX stockes dans son systeme de fichiers local.
Ce protocole auxiliaire proprietaire, connu sous le nom de NFSACL,
offre un controle d'acces plus riche que le mode binaire. Linux
implemente ce protocole dans un but de compatibilite avec
l'implementation NFS de Solaris. Cependant, le protocole NFSACL n'est
jamais devenu une partie standard de la specification NFS version 3.
La specification de NFS version 4 impose une nouvelle version des
Access Control Lists qui sont semantiquement plus riches que les ACLs
POSIX. Les ACLs de NFS version 4 ne sont pas totalement compatibles
avec les ACLs POSIX. De ce fait, des traductions entre les deux sont
obligatoires dans un environnement qui melange a la fois les ACLs POSIX
et NFS version 4.
FICHIERS
/etc/fstab Table des systemes de fichiers
BOGUES
L'option generique remount n'est pas totalement geree. Les options
generiques, comme rw ou ro peuvent etre modifiees grace a l'option
remount, mais les options specifiques NFS ne sont pas toutes gerees.
Par exemple, le transport utilise, ou la version NFS ne peuvent pas
etre changes par un remount. L'execution d'un remount sur un systeme de
fichiers NFS monte avec l'option noac peut avoir des consequences
inattendues. L'option noac est un melange d'option generique, de sync
et de l'option actimeo=0 specifique a NFS.
Le client NFS anterieur a 2.4.7 ne gerait pas NFS sur TCP.
Le client NFS anterieur a 2.4.20 utilisait une heuristique pour savoir
si les donnees memorisees d'un fichier (en cache) etaient toujours
valides plutot qu'utiliser la methode standard de coherence de cache
close-to-open decrite ci-dessus.
Depuis la version 2.4.22, Le client NFS utilise une estimation RTT de
type Van Jacobsen pour definir les delais de depassement de temps
(timeout) lorsqu'il utilise NFS sur UDP.
Le client NFS Linux anterieur a 2.6.0 ne gerait pas NFS version 4.
Le client NFS anterieur a 2.6.8 n'utilisait les lectures et ecritures
synchrones que lorsque les reglages de rsize et wsize etaient
inferieurs a la taille des pages du systeme.
Le client NFS Linux ne prend toujours pas en charge certaines
caracteristiques optionnelles du protocole NFS version 4, tel que la
negociation de securite, les soumissions de serveurs et les attributs
nommes.
VOIR AUSSI
fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
netconfig(5), ipv6(7), nfsd(8), sm-notify(8), rpc.statd(8),
rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
RFC 768 concernant la specification UDP.
RFC 793 concernant la specification TCP.
RFC 1094 concernant la specification de NFS version 2.
RFC 1813 concernant la specification de NFS version 3.
RFC 1832 concernant la specification XDR.
RFC 1833 concernant la specification RPC bind.
RFC 2203 concernant la specification du protocole de l'API GSS RPCSEC.
RFC 3530 concernant la specification de NFS version 4.
TRADUCTION
Cette page de manuel a ete traduite et mise a jour par Christophe
Blaess entre 1997 et 2003. La version presente dans Debian 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>. Veuillez signaler toute erreur de traduction par un rapport de
bogue sur le paquet manpages-fr-extra.
2 novembre 2007 NFS(5)