ubuntuusers.de

NFS4: auf dem Client angelegte Dateien gehören nobody (uid) 4294967294 (gid)

Status: Ungelöst | Ubuntu-Version: Ubuntu 17.04 (Zesty Zapus)
Antworten |

AlBundy33

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Problem ist eigentlich hier aufgetreten: https://forum.ubuntuusers.de/topic/kann-man-ein-quota-auf-ein-nfs-share-legen/#post-8892689 Da das aber nicht mehr wirklich zum Thema gehört, hab ich mal einen neuen Thread aufgemacht.

Kurze Einleitung: Ich habe eine Synology Disktation DS213 und einen Raspberry PI 3 (Raspian / Debian Stretch). Auf der DS habe ich einige Verzeichnisse per NFS freigegeben und diese am PI gemountet. Nutzer und Gruppen habe ich fast alle auf beiden Systemen vorhanden.

Hier mal ein paar Auszüge aus diversen Dateien: /etc/exports meiner DS

/volume1/public rpi(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

/etc/idmapd.conf meiner DS

[General]
Domain=localdomain
[Mapping]
Nobody-User=guest
Nobody-Group=users
[Translation]
Method=nsswitch
GSS-Methods=static,synomap
[Static]

/etc/fstab auf meinem Raspberry

diskstation:/volume1/public /media/public nfs defaults,intr,noatime,noauto,x-systemd.automount 0 0

/etc/idmapd.conf auf meinem Raspberry

[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
Domain = localdomain

[Mapping]

Nobody-User = guest
Nobody-Group = users

Soweit sieht auch alles gut aus unter /media/public - auf beiden Systemen habe ich soweit erstmal die richtigen user und gruppen, wenn ich ls -l ausführe.

Jetzt kommen wir aber zum spannenden Teil. ☺

Lege ich auf meiner Diskstation eine Datei als admin an sehe ich auf der DS und dem Raspberry admin:users, wenn ls -l eingeben. Lege ich eine Datei auf meinem Raspberry an, dann sehe ich auf dem Raspberry mit ls -l nobody 4294967294 und auf der DS 1000 1000 (das sind uid und gid des Nutzers pi auf meinem Raspberry). Ändere ich dann den Eigentümer mit chown auf den, den ich eigentlich erwartet hätte, sieht wieder alles gut aus.

Hat jemand eine Idee, was ich konfigurieren muss, damit die Files von Anfang an den richtigen Nutzer haben? Hier scheint es ja irgendwie beim user-mapping zu klemmen, da nach der Anlage die uid und guid meines Nutzers auf dem Server ankommt.

Danke

Al

Hier mal die Ausgaben.

pi@rpi:/media/public/test $ touch test
pi@rpi:/media/public/test $ touch test2
pi@rpi:/media/public/test $ ls -l
insgesamt 0
-rw-r--r-- 1 nobody 4294967294 0 Okt  8 00:00 test
-rw-r--r-- 1 nobody 4294967294 0 Okt  8 00:00 test2
pi@rpi:/media/public/test $ ls -ln
insgesamt 0
-rw-r--r-- 1 65534 4294967294 0 Okt  8 00:00 test
-rw-r--r-- 1 65534 4294967294 0 Okt  8 00:00 test2
pi@rpi:/media/public/test $ sudo chown pi:pi test
pi@rpi:/media/public/test $ ls -l
insgesamt 0
-rw-r--r-- 1 pi     pi         0 Okt  8 00:00 test
-rw-r--r-- 1 nobody 4294967294 0 Okt  8 00:00 test2
pi@rpi:/media/public/test $ ls -ln
insgesamt 0
-rw-r--r-- 1  1000       1000 0 Okt  8 00:00 test
-rw-r--r-- 1 65534 4294967294 0 Okt  8 00:00 test2
pi@rpi:/media/public/test $ ssh admin@diskstation
admin@diskstation's password:
Could not chdir to home directory /var/services/homes/admin: No such file or directory
admin@DiskStation:/$ cd /volume1/public/test/
admin@DiskStation:/volume1/public/test$ ls -l
total 0
-rw-r--r-- 1 pi   pi   0 Oct  8 00:00 test
-rw-r--r-- 1 1000 1000 0 Oct  8 00:00 test2
admin@DiskStation:/volume1/public/test$ sudo chown pi:pi test2
Password:
admin@DiskStation:/volume1/public/test$ ls -l
total 0
-rw-r--r-- 1 pi pi 0 Oct  8 00:00 test
-rw-r--r-- 1 pi pi 0 Oct  8 00:00 test2
admin@DiskStation:/volume1/public/test$ logout
Connection to diskstation closed.
pi@rpi:/media/public/test $ ls -l
insgesamt 0
-rw-r--r-- 1 pi pi 0 Okt  8 00:00 test
-rw-r--r-- 1 pi pi 0 Okt  8 00:00 test2

Kleiner Nachtrag: wenn uid auf client und server die gleichen für meinen Nutzer sind, dann werden die Besitzer von Anfang an richtig angezeigt.

Aber dann braucht man auch kein NFS4 mehr und könnte bei der 3 bleiben. Mein Ziel war ja eigentlich, dass ich die uids und gids nicht ändern muss. :-/ Oder wie seht ihr das?

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Hat niemand eine Idee?

Al

pepre Team-Icon

Supporter
Avatar von pepre

Anmeldungsdatum:
31. Oktober 2005

Beiträge: 6474

Wohnort: Erlangen

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Im Thread steht, dass die Domain gleich sein soll - das ist bei mir gegeben. Als Alternative wird geschrieben, dass man auf NFSv3 umsteigen soll - das wollte ich vermeiden, da dann uid und gid auf meiner Diskstation und dem Raspberry gleich sein müssen.

Das komische ist ja, dass beim Anlegen einer Datei (z.B. mit touch) erstmal nobody und eine "komische" gid angezeigt werden - wenn ich dann ein chown mit user:group durchführe, werden die Besitzer richtig angezeigt. Daher scheint ja NFSv4 erstmal zu funktionieren - nur die Anlage der Datei will noch nicht so richtig. :-/

pepre Team-Icon

Supporter
Avatar von pepre

Anmeldungsdatum:
31. Oktober 2005

Beiträge: 6474

Wohnort: Erlangen

Da steht aber auch:

This is true for NFsv3 and will not work with NFSv4. V4 relay on the fact, that user names are shared between client and server, while uid/gid cant be different. In opposite, v3 shares uid and gid. Probably, you have to mount with vers=3 to solve your problem. The other possibility to turn off id mapping on the server side: echo "options nfs nfs4_disable_idmapping=1" > /etc/modprobe.d/nfs.conf

Vllt das noch lesen:

https://serverfault.com/questions/98741/files-mounted-over-nfsv4-are-owned-by-4294967294-uids-and-gids-match

Zu "4294967294" findet sich so einiges im Netz. Scheint öfter mal zu haken.

Vllt hab ich morgen mal Zeit das nachzustellen, jetzt nicht, sorry...

Vllt mal in den entsprechenden RasPi Foren blättern, der verhält sich zuweilen sehr eigen...

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Ich vermute mal, dass der Teil while uid/gid cant be different ein Schreibfehler ist und es heissen soll can be different.

Soweit ich weiss ist das ja der Sinn von NFSv4, dass uid und gid nicht gleich sein müssen.

Wie gesagt, dass funktioniert nach einem chmod - nur eben nicht nach einem touch.

Ich hab auch schon danach gesucht aber noch nichts hilfreiches gefunden.

Viele sind dann wohl auf NFSv3 umgestiegen und haben dann die uid und gid auf NAS oder pi angepasst.

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Hallo pepre,

hattest Du mal Zeit zu schauen, wie das bei Dir ist? Ich habe auf meiner Diskstation auch nur NFS inkl. v4 Support aktiviert und dann ein Verzeichnis für den Raspberry freigegeben.

Auf dem Raspberry, der mit Raspian Stretch läuft gibt es bei mir keinen idmapd mehr - das wir wohl jetzt "irgendwie" über nfs-common geregelt, was aber auf jeden Fall auch mit oder so ähnlich wie idmapd funktioniert.

Wie gesagt, das Problem hab ich bei mir ja nur beim Anlegen von Dateien - nach einem chown funktioniert das scheinbar problemlos.

Allerdings ist das vermutlich nicht so im Sinne des Erfinders. ☺

Al

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Hallo pepre,

hattest Du mal Zeit einen Blick zu riskieren? Wenn nicht, ist auch nicht so schlimm.

Al

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

pepre schrieb:

Vllt hab ich morgen mal Zeit das nachzustellen, jetzt nicht, sorry...

Hallo Pepre,

hattest Du mal Zeit einen Versuch zu wagen? Alle Beiträge die ich so gefunden habe, haben entweder aufgegeben oder auf NFS3 zurückgestellt. Das geht im Grunde auch - nur hab ich dann auf der Diskstation die UIDs des Raspberry.

Al

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Ich hab mal auf einem anderen Rechnung Ubuntu 17.10 installiert und da die nfs-mounts meiner diskstation eingebunden.

Dort hab ich genau das gleiche Problem. Nach anlegen der Dateien gehören die nobody und der gid.

Nach einem chown auf den Nutzer meiner Wahl (lokal und auf diskstation vorhanden, nur mit unterschiedlicher uid und gid), wird wieder alles richig angezeigt. –> Sowohl lokal als auch auf der diskstation.

Hat jemand eine Idee, warum uid und gid nach der Anlage (z.B. touch) nicht stimmen?!?!

Al

pepre Team-Icon

Supporter
Avatar von pepre

Anmeldungsdatum:
31. Oktober 2005

Beiträge: 6474

Wohnort: Erlangen

https://help.ubuntu.com/community/NFSv4Howto

Und:

Setting NEED_IDMAPD=yes on the client as well resolved the issue. Now client correctly shows user names and groups.

Hab ich jetzt mal (auf Debian Stretch) probiert. Klappt, wenn sowohl Server als auch Client in /etc/default/nfs-common NEED_IDMAPD=yes gesetzt haben.

Klar mapped der nur lokal, d.h. die lokalen numerischen IDs.

Und: Anon User gibt dann Murks, wenn 64 und 32 Bit gemischt werden (4294967294 = 0xFFFFFFFE = -2 vs 65534 = 0xFFFE = -2).

Da ich kein Synology o.ä. NAS habe, sondern mir die Dinger mit Debian selbst baue, kann ich zum Verhalten der käuflichen NAS leider nix sagen.

Spaßeshalber hab ich mal auf dem Pi mit Raspbian getestet, da geht das mapping auch.

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Was meinst Du mit: Klar mapped der nur lokal, d.h. die lokalen numerischen IDs.

Ich denk NFSv4 ist dafür da, dass man auf Server und Client nichtdie gleichen uids und gids benötigt.

Prinzipiell funktioniert das bei mir ja auch - wenigstens, wenn ich ein chown ausführe.

Nur nach dem anlegen stimmen die Nutzer eben eben nicht, da die dann wohl erstmal nobody gehören. :-/

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8010

Synology Disktation DS213

Im Prinzip (d.h. für einen "gewöhnlichen" Server) stimmt das ja alles, und Du gehst auch richtig vor (soweit ich dies auf die Schnelle sehe). Doch die Synology-NAS haben eine eigene Rechteverwaltung, und man sollte deshalb bei diesen die Rechte lieber nur über die WEB-Oberfläche (DSM) festlegen. Die seltsamen UID und GID dienen dazu, dass in Samba der Gast-Zugriff problemlos funktioniert. Diesen verwendet Synology intern als Standard.

Wie NFS4 auf der Synology-NAS im Detail funktioniert, weiß ich nicht. Ich nehme an, dass dort die Eigentumsrechte standardmäßig eben auf diese UID und GID gemappt werden, damit Samba und NFS so weit wie möglich kompatibel bleiben. Daran sollte man dann möglichst nichts ändern.

Spaßeshalber hab ich mal auf dem Pi mit Raspbian getestet, da geht das mapping auch

Klar, aber der Pi ist hier ja der Client. Entscheidend ist, was auf der NAS geschieht, und da ist Synology eigen.

AlBundy33

(Themenstarter)

Anmeldungsdatum:
22. Januar 2017

Beiträge: 59

Ihr meint also, dass die Diskstation der Übeltäter ist?

Würde sich ein Umstieg von nfs auf cifs lohnen? Wie stelle ich bei einem cifs-mount sicher, dass alle reinschreiben können? Eine Unterscheidung auf Nutzer- oder Gruppenebene fällt da ja aus.

Al

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8010

Ich denke, das müsste auch mit NFS gehen, wenn Du beim Festlegen der Zugriffsrechte genau so vorgehst, Wie Synology dies wünscht. An den internen Dateirechten der NAS sollte man lieber nicht herumschrauben. – Cifs geht auf jeden Fall, doch NFS ist halt performanter. Ob man dies mit einem Pi überhaupt merkt, weiß ich nicht. Aber ich denke schon.

Wie stelle ich bei einem cifs-mount sicher, dass alle reinschreiben können?

Nötigenfalls mit nounix die UNIX Extensions deaktivieren. Kann jedenfalls nichts schaden. Dann mittels uid=xxx, file_mode=xxx und dir_mode=xxx auf dem Client (Pi) die Dateirechte geeignet simulieren. Fertig. Ein Mapping von Usern und Gruppen usw. ist dann nicht nötig. Siehe dazu auch Samba Client cifs.

Die Diskstation ist kein "Übeltäter", sie ist nur anders. Und sie funktioniert gut und zuverlässig, wenn man ihre Besonderheiten berücksichtigt.

Antworten |