PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFS3 und openSUSE 13.1 (Nobody/Nobody)



f_m
13.09.14, 21:24
Habe kürzlich das Upgrade von 12.x auf 13.1 und seither werden alle NFS3 Shares von der NAS-Box nur noch als User nobody, group nogroup gemountet. Software auf dem NFS Server also der NAS Box ist unverändert und Konfiguration wurde auch weder dort noch auf dem Client verändert.
Das hinzufügen von nfsvers=3 in der /etc/fstab am Client änderte auch nichts an dem Verhalten. Was kann ich tun um das alte Verhalten wiederherzustellen also damit wieder jeder Benutzer mit seiner UID und GID auf den nfsmount zugreifen kann?

muck19
14.09.14, 10:09
Habe kürzlich das Upgrade von 12.x auf 13.1 und seither werden alle NFS3 Shares von der NAS-Box nur noch als User nobody, group nobody gemountet.
Poste mal deine /fstab -

Gruss
Michael

f_m
15.09.14, 13:16
Poste mal deine /fstab -

das wären die beiden Mounts um die es geht:


192.168.0.100:/mnt/data /opt/sin/data nfs rw,noauto,users,noexec,rsize=1024,wsize=1024,timeo =14,intr,udp 0 0
192.168.0.100:/mnt/bkup /opt/sin/bkup nfs rw,noauto,users,noexec,rsize=1024,wsize=1024,timeo =14,intr,udp 0 0

unter openSUSE 12.x konnte ich damit bzw. kann ich vom Laptop aus (dort hab ich noch kein Upgrade gemacht) mit den nromalen Benutzer- und Gruppenrechten auf die NAS-Box zugreifen während das bei SuSE 13.1 auf nobody/nobody gesetzt wird. Hab dann noch nfsvers=3 zu den fstab Optionen hinzugefügt was aber auch keine Änderung des Verhaltens bewirkt.

muck19
15.09.14, 13:38
während das bei SuSE 13.1 auf nobody/nobody gesetzt wird.
Wo wird das gesetzt??

In deiner fstab steht meiner Meinung nach viel zu viel Gedönse drin.
Bei mir sieht das so aus:

192.168.2.101:/Desktopbackup /mnt/Desktopbackup nfs defaults 0 0

Gruss
Michael

f_m
15.09.14, 13:58
Wo wird das gesetzt??
Ganz einfach, wenn ich unter SuSE 12.x eine Datei erzeuge auf dem nfs Mount (touch test) dann hat die meine UID und GID (des aktuellen Benutzers), wenn ich das gleiche unter 13.1 mache dann gehört die Datei nobody/nobody. Logischerweise kann ich dann auch keine Dateien, die ich vor dem upgrade erstellt habe mehr bearbeiten oder löschen weil ja die Benutzer nicht mehr übereinstimmen.

Das "Gedönse" hatte alles seinen Grund als ich vor ca. 3 jahren diese NAS-Box einrichtete, sei es weil der Zugriff sonst nicht klappte oder zu langsam war. Ich kann aber jetzt keinen Zusammenhang zwischen diesen Optionen und dem Problem mit den Benutzer-/Gruppenrechten erkennen.
rw, noauto, users ... da die NAS Box nicht immer verfügbar ist wird bei bedarf durch den jeweiligen user gemountet (rw ist wohl überflüssig aber sollte hier nicht das Problem sein)
noexec ... möchte halt nicht, daß Programme direkt von der NAS ausgeführt werden
die restlichen Optionen waren die Ergebnisse langwieriger Versuche um die Performance zu erhöhen, rsize/wsize kam daher, daß es hier noch eine zweite NAS-Box gab die jumboframes konnte und diejenige um die es hier geht eben nicht

f_m
15.09.14, 14:09
Hab es nun mal ohne zusätzlicher Optionen und ohne fstab reproduziert:


# mount -t nfs -o udp 192.168.0.100:/mnt/data /mnt/
# cd /mnt/test
# touch testfile
# ls -l
total 88252
...
-rw-r--r-- 1 nobody nogroup 0 sep 15 2014 testfile


udp Option muß sein, sonst kann man das Gerät gar nicht mounten.

