Linux-NFS-Server und SCO-Client

hallo alle zusammen,

hab ein problem mit den berechtigungen auf dem Sco-Client. Linux und SCO können wohl ihre passwort-dateien nicht abgleichen. hab da was von einem rpc.ugidd gelesen, weiss jedoch nicht wies zu handhaben is.

danke im voraus

[thommy]

Der rpc.ugidd ist nur ein Auskunftdienst, der zu UIDs versucht, den Klartextnamen vom Server zu erfragen. Mit den Rechten hat das nichts zu tun.

Ich vermute mal, dass der NFS-Server die Rechte beschneidet, denn am Client kann man nicht viel falsch machen (außer vielleicht read-only mounten...). Am einfachsten ist, Du postest mal die /etc/exports und Deinen mount-Aufruf auf Clientseite.

Thomas

Hallo,

meine exports auf Seiten von Linux sieht
folgendermassen aus:
/home/daten *(rw,no_all_squash)

mit folgendem mount Befehl montiere ich das Volumen: mount -F nfs server:/home/daten /daten

auf dem client hab ich dann auf die verzeichnisse keinen zugriff oder besser ich seh darin gar keine dateien.

client:
drwx______ /home/xx 1 1003 usw..

mfg

[thommy]

Sieht so aus, als würde SCO andere Optionen bei mount verwenden...

Auf den ersten Blick offenbart sich kein Fehler, ich würde zunächst prüfen, ob Server oder Client das Problem darstellt. Dazu kannst Du einen nfs-Mount auf dem Server versuchen: "root@server> mount -t nfs localhost:/home/daten /irgendwohin". Wenn das klappt, passt die Server-Konfiguration.

Wenn's am Client scheitert, kann Dir vermutlich nur die SCO-Doku weiter helfen. Denn es scheint, als ob es beim NFS dann doch Unterschiede zur Linuximplementierung gibt.

Thomas

Wenn ich auf dem Server nfs mounte, hab ich das gleiche Problem wie auf dem Client

mfg

Hallo Thomas,
ich hab das problem gelöst.
es fehlte in der exports die option no_root_squash.

mfg

[thommy]

"no_root_squash" verhindert aber nur das Mapping der UID 0 auf nobody (-2). Die Option hat eigentlich nichts mit dem von Dir beschriebenem Problem zu tun???

Thomas

scheint damit aber zu funktionieren

es scheint für mich wohl doch ein Problem der Berechtigunge gewesen zu sein. Denn wenn ich die Berechtigungen auf 777 im freigegeben Verzeichnis geändert hab, konnte ich die Dateien im NFS-gemóuntetem Volume sehen und auf zie zugreifen. bei 700 war das nicht der Fall. Auch hat er mir nicht den Eigentümer übernommen.

mfg

[thommy]

"...Denn wenn ich die Berechtigungen auf 777 im freigegeben Verzeichnis geändert hab, konnte ich die Dateien im NFS-gemóuntetem Volume sehen und auf zie zugreifen. bei 700 war das nicht der Fall..."

Das sieht für mich so aus, als würde root der Besitzer des frei gegebenen Verzeichnisses sein, dann ist klar, das nichts sichtbar ist, da ja einzig root bei "700" das Verzeichnis listen/betreten darf. Da aber root ohne die Option "no_root_squash" auf einem importierten Verzeichnis quasi nicht existiert, kann niemand etwas damit anfangen.

Ändere also den Besitzer des Verzeichnis auf einen "Nicht-Root-Benutzer" und es sollte wie erwartet funzen.

Thomas

der Besitzer des freigegebenen Verzeichnisses ist nicht root. auf dem nfs gemountetem übernimmt er aber nicht den benutzer sonder die uid, diesen "Benutzer" aber kennt natürlich SCO nicht.

mfg

[thommy]

"Houston, wir haben ein Problem." http://www.linuxforen.de/ubb/smile.gif

Wenn ich Dich richtig verstanden habe, möchtest Du, dass nur der Eigentümer einer Datei (der Linuxkiste) von SCO aus diese bearbeiten darf.

Da aber für Unix nur die UID zählt und die Benutzerkennungen nichts anderes als eine Art Alias für die UID sind, tritt der Effekt auf, dass SCO manche UID nicht kennt. Und hier gibt es nur zwei Möglichkeiten, um einen Abgleich zu erreichen.

1. Unter SCO legst Du die Benutzer in der Passwortdatei mit denselben UIDs an, die auch Linux verwendet (bei einigen, wenigen Benutzern sinnvoll)

2. Du richtest NIS ein, d.h. die Passwortdatei gibt es in der NIS-Domäne nur einmal und wird zwischen den einzelnen Rechnern geshared.

Dein bisheriges Vorgehen ist nur geeignet, wenn auf die importierten Daten nur lesend zugegriffen werden soll.

Thomas