NFS, prise de tête

Bonjour,

Il paraît que NFS est la méthode la plus simple pour partager des fichiers entre machines Linux. Après une prise de tête de plusieurs heures je ne partage pas cet avis. La configuration côté serveur est simplissime une ligne dans /etc/exports, un exportfs -rav et ça tourne. Côté client, un mount (rw) relativement classique.

Mais…

Pour que le mount (sur le client) fonctionne correctement, il est impératif que les uid/gid correspondent des deux côtés! Exemple:
[ul]

[li]Sur le client on a:

uid toto 1000 uid mysql 1005 gid mysql 1005

Toto (1000) est dans le groupe mysql (1005) et a donc les droits 7 sur les fichiers locaux 1005:1005 avec des droits 770 du groupe mysql.

[/li]
[li]Sur le serveur:

Un répertoire a les droits 770:

On sait qu’avec NFS il faut que l’uid de toto sur le serveur et client soient identiques (1000). C’est dans tous les howto’s et man (“id mapping”). Ça c’est bon. Mais, pour le groupe, si on a

uid toto 1000 uid mysql 1001 gid mysql 1001
Toto (1000) est dans le groupe mysql (1001).

Dans ce cas, après le mount (rw) sur le client, toto-client (uid 1000, inclus dans le groupe 1005 sur le client) n’aura pas les droits de création de fichiers du serveur qui n’autorise la création de fichiers que pour le proprio (mysql uid 1001) et les membres du groupe 1001 car le client s’y présente comme toto 1000 membre de 1005 et pas toto 1000 membre de 1001.

Le gid doit donc également correspondre des deux côtes.

[/li]
[li]Solutions possibles:
[list]

[*]harmoniser les uid/gui sur les deux machines (usermod -u et -g). Mais ATTENTION il faudra aussi changer les uid/gid de tous les fichiers à coup de find+xargs. Opération possible mais pas sans danger. Travailler méthodiquement. C’est la méthode que j’ai choisie.

[/li]
[li]sur le serveur, exporter avec all_squash et mettre un uid/gid qui va bien avec anonuid anongid

Solution plus rapide mais moins sécurisée car tout le monde sera squashé avec le anonuid/gid

