NFS Server: Wie konfiguriere ich das mehrere Benutzer selbe Dateien schreiben dürfen?

[binary trust]

hi,

ich habe 2 rechner mit 2 verschiedenen benutzern (Userids) die auf aber schreibend auf die selbe nfs freigabe zugreifen müssen. wie stell ich das ganze denn an? bei gleicher userid war das ganze kein problem aber mit unerschiedlichen nutzern weis ich leider nicht weiter.

meine bisherige einstellung:
/srv/www/htdocs/ coding1.domain.tld (rw,sync,all_squash,anonuid=500,anongid=100)

problem ist jetzt alledings das, das auf rechner 1 die userid 500 ist und auf rechner2 die id 1000 .

könnt ihr mir weiterhelfen?
danke

[drcux]

/srv/share/musik/ *(rw,root_squash,sync,all_squash)

so funktioniert es bei mir, alle Dateien bekommen nobody:nogroup mit 755.

[binary trust]

aha,

das ist natürlich auch eine lösung.
aber in diesem fall kann ich auch wieder nur als root schreibend auf die dateien von nobody zugreifen?
als normaler user kann ich dateien zwar lesen aber nicht schreiben, da ich ja auch nicht der eigentümer bin, sonder nobody.

momentan läuft das ganze ja so ab:
-user1 legt datei auf nfsserver an, dieser ändert die rechte auf nobody
-user2 legt datei auf nfsserver an, dieser ändert die rechte auf nobody
-user 1 und user2 haben haben nun keine schreibrechte mehr auf die dateien
- kann man das ganze jetzt rückwirkent machen sprich nobody in lokalen user umwandeln ?

welche lösungen hab ich denn sonst ?


gruß
binary

[wadesch]

da brauchts noch eine zentrale Benutzerverwaltung z.B. NIS/YP oder LDAP

[drcux]

-user 1 und user2 haben haben nun keine schreibrechte mehr auf die dateien


x@y~:cd /netz/musik
x@y:/netz/musik>mkdir test
x@y:/netz/musik>ls -al
drwxr-xr-x 2 nobody nogroup 6 2005-02-09 18:27 test
x@y:/netz/musik>cd test
x@y:/netz/musik/test>touch test.txt
x@y:/netz/musik/test>ls -al
-rw-r--r-- 1 nobody nogroup 0 2005-02-09 18:29 test.txt
x@y:/netz/musik/test>echo "Huhu" >> test.txt
x@y:/netz/musik/test>cat test.txt
Huhu
x@y:/netz/musik/test>rm test.txt
x@y:/netz/musik/test>cd ..
x@y:/netz/musik>rm -r test

geht alles wunderbar...

"man exports" sagt dazu:

all_squash - Map all uids and gids to the anonymous user.

D.h., alles was du machst, machst du als nobody:nogroup

[binary trust]

Es will einfach nicht funktionieren:

hier meine /etc/exports:
/srv/www/htdocs 10.2.3.133(rw,root_squash,sync,all_squash)

Auf dem Server hab ich nun folgendes gemacht:
NFServer:/srv/www # chown -R nobody:nogroup htdocs/
NFServer:/srv/www # chmod -R 755 htdocs/

als normaler benutzer kann ich die dateien nur lesen, aber keine anlegen oder schreiben. wenn ich mich als root anmelde funktioniert das ganze komischerweise.

allerdings hat die datei dann die rechte nobody.nobody.
hab nun die rechte auf nobody.nobody abgeändert, aber auch das lässt denn armen user1 nur lesen.

auf dem client rechner sieht das ganze dann z.b. so aus:
rwxr-xr-x 2 nobody 65533 48 2005-02-11 11:52 test2

anscheinend kennt dieser die groupe 65533 nicht.

woran könnte es denn sonst noch liegen?

hinweis:
auf client und server sind unteschiedliche distries.
der server ist ein suse 9.0 und der client ist ein debian sarge, daher sind die benutzerids ev. nicht gleich. kann es damit was zu tuhen haben?

danke

[drcux]

sehr merkwürdig...

Mein Server ist auch eine SuSE 9.0, Clients SuSE 9.2,8.2 und nen CT-VDR, und bei allen haut es so hin.
Wie mountest du denn die Freigaben?

[binary trust]

ich mounte das ganze über die /etc/fstab.
der eintrag sieht folgendermaßen aus:

