PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Sehr komisches Rechteproblem mit NFS



d@tenmaulwurf
28.01.07, 18:53
Also, es gibt hier 2 Versionen der Beschreibung meines Problems, einmal in Prosa und einmal an einem Beispiel.
Wer keine Lust auf den Text hat kann gleich nach unten scrollen :)
Habe versucht das so ausführlich wie möglich zu machen.

Auf dem Server gibt es die Gruppe "storage", welcher der User "Client1" angehört. Der User "Client1" hat die selbe UID/GID wie der Benutzer "daten" des NFS-Clients.
Ein Directory auf dem Server hat nun die Rechte 775 und gehört der Gruppe "storage" (welcher eben auch der User "Client1" angehört).
Wenn ich mich (auf dem Server) als User "Client1" einlogge, kann ich in dem erstellten Directory schreiben.
Wenn ich jetzt aber versuche vom NFS-Client (nochmals wiederholt: dessen Benutzer "daten" die selbe UID/GID hat wie der User "Client1" auf dem NFS-Server) bekomme ich ein "Permission denied".
Grund glaubte ich wäre ein user-squash, also erzeugte ich auf dem Server ein weiteres Directory mit den Rechten 777 / Gruppe "storage" und versuchte in dieses via NFS zu schreiben, was ging.
Ein ls -l auf dem Server auf das vom NFS-Client erzeugt File zeigte mir, dass es dem User "Client1" und der Gruppe "Client1" gehöre - ein squashing findet also nicht statt.
Ein angelegtes File via NFS und lokal als User "Client1" hat also die selbe UID und GID.
Warum kann ich dann in ein 775-chmoddetes Directory nicht via NFS aber als lokaler Benutzer "Client1" schreiben?


Hier das nochmal an Hand eines konkreten Beispiels:

$ ls -l
drwxrwxr-x 2 datenmaulwurf storage 4096 2007-01-27 20:39 775
drwxrwxrwx 2 datenmaulwurf storage 4096 2007-01-28 18:29 777

auf dem server als User Client1:
$ touch 775/lokal
$ touch 777/lokal
$ ls -l 77*/*
-rw-r--r-- 1 Client1 Client1 0 2007-01-28 18:30 775/lokal
-rw-r--r-- 1 Client1 Client1 0 2007-01-28 18:31 777/lokal

auf dem NFS-Client als User "daten" mit der selben UID/GID wie der User "Client1" auf dem Server:
$ touch 777/remote
$ touch 775/remote
touch: 775/remote: Permission denied

auf dem NFS-Client:
$ ls -l 77*/*
-rw-r--r-- 1 daten daten 0 Jan 28 18:30 775/lokal
-rw-r--r-- 1 daten daten 0 Jan 28 18:31 777/lokal
-rw-r--r-- 1 daten daten 0 Jan 28 18:31 777/remote

auf dem Server:
$ ls -l 77*/*
-rw-r--r-- 1 Client1 Client1 0 2007-01-28 18:30 775/lokal
-rw-r--r-- 1 Client1 Client1 0 2007-01-28 18:31 777/lokal
-rw-r--r-- 1 Client1 Client1 0 2007-01-28 18:31 777/remote

Sehr lustig ist jetzt noch folgendes auf dem Client:
$ rm */*
rm: 775/lokal: Permission denied

Obwohl alle Files die selben Rechte hatten, kann ich das lokal im Dir 775 angelegte Testfile vom NFS-Client aus nicht löschen - auf dem Server als User "Client1" hingegen schon.

Vllt. seh ich grad auch nur den Wald vor lauter Bäumen nicht.

Vielen Dank im voraus,

d@tenmaulwurf

d@tenmaulwurf
28.01.07, 19:11
OK, ich hab den Fehler.

Nicht der NFS-Server gibt das "Permission denied" zurück, sondern der Client.
Auf dem NFS-Client existiert keine Gruppe mit der GID, welche gleich der GID der Gruppe "storage" auf dem Server ist - folglich ist mein User "daten" (aus der Sicht des Clients) auch nicht Mitglied der Gruppe (da diese ja nicht exitiert).

Auf dem Client:
$ ls -l
total 16
drwxrwxr-x 2 1000 1001 4096 Jan 28 18:59 775
drwxrwxrwx 2 1000 1001 4096 Jan 28 18:57 777

Ich wäre nie darauf gekommen, dass ich die entsprechende Gruppe auf Clientseite auch anlegen muss.