en to fr translation catalogue (37 entries)

en: The option can be explicitly disabled with I<hide>.
fr: Cette option peut être désactivée explicitement avec I<hide>.

note: type: Plain text
en: This option is similar to I<nohide> but it makes it possible for clients to move from the filesystem marked with crossmnt to exported filesystems mounted on it.  Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has the same effect as setting "nohide" on B.
fr: Cette option est semblable à I<nohide> mais elle permet aux clients de se déplacer du système de fichiers marqué crossmnt aux systèmes de fichiers partagés montés dessus. Ainsi, si un système de fichiers fils « B » est monté sur un système de fichiers père « A », définir l'option crossmnt sur « A » aura le même effet que d'indiquer « nohide » sur « B ».

note: type: Plain text
en: This option disables subtree checking, which has mild security implications, but can improve reliability in some circumstances.
fr: Cette option neutralise la vérification de sous-répertoires, ce qui a des subtiles implications au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.

note: type: Plain text
en: If a subdirectory of a filesystem is exported, but the whole filesystem isn't then whenever a NFS request arrives, the server must check not only that the accessed file is in the appropriate filesystem (which is easy) but also that it is in the exported tree (which is harder). This check is called the I<subtree_check>.
fr: 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 I<subtree_check>.

note: type: Plain text
en: In order to perform this check, the server must include some information about the location of the file in the "filehandle" that is given to the client.  This can cause problems with accessing files that are renamed while a client has them open (though in many simple cases it will still work).
fr: 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).

note: type: Plain text
en: subtree checking is also used to make sure that files inside directories to which only root has access can only be accessed if the filesystem is exported with I<no_root_squash> (see below), even if the file itself allows more general access.
fr: 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 exporté avec l'option I<no_root_squash>(voir ci-dessous), et ce, même si les fichiers eux-mêmes offrent un accès plus généreux.

note: type: Plain text
en: As a general guide, a home directory filesystem, which is normally exported at the root and may see lots of file renames, should be exported with subtree checking disabled.  A filesystem which is mostly readonly, and at least doesn't see many file renames (e.g. /usr or /var) and for which subdirectories may be exported, should probably be exported with subtree checks enabled.
fr: 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.

note: type: Plain text
en: The default of having subtree checks enabled, can be explicitly requested with I<subtree_check>.
fr: On peut explicitement spécifier ce comportement par défaut de vérification des sous-répertoires en indiquant l'option I<subtree_check>.

note: type: Plain text
en: From release 1.1.0 of nfs-utils onwards, the default will be I<no_subtree_check> as subtree_checking tends to cause more problems than it is worth.  If you genuinely require subtree checking, you should explicitly put that option in the B<exports> file.  If you put neither option, I<exportfs> will warn you that the change is pending.
fr: À partir de la version 1.1.0 de nfs-utils, le réglage par défaut sera I<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 spécifier cette option dans le fichier B<exports>. Si vous ne précisez rien, I<exportfs> vous avertira de la modification.

note: type: Plain text
en: This option (the two names are synonymous) tells the NFS server not to require authentication of locking requests (i.e. requests which use the NLM protocol).  Normally the NFS server will require a lock request to hold a credential for a user who has read access to the file.  With this flag no access checks will be performed.
fr: 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é.

note: type: Plain text
en: Early NFS client implementations did not send credentials with lock requests, and many current NFS clients still exist which are based on the old implementations.  Use this flag if you find that you can only lock files which are world readable.
fr: 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 »).

note: type: Plain text
en: The default behaviour of requiring authentication for NLM requests can be explicitly requested with either of the synonymous I<auth_nlm>, or I<secure_locks>.
fr: Par défaut, les demandes d'identifications des requêtes NLM se comportent comme si les options (synonymes !) I<auth_nlm> ou I<secure_locks> avaient été fournies. On peut cependant écrire explicitement ces options.

note: type: Plain text
en: On some specially patched kernels, and when exporting filesystems that support ACLs, this option tells nfsd not to reveal ACLs to clients, so they will see only a subset of actual permissions on the given file system.  This option is safe for filesystems used by NFSv2 clients and old NFSv3 clients that perform access decisions locally.  Current NFSv3 clients use the ACCESS RPC to perform all access decisions on the server.  Note that the I<no_acl> option only has effect on kernels specially patched to support it, and when exporting filesystems with ACL support.  The default is to export with ACL support (i.e. by default, I<no_acl> is off).
fr: Sur certains noyaux spécialement modifiés, et lors de partages de systèmes de fichiers implémentant les ACL, cette option indique à nfsd ne pas dévoiler les ACL aux clients, ainsi ils verront seulement un sous-ensemble de permissions réelles sur le système de fichiers donné. Cette option est efficace pour des partages utilisés par les clients NFSv2 et les anciens clients NFSv3 qui effectuent des vérifications d'accès localement. Les clients NFSv3 actuels utilisent l'appel de procédure distante ACCESS (« ACCESS RPC ») afin d'effectuer toutes les vérifications d'accès sur le serveur. Notez que l'option I<no_acl> n'a d'effet que sur des noyaux spécifiquement modifiés pour le gérer, et seulement lors du partage de systèmes de fichiers implémentant les ACL. Par défaut, le partage implémente les ACL (c.-à-d. par défaut, I<no_acl> est désactivée).

