Forum Linux.debian/ubuntu montage NFS sans UID et GID

Posté par  .
Étiquettes : aucune
-2
16
août
2011

Bonjour,

Je monte le répertoire HOME de mes utilisateurs en NFS. Le soucis est que les UID et GUID des repertoires ne correspondent pas à part si je fais un chgrp ou un chown avec l'option -R sur ceux ci.
exemple :

:~$ ls -l /home
total 576
drwxr-x---   6 4294967294 4294967294  17  6 juil.  2010 user1
drwxr-x---  24 4294967294 4294967294  31 16 août  19:48 user2
drwxr-x---  28 4294967294 4294967294  57  8 juil. 14:59 user3

tail -1 /etc/fstab
host:/export/home   /home   nfs     bg,rw,rsize=8192,wsize=8192,intr         0      0

J'ai remplacé les options rw et intr par defaults mais j'ai le même résultat. J'ai aussi essayé autofs, j'ai toujours le résultat ci dessus. Par contre mes servuer RHEL et SOLARIS n'ont pas ce soucis les UID et GID sont respectés.

Comment faire pour avoir un ls -l /home comme ceci :
:~$ ls -l /home
total 576
drwxr-x--- 6 user1 user1 17 6 juil. 2010 user1
drwxr-x--- 24 user2 user2 31 16 août 19:48 user2
drwxr-x--- 28 user3 user3 57 8 juil. 14:59 user3

  • # NIS ou autre pour utiliser une base commune d'utilisateur/groupe

    Posté par  . Évalué à 2.

    il te faut une solution centrale pour la gestion de tes utilisateurs/groupes
    afin d'avoir des UID/GID communs.

    Couramment, avec NFS on utilise NIS

    • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

      Posté par  (site web personnel) . Évalué à 3.

      Regarde du côté d'idmap

    • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

      Posté par  . Évalué à -1.

      Bonjour ,

      Je suis avec un authentification LDAP

      • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

        Posté par  . Évalué à -1.

        si tu utilises une authentification LDAP, arrange toi pour ajouter le shema posix dedans

        ainsi ce sera ton LDAP qui gerera les UID/GID, y a de tres bons tutos sur le net à ce sujet

        ainsi tu aura des IDs centralisés et plus de probleme (en principe)

        • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

          Posté par  . Évalué à -4.

          Merci pour ta réponse
          Ce que je ne comprend c'est que je n'ai rien du à faire sur mes serveurs RedHat en tant que client NFS. J'ai copié le /etc/idmap.conf des RHEL sur le serveurs Debian, cela a été sans effet.

          :~# more /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

          Peux tu me donner un liens que je puisse commencer les recherches...?

          • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

            Posté par  . Évalué à -1.

            avant de copier le idmap de redhat/solaris vers ubuntu
            je regarderais si mes IDs sont les memes sur les 3 machines

            sous linux la commande
            getent passwd et getent group

            eventuellement avec un grep pour trouver ton utilisateur ou ton groupe et ainsi voir ses ids.

            ensuite ton histoire de "ca met tout à nobody/nogroup" ca ressemble quand meme à une regle "squash" de nfs activée soit coté serveur, soit coté client.

            • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

              Posté par  . Évalué à -1.

              Oui C'est centralisé ....

              Sur SOLARIS il n'y pas de fichier idmap.conf ...
              J'ai trouvé ce message d'erreur dans /var/log/daemon.log :

              Aug 17 15:55:57 lsdbot rpc.idmapd[8629]: nss_getpwnam: name '70013' does not map into domain 'localdomain'
Aug 17 15:56:34 lsdbot rpc.idmapd[8629]: nss_getpwnam: name '70109' does not map into domain 'localdomain'
Aug 17 15:56:35 lsdbot rpc.idmapd[8629]: nss_getpwnam: name '70013' does not map into domain 'localdomain'
Aug 17 15:56:43 lsdbot rpc.idmapd[8629]: nss_getpwnam: name '70109' does not map into domain 'localdomain'
Aug 17 15:56:57 lsdbot rpc.idmapd[8629]: nss_getpwnam: name '70013' does not map into domain 'localdomain'

              C'est intèrressant car c'est à 70000 que commence mes UID.
              J'ai vérifié mon /etc/hosts et j'ai corrigé un mauvaise configuration sur cette ligne :

              127.0.0.1      localhost.localdomain    localhost

              J'ai redémarré les services nfs-common et portmap rien n'y fait ...........

              • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

                Posté par  . Évalué à -2.

                Oui C'est centralisé ....
                Sur SOLARIS il n'y pas de fichier idmap.conf ...

                mais donc ton probleme, il est sur ubuntu ou sur solaris ?
                sur le serveur ou sur le client ?

                parce que là, je suis perdu dans tes demandes ?

                J'ai trouvé ce message d'erreur dans /var/log/daemon.log :

                et ton fichier idmap, il fait quoi comme calcule ?
                sur ubuntu ?

                de ce que j'ai compris du fichier idmap, son but c'est de convertir les uids locales en uids du serveur (et l'inverse)

                il faut donc lui dire comment chercher et comment calculer le nouvel IDs

                • [^] # Re: NIS ou autre pour utiliser une base commune d'utilisateur/groupe

                  Posté par  . Évalué à -1.

                  mais donc ton probleme, il est sur ubuntu ou sur solaris ?
                  sur le serveur ou sur le client ?

                  parce que là, je suis perdu dans tes demandes ?

                  Ubuntu est le client qui monte le NFS sur /home. Quand je fais ls -l sur /home tous les sous repertoires ont nogroup comme GID et nobody comme UID.
                  Mais cela ne gène en rien les connexions puisque les utilisateur arrive à écrire dans le répertoire et n'arrive pas à lire ce que contient les répertoires des autres utilisateurs. Note que je n'ai aucun problème avec les autres clients du serveur NFS, c'est pour cela que j'essaie de savoir ce qui fonctionne sur ces dernier.

                  il faut donc lui dire comment chercher et comment calculer le nouvel IDs
                  Je rappel mon idmap.conf :

                  :~# more /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

                  D'après ce j'ai compris, la section Translation n'est pas obligatoire, mais le Mapping l'est et il force à nobody. Malheureusement je ne sais pas qu'elle autre valeur peut on mettre.
                  J'ai trouvé un faute dans mon fichier /etc/hosts que j'ai corrigé. Faut-il redémarré le serveur car j'ai redémarré le service portmap et nfs-comon c'est sans effet.

                  Merci de votre aide

  • # Ubuntu aussi...

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    J'ai eu un problème similaire sur Ubuntu: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/643289

    La fin du paragraphe "NFSv4 without Kerberos > NFSv4 Client", à https://help.ubuntu.com/community/NFSv4Howto, permet de résoudre le problème.

    • [^] # Re: Ubuntu aussi...

      Posté par  . Évalué à -3.

      Merci Aurel,

      Effectivement dans la doc Ubuntu il y a bien la description de l'erreur:
      all directories and files on the client are owned by uid/gid 4294967294:4294967294

      J'ai donc appliqué la modification du fichier /etc/default/nfs-common et j'ai redémarrer le démon nfs-common. Malheureusement cela n'a pas résolu notre problème puisque que la valeur 4294967294 s'est transformé par nobody pour l'UID et nogroup pour pour le GID.

      Ce qui est étrange les restrictions sont proutant bien respectées : l'user1 ne peut pas aller voir ce qui a à l’intérieur du répertoire de user2, par exemple, a part s'ils sont dans le même groupe.....

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.