10.2.3.134:/srv/www/htdocs /mnt nfs defaults,users,noauto 0 0


binary@debian:~$ mount /mnt/ && mkdir /mnt/test3
mkdir: kann Verzeichnis ,,/mnt/test3" nicht anlegen: Keine Berechtigung

[drcux]

lass mal das "defaults" weg

[dermartn]

hallo *,

ich hab im prinzip das gleiche problem.
auf der client seite kann nur root in den verzeichnissen schreiben.

nfs-server exports:
/verzeichnis/ 192.168.0.27(rw,sync,anonuid=500,anongid=100,all_s quash)

client fstab:
192.168.0.20:/verzeichnis /mnt/verzeichnis nfs noauto,user 0 0

es hat bis vor kurzem auch noch wunderbar funktioniert! serverseitig wurde definitiv nichts verändert.

die rechte in dem verzeichnis:
drwxr-xr-x 4 nfsuser users 4096 2005-02-12 03:02 .

und nfsuser darf rwx und er hat auch die user-id 500 und die group-id 100, die der nfs-client auf dem anderen rechner dann ja "erbt"...

kann mir da jemand weiterhelfen?

- dermartn

[binary trust]

@drcux: hi, hab das default rausgenommen und auch sonst kleine änderungen durchgeführt, leider alles ohne erfolg. meine konfigurationsdateien sehen nun folgendermaßen aus:

Client (fstab):
10.2.3.134:/srv/www/htdocs /mnt nfs _netdev,rw,sync,users,auto 0 0

Server (exports):
/srv/www/htdocs 10.2.3.133(rw,sync,all_squash)

hilft mir das vielleicht weiter und wenn ja wie konfiguriere ich das ganze denn dann:



map_daemon
Diese Option schaltet die dynamische UID/GID-Umwandlung mit dem UGID RPC Protokoll ein. Jede UID in einem NFS-Request
wird übersetzt in die äquivalente UID auf der Server-Maschine und umgekehrt. Diese erfordert allerdings den
rpc.ugidd(8), der auf dem Client laufen muß. Die Voreinstellung ist jedoch map_identity, die alle UIDs so beläßt. Die
normalen Squash-Optionen werden unabhängig von dynamischer Umwandlung angewendet.





@dermartn:
mir ist aufgefallen das du bei all_squash ein leerzeichen hast "s q".
ich hatte damals eine ähnliche konfiguration da und da beide user die gleiche uid hatten (beides suse kisten) ging es auch ohne probleme. nur jetzt wo unterschiedliche uids im spiel sind gibt es probleme mit denn berechtigungen :(
mein alter eintrag sah so aus:
/srv/www/htdocs/ 10.2.3.133(rw,sync,all_squash,anonuid=500,anongid= 100)

[dermartn]

@binary trust
vielen dank für den tipp, war aber nur ein copy&paste fehler meinerseits.
bei mir funzt es jetzt wunderbar.
ich bin mir allerdings nicht so ganz sicher ob es nur am ausschalten (und erst am nächsten morgen wieder anschalten) beider rechner lag, oder am nfs v3 support. den hat der client jetzt noch zusätzlich in den kernel bekommen...

- dermartn

[binary trust]

@ALL, es klappt und ich werde allen künftig noch leidenden NFS Brüdern denn Weg in die Vollkommenheit zeigen:

Serverseitiger Eintrag in der /etc/exports:
/srv/www/htdocs 10.2.3.133(rw,sync,all_squash,map_daemon)

! ! ! M A P _ D A E M O N ! ! !

Clientseitiger Eintrag in der /etc/fstab:
10.2.3.134:/srv/www/htdocs /mnt nfs _netdev,rw,sync,users,auto 0 0

Nun muss allerdings Clientseitig wie in man exports beschrieben, der ugidd-Dienst installiert werden.

! ! ! U G I D D _ D A E M O N ! ! !
Unter Debian geht dies locker flockig mittels apt-get install ugidd und unter SuSE musste ich denn NFS_Server auf denn Client installieren um denn ugidd nutzen zu können (total unlogisch, da ugidd ja ausschließlich clientseitig verwendung findet).

zu allerletzt noch denn nfsserver reloaden und ab geht die post ...

hoffe das ich damit jemand in der zukunft helfen kann ...


gruß
binary trustix