muck19
15.09.14, 18:02
Ganz einfach, wenn ich unter SuSE 12.x eine Datei erzeuge auf dem nfs Mount (touch test)
Wie machst du das? Bitte mal genau beschreiben, damit ich das nachstellen kann.
Was für ein NAS ist das?
nobody/nogroups hab ich noch nie gesehen. Kann mir nicht vorstellen, dass die Susi das macht (?)

Gruss
Michael

f_m
15.09.14, 19:00
Wie machst du das? Bitte mal genau beschreiben, damit ich das nachstellen kann.
Steht doch Schritt für Schritt im Beitrag oben #6

nopes
15.09.14, 20:07
Tja, ich würde meinen, dass die UIDs sich plötzlich unterscheiden, vergleich die doch mal - siehe hier (https://communities.netapp.com/thread/24383). Bei 4, keine Ahnung ob es auch schon bei 3 sowas gibt, ist auch die Rede von /etc/idmapd.conf - siehe hier (http://serverfault.com/questions/514118/mapping-uid-and-gid-of-local-user-to-the-mounted-nfs-share).

f_m
15.09.14, 20:47
Tja, ich würde meinen, dass die UIDs sich plötzlich unterscheiden, vergleich die doch mal - siehe hier (https://communities.netapp.com/thread/24383). Bei 4, keine Ahnung ob es auch schon bei 3 sowas gibt, ist auch die Rede von /etc/idmapd.conf - siehe hier (http://serverfault.com/questions/514118/mapping-uid-and-gid-of-local-user-to-the-mounted-nfs-share).

In die Richtung dachte ich auch schon aber die UID/GID sind unverändert und identisch auf allen Clients seit 3 jahren, hab es auch gerade nochmal überprüft. Auf der NAS-Box habe ich die Benutzer nie eingerichtet, da wird von Anfang an einfach die uid/gid als Nummer angezeigt (wenn man sich per ssh direkt reinhängt und ls -l macht). Das hat auch unter allen 12.x Versionen von SUSE hinweg nie ein Problem dargestellt und problemlos funktioniert; außer bei der 13.1 eben. ;)

idmapd.conf sollte doch eigentlich nur für NFS4 von Bedeutung sein, oder?
Hab aber trotzdem mal testweise dort statt nobody meinen Standarduser eingetragen, bringt aber nichts.. die NFS3 Mounts werden immer noch auf nobody gesetzt.

nopes
15.09.14, 20:50
Wem gehört den /mnt vor dem mount, mal was anderes probiert, wobei auch nicht logisch...

[EDIT]Gibt -v (http://linux.die.net/man/8/mount.nfs) was sinnvolles aus, wenn du mountest?

f_m
15.09.14, 21:13
Wem gehört den /mnt vor dem mount, mal was anderes probiert, wobei auch nicht logisch...

[EDIT]Gibt -v (http://linux.die.net/man/8/mount.nfs) was sinnvolles aus, wenn du mountest?

/mnt gehört root/root genauso wie die Standardmountpoints in der fstab


# mount -t nfs -o udp -v 192.168.0.100:/mnt/data /mnt/
mount.nfs: timeout set for Mon Sep 15 21:11:51 2014
mount.nfs: trying text-based options 'udp,sec=none,addr=192.168.0.100'
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: trying 192.168.0.100 prog 100003 vers 3 prot UDP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.0.100 prog 100005 vers 3 prot UDP port 32780
#

nopes
15.09.14, 23:34
Mal die Ausgaben, vom alten mit dem neuen verglichen? Mehr fällt mir nicht mehr ein. Ok, also sec=none, war mir aufgefallen. Was macht das?
nopes@sandbox:~$ info nfs; #aka: man 5 nfs
...
sec=flavor The security flavor to use for accessing files on this mount point. If the server does not support this flavor, the mount operation fails. If sec= is not specified, the client attempts to find a security flavor that both the client and the
server supports. Valid flavors are none, sys, krb5, krb5i, and krb5p. Refer to the SECURITY CONSIDERATIONS section for details.
...
SECURITY CONSIDERATIONS
NFS servers control access to file data, but they depend on their RPC implementation to provide authentication of NFS requests. Traditional NFS access control mimics the standard mode bit access control provided in local file systems. Traditional RPC
authentication uses a number to represent each user (usually the user's own uid), a number to represent the user's group (the user's gid), and a set of up to 16 auxiliary group numbers to represent other groups of which the user may be a member.

Typically, file data and user ID values appear unencrypted (i.e. "in the clear") on the network. Moreover, NFS versions 2 and 3 use separate sideband protocols for mounting, locking and unlocking files, and reporting system status of clients and servers.
These auxiliary protocols use no authentication.

In addition to combining these sideband protocols with the main NFS protocol, NFS version 4 introduces more advanced forms of access control, authentication, and in-transit data protection. The NFS version 4 specification mandates support for strong
authentication and security flavors that provide per-RPC integrity checking and encryption. Because NFS version 4 combines the function of the sideband protocols into the main NFS protocol, the new security features apply to all NFS version 4 operations
including mounting, file locking, and so on. RPCGSS authentication can also be used with NFS versions 2 and 3, but it does not protect their sideband protocols.

The sec mount option specifies the security flavor that is in effect on a given NFS mount point. Specifying sec=krb5 provides cryptographic proof of a user's identity in each RPC request. This provides strong verification of the identity of users accessâ
ing data on the server. Note that additional configuration besides adding this mount option is required in order to enable Kerberos security. Refer to the rpc.gssd(8) man page for details.

Two additional flavors of Kerberos security are supported: krb5i and krb5p. The krb5i security flavor provides a cryptographically strong guarantee that the data in each RPC request has not been tampered with. The krb5p security flavor encrypts every RPC
request to prevent data exposure during network transit; however, expect some performance impact when using integrity checking or encryption. Similar support for other forms of cryptographic security is also available.

The NFS version 4 protocol allows a client to renegotiate the security flavor when the client crosses into a new filesystem on the server. The newly negotiated flavor effects only accesses of the new filesystem.

Such negotiation typically occurs when a client crosses from a server's pseudo-fs into one of the server's exported physical filesystems, which often have more restrictive security settings than the pseudo-fs.
[EDIT]Also ich würde sagen macht Sinn, aber mal sec=sys probieren tut auch nicht weh ;)


Kann es dir zwar gerade nicht beweisen, denke aber, dass das ein Resultat einer verbesserten Sicherheit ist, immerhin schickst du Sachen im Klartext übers Netz bzw. genau das wird so verhindert -ok, zu mindestens kann man es sich so schön reden :)

Sauerland1
16.09.14, 09:28
Läuft da eventuell apparmor?

f_m
16.09.14, 23:21
Also ich würde sagen macht Sinn, aber mal sec=sys probieren tut auch nicht weh ;)

Danke, das war die Lösung. Mit der Option verhält es sich wieder wie gewünscht, offenbar hat sich hier die Standardeinstellung geändert.

f_m
16.04.15, 16:36
Jetzt wirds mysteriös, nach einem Upgrade von openSUSE 13.1 auf 13.2 schreibe ich nun wieder und diesmal trotz sec=sys als nobody:nogroup auf die NFS Freigaben...
Serverseitig ist Alles beim Alten.

fork
16.04.15, 22:41
Schau Dir mal die *squash* Optionen von NFS an. Vielleicht ist da jetzt per Default was umgestellt.

http://de.linwiki.org/wiki/Linuxfibel_-_Netzwerk_Server_-_NFS_Server

f_m
22.04.15, 11:14
Schau Dir mal die *squash* Optionen von NFS an. Vielleicht ist da jetzt per Default was umgestellt.

http://de.linwiki.org/wiki/Linuxfibel_-_Netzwerk_Server_-_NFS_Server

Danke für den Tipp, konnte mich leider nicht früher mit der Sache befassen weil ich verreist war.

An squashing dacht ich auch schon mal, allerdings ist das ja eine serverseitige Funktion und mein Problem ist am Client zu Hause. Mit den anderen noch nicht upgegradeten Clients klappt ja nach wie vor Alles und der "Server", sprich die NAS Box, läßt nur begrenzt Einstellungen zu. Ein erster Test mit no_squash und root_squash in der /etc/exports der NAS Box war auch wenig erfolgreich, da streikte der nfs Server dann gleich komplett und gab die entsprechenden Freigaben nicht mehr frei. Jedenfalls macht der Server ohnehin kein squashing weil die anderen Clients schreiben auch alle mit ihren Benutzer-/Gruppenrechten.
Daher scheint für mich klar, daß bereits der Client nobody:nogroup an den Server meldet. Ich hab also quasi ein clientseitiges squashing aber wie stell ich das ab?

sysop
22.04.15, 14:45
Ich hatte ähnliche Problem, wenn Server NFS Vers 4 und Client, NFS vers 3 zusammentrafen.
Den Server habe ich auf NFS Vers 3 festgelegt und habe Vers 4 abgeschalten

Die Freigaben habe ich dann mit anonuid und anongid versehen.


Freigabe netz(rw,async,no_root_squash,no_subtree_check,anon uid=0,anongid=5001)

Deine entsprechenden uid`s und gid`s eintragen.

PS
Ach ja, um Vers 4 zu deaktivieren musste ich auf Centos unter /etc/sysconfig/ in der Datei nfs den Parameter


RPCNFSDARGS="-N 4"

setzen

f_m
23.04.15, 09:26
Mein "Server" kann überhaupt kein NFS4 und anonuid/-gid sind keine Lösung weil ja jeder Benutzer mit seiner uid/gid zugreifen soll und nicht Alle mit derselben.

sysop
23.04.15, 13:04
Scheinbar stimmen die UID bzw GID deines Clients nicht mit denen des Servers überein und werden auf nobody gemapped. Ich kann nirgends ersehen, ob und wie du eine zentrale Userverwaltung und so einheitliche UID`s und GID`s sicherstellst.



Der alte User-Space-NFS-Server erlaubte das »Squashen« jeder UID auf jede beliege andere und ebenso konnte jede Gruppenkennung (GID) auf jede andere gemappt werden. Der neuer Kernel-NFS-Server arbeitet wesentlich restriktiver und gestattet einzig, anstatt dem Pseudobenutzer »nobody« bzw. der Pseudogruppe »nogroup« mittels »anonuid=<UID>« bzw. »anonguid=<GID>« andere Kennungen zu vergeben. Diese gelten dann jedoch für beliebige Gruppen oder Benutzer

Daher auch mein Vorschlag, im Falle dass die ID`s nicht übereinstimmen wenigstens eine Feste ID und GID zu vergeben und so zumindest Lesezugriffe zu erlauben.

Ohne das nun wirklich selbst nachvollzogen zu haben, aber die Restriktionen scheinen sich (zumindest teilweise) auf auf den Client zu beziehen, verschiedene Distro-Versionen verhalten sich auch bei mir unterschiedlich am selben Server.

Ich will dir also sicher nicht zu nahe treten, aber das ganze Theater hatte ich wie gesagt auch und habe deshalb für meine 6-8 Leutchen einen NIS-Server zusammengebastelt, der mir einheitliche UID`s und GID`s garantiert. Seither hat die liebe Seele Ruh und alle können wieder werkeln.

Hast du denn mal kontrolliert, ob der zugreifende User die selbe UID/GID wie das Verzeichnis/die Datei besitzt?
Squashing sollte IMHO erst dann zum Zug kommen, wenn regelmässig Abweichende ID`s zum Einsatz kommen.

PS

....weil ja jeder Benutzer mit seiner uid/gid zugreifen soll und nicht Alle mit derselben. .
Das verstehst du glaube ich falsch, das ist, wie ich das sehe, keine Generelle UID/GID sondern kommt zum Zug, wenn UID/GID abweichen.

pibi
23.04.15, 13:05
Du schreibst nur von einer "NAS-Box". Welches Fabrikat? Ich (siehe Signatur) hatte eine zeitlang auch dieses Problem mit dem nobody/nogroup. Da ich als Einzigster auf meine Box zugreife, hat es mich nicht sonderlich gestoert. Allerdings mache ich regelmaessig die Updates, die Synology mir vorschlaegt. Seit einiger Zeit funktioniert es wieder. Leider kann ich im Nachhinein nicht sagen, was genau das Problem beseitigt hat.

Gruss Pit.