Uwe Koloska <m...@koloro.de> (Do 04 Mär 2010 23:11:24 CET):
> Hallo Heiko,
> 
> Am Donnerstag 04 März 2010 schrieb Heiko Schlittermann:
(…)
> > Eigentlich ein Verhalten, das als „root_squash“ bekannt ist, und, wenn
> > es für alle Nutzer gilt, dann als „all_squash“. Default ist beim Export
> > „root_squash“. Das dürfte für normale Nutzer nicht gelten, insofern
> > etwas eigentartig.
> 
> Das weiß ich schon, hätte es aber natürlich noch erwähnen müssen, denn die 
> Nicht-Beachtung dieser Optionen ist ja gerade das, was ich hier nicht 
(…)
> anderen Rechner von der coLinux Maschine (Fedora 10) auf den Server (Debian 
> 4) übertragen wollte.  Dazu sollten natürlich alle Nutzer und Nutzerrechte 
> erhalten bleiben.  Deshalb habe ich natürlich zuerst "no_root_squash" 
> konfiguriert.  Der root konnte trotzdem noch nicht auf das Serververzeichnis 
> zugreifen.  

Das ist merkwürdig.

(…)
> >    -> ein besserer Test wäre hier „mkdir test“, da gäbe es deutlichere
> >    Anzeichen bei Mißerfolg.
> Was gibt es denn da für deutlichere Anzeichen?

Wenn das Objekt schon vorhanden ist, mault es. Und wenn's geht, kannst
Du bedenkenlos das leere Verzeichnis wieder löschen. Wenn Du das mit
touch machst auf eine schon vorhandene (aber wichtige) Datei, wäre das
böse.

> > 2) Was macht ein „mkdir /tmp/test“ als der selbe Nutzr, der „mkdir
> >    /mnt/server/tmp/test“ macht?
> 
> ?? Wo soll ich den ersten Befehl ausführen?

Auf dem Client. Einfach ums zu sehen, wer Du bist. (id sollte es auch
tun, aber man weiß ja nie…)


> Ich kann mir eigentlich nur vorstellen, dass der NFS Client von Fedora 10 
> schon einige NFS4 Eigenschaften nutzt (was unwahrscheinlich ist, da nfs4 beim 
> Mounten explizit ausgewählt werden muss).  Dort gibt es aber einen Dämon, der 
> die Nutzer umschreibt (Name müsste ich morgen nachgucken).  Der ist nur für 
> nobody/nogroup konfiguriert.

Es gibt einen ID-Mapper -- gucke doch mal auf dem Server nach, wem die
Files gehören nach dem Anlegen, wo Dein Client „nobody:nobody“ sagt.

> Eine andere Alternative wären die Sicherheitseinstellungen, obwohl SELinux 
> anscheinend gar nicht aktiviert ist.

Hm, das glaube ich auch eher nicht.


-- 
Heiko

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Lug-dd maillist  -  Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd

Antwort per Email an