Le problème
Le montage NFSv4 affiche à tort tous les fichiers dont la propriété est "personne :personne “. À partir du serveur client, le partage NFSv4 monté est propriétaire de tous les fichiers et répertoires répertoriés comme personne :personne au lieu de l'utilisateur réel qui les possède sur le serveur NFSv4, ou même qui a créé le nouveau fichier et répertoire.
Voir également l'erreur suivante dans /var/log/messages :
nss_getpwnam: name ‘[email protected]’ does not map into domain 'localdomain'
Cause fondamentale
Dans NFSv3, le nom d'utilisateur et le nom de groupe sont mappés à partir de la valeur UID/GID, l'UID/GID de l'utilisateur créant la ressource est enregistré sur le serveur. Lorsque les serveurs clients y accèdent, les fichiers /etc/passwd et /etc/gpasswd seront vérifiés pour voir si l'identifiant existe et pour quel utilisateur il sera mappé. S'il y a un utilisateur avec le même uid et gid, alors il sera mappé à cet utilisateur, sinon, la valeur numérique sera affichée.
Dans NFSv4, le concept est user@domainname, s'il n'y a pas de mappage d'utilisateurs centralisé, alors l'utilisateur sera mappé à l'utilisateur par défaut personne ou à n'importe quel utilisateur configuré dans /etc/idmapd.conf.
Vérifiez d'abord la configuration malformée de /etc/imapd.conf dossier. Si vous apportez des modifications au fichier idmapd.conf, sur CentOS/RHEL 6.5 et versions ultérieures, la commande pour nettoyer les anciens mappages est :
# nfsidmap -c
NFSv4 utilise le mappage d'ID pour s'assurer que les autorisations sont correctement définies sur les partages exportés. Si les domaines du serveur client et du serveur parent ne correspondent pas, les autorisations sont mappées sur personne :personne.
La solution
1. Changez le /etc/idmapd.conf avec le nom de domaine complet (FQDN) approprié, à la fois sur le client et sur le serveur parent. Dans cet exemple, le domaine approprié est "example.com" donc la directive "Domain =" dans /etc/idmapd.conf doit être modifiée pour lire :
# vi /etc/idmapd.conf Domain = oracle.com
2. Pour appliquer les modifications, redémarrez le service rpcidmapd et remontez le système de fichiers NFSv4 :
# service rpcidmapd restart # mount -o remount /nfs/mnt/pointRemarque :Il est seulement nécessaire de redémarrer le service rpc.idmapd sur les systèmes où rpc.idmapd exécute réellement le mappage d'id. Sur RHEL 6.3 et les CLIENTS NFS plus récents, les cartes sont stockées dans le trousseau de clés du noyau et le mappage d'ID lui-même est effectué par le programme /sbin/nfsidmap. Sur les anciens CLIENTS NFS (RHEL 6.2 et versions antérieures) ainsi que sur tous les SERVEURS NFS exécutant RHEL, le mappage des identifiants est effectué par rpc.idmapd. Assurez-vous que le client et le serveur ont des UID et des GID correspondants. C'est une idée fausse courante que les UID et les GID sont autorisés à être différents lors de l'utilisation de NFSv4. Le but du mappage d'id est de mapper id à un nom et vice-versa. Le mappage d'ID n'est pas destiné à remplacer la gestion des ID.
Sur Red Hat Enterprise Linux 6, si les paramètres ci-dessus ont été appliqués et que les UID/GID sont mis en correspondance sur le serveur et le client et que les utilisateurs sont toujours mappés à personne :personne, un effacement du cache idmapd peut être nécessaire.
# nfsidmap -cRemarque :La commande ci-dessus n'est nécessaire que sur les systèmes qui utilisent le mappeur d'identifiant basé sur le trousseau de clés, par ex. CLIENTS NFS exécutant RHEL 6.3 et supérieur. Sur les CLIENTS NFS RHEL 6.2 et antérieurs ainsi que sur tous les SERVEURS NFS exécutant RHEL, le cache est vidé lorsque rpc.idmapd est redémarré. Une autre vérification, voyez si les paramètres passwd:, shadow:et group:sont correctement définis dans le fichier /etc/nsswitch.conf sur les serveurs Parent et Client.
Désactivation de l'idmapping
Par défaut, les clients et serveurs NFS RHEL6.3 et plus récents désactivent l'idmapping lors de l'utilisation de la version d'authentification AUTH_SYS/UNIX en activant les instructions booléennes suivantes :
Serveur client NFS
# echo 'Y' > /sys/module/nfs/parameters/nfs4_disable_idmapping
Serveur parent NFS
# echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping
Dépannage
Si le plan ci-dessus ne résout pas votre problème, veuillez effectuer les étapes de diagnostic suivantes :
1. Le débogage/verbosité peut être activé en modifiant /etc/sysconfig/nfs :
# vi /etc/sysconfig/nfs RPCIDMAPDARGS="-vvv"
2. La sortie suivante s'affiche dans /var/log/messages lorsque le montage est terminé et que le système n'affiche personne :personne en tant qu'utilisateur et groupe d'autorisations sur les répertoires et les fichiers :
Jul 3 00:23:18 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘[email protected]’ does not map into domain ‘localdomain’ Jun 3 00:26:54 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘[email protected]’ does not map into domain ‘localdomain’
3. Collectez un tcpdump de la tentative de montage :
# tcpdump -s0 -i {INTERFACE} host {NFS.SERVER.IP} -w /tmp/{SR_number}-$(hostname)-$(date +”%Y-%m-%d-%H-%M-%S”).pcap &