note: type: TP
en: I<mountpoint=>path
fr: I<mountpoint=>chemin

note: type: Plain text
en: This option makes it possible to only export a directory if it has successfully been mounted.  If no path is given (e.g.  I<mountpoint> or I<mp>)  then the export point must also be a mount point.  If it isn't then the export point is not exported.  This allows you to be sure that the directory underneath a mountpoint will never be exported by accident if, for example, the filesystem failed to mount due to a disc error.
fr: 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 I<mountpoint> ou I<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.

note: type: Plain text
en: If a path is given (e.g.  I<mountpoint=>/path or I<mp=>/path)  then the nominated path must be a mountpoint for the exportpoint to be exported.
fr: Si un chemin est précisé (c.-à-d. I<mountpoint=>/chemin ou I<mp=>/chemin), le chemin indiqué doit être un point de montage pour le partage qui est fait.

note: type: Plain text
en: NFS needs to be able to identify each filesystem that it exports.  Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device).
fr: 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).

note: type: Plain text
en: As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem.  This is done with the I<fsid=> option.
fr: 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 de spécifier comment NFS identifiera un système de fichiers. C'est le rôle de l'option I<fsid=>.

note: type: Plain text
en: For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem.  This is specified with I<fsid=root> or I<fsid=0> both of which mean exactly the same thing.
fr: 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 I<fsid=root> ou I<fsid=0>, qui veulent tous deux dire exactement la même chose.

note: type: Plain text
en: Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctuation.
fr: 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.

note: type: Plain text
en: Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels.  Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike.
fr: 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.

note: type: TP
en: I<refer=>path@host[+host][:path@host[+host]]
fr: I<refer=>chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]

note: type: Plain text
en: A client referencing the export point will be directed to choose from the given list an alternative location for the filesystem.  (Note that the server must have a mountpoint here, though a different filesystem is not required; so, for example, I<mount --bind> /path /path is sufficient.)
fr: 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, I<mount --bind> /chemin /chemin suffit).

note: type: TP
en: I<replicas=>path@host[+host][:path@host[+host]]
fr: I<replicas=>chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]

note: type: Plain text
en: If the client asks for alternative locations for the export point, it will be given this list of alternatives. (Note that actual replication of the filesystem must be handled elsewhere.)
fr: 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).

note: type: SS
en: User ID Mapping
fr: Correspondance d'ID utilisateur (« User ID Mapping »)

note: type: Plain text
en: I<nfsd> bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.
fr: I<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.

note: type: Plain text
en: Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or I<nobody> uid. This mode of operation (called `root squashing') is the default, and can be turned off with I<no_root_squash>.
fr: Bien souvent, il n'est pas souhaitable que l'administrateur d'une machine cliente soit également traité comme le super utilisateur 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 I<nobody>. C'est le mode de fonctionnement par défaut (appelé « root squashing »), qui peut être désactivé grâce à I<no_root_squash>.

note: type: Plain text
en: By default,
fr: Par défaut,

note: type: Plain text
en: I<exportfs> chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the I<anonuid> and I<anongid> options.
fr: I<exportfs> choisit un UID et un GID de 65534 pour l'accès « squash ». Ces valeurs peuvent également être définies par les options I<anonuid> et I<anongid>.

note: type: Plain text
en: Finally, you can map all user requests to the anonymous uid by specifying the I<all_squash> option.
fr: Pour finir, vous pouvez faire correspondre toutes les requêtes des utilisateurs à l'UID anonyme en indiquant l'option I<all_squash>.

note: type: Plain text
en: Here's the complete list of mapping options:
fr: Voici la liste complète des options de correspondance (« mapping ») :

note: type: Plain text
en: Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user I<bin> or group I<staff>.
fr: 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 I<bin> ou le groupe I<staff> par exemple.

note: type: Plain text
en: Turn off root squashing. This option is mainly useful for diskless clients.
fr: Désactiver la transformation du super utilisateur. Cette option est principalement utile pour les clients sans disque dur.

note: type: Plain text
en: Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is I<no_all_squash>, which is the default setting.
fr: 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 I<no_all_squash>, qui est celle par défaut.

note: type: TP
en: I<anonuid> and I<anongid>
fr: I<anonuid> et I<anongid>

note: type: Plain text
en: These options explicitly set the uid and gid of the anonymous account.  This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for B</home/joe> in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).
fr: 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 B</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).
