[linux-l] Stale NFS file handle

[Steffen Dettmer]

* Roland Penzin wrote on Fri, Dec 27, 2002 at 03:29 +0100:
> Am Donnerstag, 26. Dezember 2002 19:22 schrieb Malte Frerichs:
> > > > Can't change Permissons ...(Filename): Stale NFS file handle
> 
> > Hab natürlich die Shares vorher geunmountet (oder heißt es
> > ungemountet??).

> ich würde sagen "unmounted"

Du hast also erfolgreich unmounted (um mich mal der Empfehlung
konform auszudrücken), danach war ls /mnt/ auch leer, ja? Ein
erfolgreiches umount /mnt auf ein NFS System heißt ja gar nix.
Besonders schlimm waren die ersten KernelNFS Versionen, weiß
nicht, ob das inzwischen besser ist... Und direkt nach dem
mounten kannst Du ls machen und alles schick, bloß bei chmod
meckert er dann gleich rum? 

Dann ist's was anderes ;)

> > den drei, von mir getesteten Einstellungen, verkehrt ist. Eine der
> > Varianten muss doch eingentlich zum Erfolg führen.

Nicht probieren, ist ja kein Windows ;)

> > all_squash drin hab, bedeutet das doch, dass jeder Zugriff
> > von jedem Programm auf das gemountete Share mit dem Benutzer
> > und der Gruppe nobody erfolgt.  Die Verzeichnisse werden alle
> > mit
> >
> > rwxr-xr-x  nobody nobody <filename>
> >
> > angezeigt. dann muss es doch klappen.

Was soll da eigentlich klappen? Kompilieren und so? Na ja,
all_squash auf r/w ist nicht unbedingt ideal, weil man nicht mehr
weiß, wer eigentlich was wo schreiben darf. Aber Du hast nicht
wirklich ein Konfigurationsproblem, wenn es "ein bißchen geht".
Ich verstehe Dich so, daß es "irgendwann" mittendrin abbricht,
aber Du per Hand problemlos Dateien anlegen kannst etc, ja?

> ohne genau verstanden zu haben, was für ein problem du hast, sehe ich 
> noch ein verständnisproblem:

Denke, das kam durch das Probieren. 

> (rechte auf der serverplatte) && (rechte der share - operation) && 
> (rechte auf dem klientrechner) = (resultierende rechte)

Ist bestimmt richtig :) Aber sieht kompliziert aus. Einfacher
ausgedrückt, man kann nur einschränken. Das mapping (bzw.
all_squash) ist hier evtl. ne kleine Ausnahme, weil etvl. ein
User nobody Dateien schreiben darf. Eigentlich sagt man aber
"nobody hat keine Dateien", dann paßt das wieder, das verlangt
natürlich, daß auf all_squash's nicht geschrieben werden sollte,
sonst entstehen ja nobody files. Das erreicht man, indem man
all_squash oft mit r/o anwendet (und als PUBLIC schreibt). 

Dies alles sollte aber deterministisch sein. Das heißt, entweder
kannst Du immer eine Aktion durchführen, oder nie. Bei Dir sieht
es so aus, als ob es "ein bißchen" geht. Hört sich dann für mich
mehr nach Inkompatiblität oder Hardwarefehler an. Mit letzerem
hatte ich öfter mal nette Probleme, ein NFS Server mit kleinen
Speicherproblemen ist absolut zum Heulen, schwer zu merken (geht
alles, nur eben nicht immer).

Inkompatiblität ist auch extrem toll, kann gut zu solchen
Phänomenen führen. Hatte solche Probleme auch mal. Da half es ein
bißchen, über /etc/fstab anstatt autofs zu mounten. Ach so, NFS
hat auch noch ein paar Eigenheiten. Ein nettes Detail: wenn man
als root Prozeß ne Datei öffnet, Rechte dropt und forkt (oder
umgekehrt?), darf man normalerweise die Datei noch verwenden.
Über NFS sieht das schnell anders aus, das kann einem bei
Logfiles prima auf den Fuß fallen. Weiterhin kann man Probleme
bekommen, wenn Schreibrechte über den 33. Gruppeneintrag kommen
oder sowas, kann dann auch passieren, daß es lokal geht, vom NFS
Client aus nicht. Aber dann geht es auch wieder immer oder nie.

> normalerweise hat man aber das problem, dem user am client seine 
> SCHREIBrechte zu geben & das in einer sauberen, d.h. 
> sicherheitsbewussten form.

Zum Beispiel: Entweder root_squash oder r/w.
	(es gibt IMHO keinen Grund, für root über NFS zu
	schreiben)

Wenn man z.B. /home/ über NFS bereitstellt, also mit root_squash,
und am besten NIS nimmt, damit die User gleich heißen (ist toll,
wenn auf zwei Clienten zwei verschiedene User UID=500 haben), hat
man so ne Standardanwendung. 

> > Was bedeutet diese Fehlermeldung überhaupt genau???

IMHO: Der Client hat sich ein Handle für ein File geholt. Da
möchte er jetzt ein chmod drauf machen, das geht aber nicht, weil
der Server mit dem Handle irgendwie nix anfangen kann. Sowas
sollte aber eigentlich nicht passieren; wenn die Rechte falsch
sind, erwartet man ein permission denied.

Manchmal hilft ein Blick in's syslog (/var/log/messages), aber
leider ist NFS in der Regel sehr schweigsam.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.