[/li]
[li]Installer NIS (pas testé. Plus le courage.)[/li][/ul][/*:m][/list:u]

Si quelqu’un a une solution plus simple (mais pas du genre chmod 777!), je prends.

liens

[linux-france.org/prj/inetdoc ... s.lab.html](http://www.linux-france.org/prj/inetdoc/cours/admin.reseau.synthese-nfs-nis/admin.reseau.synthese-nfs3-nis.lab.html)
[fr.wikibooks.org/wiki/Le_syst%C3 ... chiers_NFS](http://fr.wikibooks.org/wiki/Le_syst%C3%A8me_d%27exploitation_GNU-Linux/Le_partage_de_fichiers_NFS)

Bonjour,

As tu essayé le sshfs? Moi j’utilise ça et ça fonctionne très bien.

installe le démon rpc.ugidd et renseigne toi sur le «map_identity», cela fait ce que tu veux.

[quote=“darham”]As tu essayé le sshfs? Moi j’utilise ça et ça fonctionne très bien.[/quote]Oui, j’utilise souvent scp rsync et compagnie. Mais j’essaye d’éviter le passage par ssh pour alléger le transfert de gros fichiers. Et puis, NFS a été prévu pour que des systèmes *nix communiquent entre-eux sans devoir passer sous les fourches caudines de SMB non?

[quote=“fran.b”]installe le démon rpc.ugidd et renseigne toi sur le «map_identity», cela fait ce que tu veux.[/quote]Merci pour la piste qui m’a fait progresser. Depuis que le serveur NFS4 est passé dans le kernel, les options map_daemon et map_static ne semblent plus supportées. Par contre, ça semble maintenant se passer dans /etc/idmapd.conf. Je teste ça demain et si j’arrive à quelque-chose, je posterai ici.

hello

j’utilise aussi nfs ,je vai donc suivre le topic :stuck_out_tongue:

sinon c’est nfs + ssh l’avantage c’est que l’user peux monter, et ssh crypte les informations .
l’inconvenian c’est que sa mange un peux de bande passante et de ressource cpu …

Bon, je ne suis arrivé à rien. Avec NFS4 le mapping se fait dans le fichier idmapd.conf si j’ai bien compris. Des deux côtés le daemon rpc.idmapd doit tourner. Jusque là ça va. Mais pour le mapping, ça coince. Exemple:

Client:
Xavier (uid xavier, gid xavier) veut accéder aux fichiers de Jessica (uid jessica, gid jessica) sur lesquels elle seule a les droits sur le serveur. L’uid/gid jessica n’existe pas sur le client.
idmapd.conf du client

[code][General]

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

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

xavier-User = xavier
xavier-Group = xavier[/code]

Serveur:

[code][General]

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

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

xavier-User = jessica
xavier-Group = jessica[/code]
J’ai essayé toutes les combinaisons possibles.

Le man de idmapd.conf dit:

[quote][size=85] The idmapd.conf configuration file has two sections, initiated by the strings [General] and [Mapping]. Each section may
contain lines of the form

       variable = value

 The variables allowed in the General section are Verbosity, Pipefs-Directory, and Domain, whose values have the same
 effect as the arguments to the -v, -p, and -d commandline options, respectively.  The variables allowed in the Mapping
 section are Nobody-User and Nobody-Group, which have the same effect as the -U and -G commandline options.[/size]

[/quote]Si j’en crois ce man, les seules variables admise dans la section mapping seraient Nobody-User et Nobody-Group auquel cas je ne vois pas comment mapper. NFS3 permettait de mapper plus simplement à ce qu’il me semble. On mettait dans un fichier du serveur quelque-chose comme:

[code]# This file maps remote identifiers to local identifiers.

remote local

uid 501 1000
gid 501 1000 [/code]

Franchement je ne vois pas comment faire. Peu de doc (j’ai du dépasser mon quota sur les serveurs de Google) et rien ou très peu dans les log. Un tcpdump ne révèle rien de frappant non plus. J’ai bien envie de laisser tomber. Alors si quelqu’un a une idée…

J’instiste un peu mais jr crois bien que le paquet ugidd fait ce que tu veux

http://packages.debian.org/lenny/ugidd

(Tu l’installes sur le serveur)

Mouais, à vue de nez ugidd a été abandonné avec le passage en NFS-kernel. Peut être que le NFSV4 le reprend… [edit: en fait NFS4 fait ces instructions, je pense que ton NFS tourne en V3 qui lui ne sait pas le faire]

Je suis en NFS4 des deux côtés. Trouvé deux bons tuto sur la configuration pas tellement triviale tant dans l’export que dans la manière de monter côté client. Mais rien y fait pour le mapping. Ça se monte bien mais pour les droits, pas de mapping. Sans lui, il faut donc respecter une équivalence stricte des uid/gid. Un peu limitatif je trouve. J’en arrive a voir Samba comme une alternative plus simple et mieux documentée. Un comble.

brennan.id.au/19-Network_Fil … .html#nfs4
vanemery.com/Linux/NFSv4/NFS … pcsec.html

Dans les fils que j’ai vu là dessus, la plupart des erreurs venait de là: malgré un NFS4 des 2 cotés, le protocole basculait en NFS3. Or cette fonctionnalité est spécifique NFS4. vérifie bien que tu n’es pas dans ce cas. Sinon, à ta place j’utiliserais le nfs-user de lenny avec le rpc.ugidd en attendant que NFS 4 soit pleinement opérationnel.
Samba est une bonne alternative, n’hésite pas à l’utiliser, les performances sont bonnes. Ça n’est pas parce que Windows utilise NetBios que c’est une cochonnerie. Le protocole est très vieux et assez lourd (fait par IBM je crois vers 70-80) mais il a été amélioré et est solide.

Je pense effectivement que je devrai retourner à SMB. Un peu frustré quand même car NFS est beaucoup plus léger. C’est ma troisième tentative en 5 ans d’utiliser NFS. J’y arriverai un jour j’imagine…

Ou bien installe des noyaux très récents des deux cotés… (NFS est géré par le noyau)

Oui, peut-être. Mais ça fait quand même beaucoup de contraintes quand même. J’avance un peu, j’ai rendu le daemon rpc.idmapd un peu plus bavard (RPCGSSDOPTS="-vvv" dans /etc/defaults/nfs-common) et il me montre une forme de mapping dont je ne comprends pas pourquoi il ne fonctionne pas comme souhaité. Mais mapping il y a.

Je résume. NFS4 des deux côtés avec les options du /etc/default/nfs-common qui forcent NFS4 des deux côtés (NEED_STATD=no, NEED_IDMAPD=yes)
Sur le serveur un export NFS4 (avec le système de fichier racine fsid=0, le bind du fstab et tout le toutim) et sur le client, un mount spécifique NFS4 qui fonctionne.

Sur le client on a xavier:xavier (1000:1000)
Sur le serveur: xavier:xavier (1000:1000) et jessica:jessica (1003:1003)

Le mount sur le répertoire serveur de xavier fonctionne parfaitement. Pas de problème de ce côté puisqu’il y a correspondance complète des uid:gid.

Maintenant le mapping pour que xavier accède aux rép. de jessica (serveur). Dans le /etc/idmapd.conf je configure (des deux côtés) un mapping standard comme dans tous les howto que j’ai lu:
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

Si xavier demande par exemple un ls sur un répertoire (770) de jessica sur le serveur j’ai une journalisation du genre:

Sur le client:
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nss_getpwnam: name ‘jessica@localdomain’ domain ‘localdomain’: resulting localname 'jessica’
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nss_getpwnam: name ‘jessica’ not found in domain 'localdomain’
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_uid: nsswitch->name_to_uid returned -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_uid: final return value is -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: Client 11: (user) name “jessica@localdomain” -> id "65534"
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: nsswitch->name_to_gid returned -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: final return value is -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: Client 11: (group) name “jessica@localdomain” -> id "65534"
Mar 27 11:26:21 ibm rpc.idmapd[5623]: New client: 13

Il y a une forme de logique: jessica n’existant pas sur le client, on lui donne les uid:gid de nobody:nogroup du client. Jusque là c’est bien conforme à la consigne de mapping du idmapd.conf.

Serveur
Mar 27 11:24:26 debian rpc.idmapd[6422]: nfsdcb: authbuf=ibm authtype=group
Mar 27 11:24:26 debian rpc.idmapd[6422]: Server: (user) id “1003” -> name "jessica@localdomain"
Mar 27 11:24:26 debian rpc.idmapd[6422]: nfsdcb: authbuf=ibm authtype=user
Mar 27 11:24:26 debian rpc.idmapd[6422]: Server: (user) id “1003” -> name “jessica@localdomain”

xavier n’hérite pas des droits de jessica sur un de ses (jessica) répertoires 770. Il lui est impossible de faire un simple ls sur le mount de ce répertoire. Il faut que ce répertoire soit en 777 pour que ça marche. J’ai donc pensé que xavier, au vu du log du client, se présentait comme nobody sur le serveur et j’ai donc ajouté nobody comme membre du groupe jessica du serveur. Avec ces droits 770 nobody devrait accéder au rép. de jessica non? Et bien oui si j’essaye un ls comme nobody sur le serveur mais pas depuis le client comme xavier mappé à nobody! Vous me suivez toujours? Oui? Et bien vous avez de la chance car moi, je suis perdu!

Si une bonne âme douée, titillée par le défi ou poussée par la nécessité de faire un partage NFS qui fonctionne passe par ici et trouve la solution…

Essaye d’installer NIS et vérifies ton /etc/nsswitch.conf
Ton souci c’est ça:

Oui mais justement, comme jessica n’existe pas sur le client, idmapd du client “mappe” jessica vers nobody:nogroup (65534:65534)

Mar 27 11:26:21 ibm rpc.idmapd[5623]: nss_getpwnam: name ‘jessica’ not found in domain 'localdomain’
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_uid: nsswitch->name_to_uid returned -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_uid: final return value is -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: Client 11: (user) name “jessica@localdomain” -> id "65534"
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: nsswitch->name_to_gid returned -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: nfs4_name_to_gid: final return value is -2
Mar 27 11:26:21 ibm rpc.idmapd[5623]: Client 11: (group) name “jessica@localdomain” -> id "65534"

De là, j’imagine que la demande NFS-client vers le serveur s’y présente comme nobody:nogroup qui existe également sur le serveur et qui se trouve dans le groupe de jessica avec des droits rwx.

Installer NIS, j’espérais y échapper! Je ne suis pas loin du but, je le sens, il s’agit sans doute d’un détail de droit. Mais je pense que le mapping se fait bien. Du moins avec nobody.

salut Ripat! Le post date un peu, mais bon…

Il est possible à ce que je viens de tester, de mapper le nobody en un utilisateur. Mais pour l’instant, j’en suis arriver à mapper un seul utilisateur.

Le serveur envoie un nobody aux services clients:

Nobody-User = nobody Nobody-Group = nogroup

Et le client transforme le nobody en utilisateur:

Nobody-User = jessica Nobody-Group = jessica

Comme ça, le dossier partagé sur le client possède autre droit que le 777

En espérant t’avoir aidé si tu as trouvé aucune solution à ce jour

Bonjour,
j’ai un problème similaire (un PC Ubuntu 16.04 tentant d’accéder en NFS à un synology). Je précise qu’en SMB/CIFS tout fonctionne… sauf que je n’ai pas de liens symboliques à disposition (n’existe pas sur SMB à ma connaissance), donc je voudrais passer en NFS.

Ma compréhension du problème initial de ce post: le client envoie l’ID 65534 de nobody au serveur. Est-ce que cet ID correspond au user nobody sur le serveur? si non, il sera sans doute inconnu et donc mappé sur le nobody-user déclaré côté serveur.

Ajouter le user nobody serveur dans le groupe de jessica est insuffisant AMA (faudrait relire la doc sur le fonctionnement des permissions Unix). Ca relève plus de l’intuition de ma part de dire ça, donc je me trompe peut-être.

Mon problème perso : les UIDs client (portable) et serveur (synology) sont différents, mais hier soir, j’avais une config NFSv4 où une fois monté, je voyais les bon username pour les fichiers (je monte le /volume1/homes du synology, donc je voudrais préserver TOUS les UIDs serveurs).

Après avoir correctement configuré les permissions complémentaires de synology (il y en a quelques unes, c’est un peu uzine à gaz), j’ai accès, mais quand j’écris un fichier sur le serveur, il se retrouve avec des UID/GID qui ne ressemblent à rien ?! (mais je suspecte un GID -2 qui donne un int LONG côté serveur au lieu de juste 65534).

Bonjour,

Je bosse là dessus aussi…
Il me semble que nfs4 soit une maj mise en place avec la charrue avant les bœufs…

(Bien entendu, parmi les bœufs je fais sois-même parti de ce groupe)

Je ne saurais jeter la pierre à ceux qui sont investi de ce projet…

Toujours est-il que je crois avoir compris qu’il manque des routines usités sous nfs3 qui ne sont pas implémentés sous nfs4

eg: L’ IPV6 ne fonctionne pas…

Re-bonjour;

Désolé pour l’envoi touche “return” dans le noir… Je continue…

Le mapping multiple, par contre ça c’est cool, mais côté règles de sécurités, je pense qu’il faut soit passer sous nfs3…

Soit, déclenche kerberos, qui est prévu en tête pour cette version de nfs4 …

… Si je ne dis pas de co…eries… ???

D’ailleurs c’est ce que je vais tester en premier, Kerberos…