Moin, cfchris6 schrieb:
Wenn per anongid und anonuid ein nfs Verzeichnis eingebunden wurde, dann werden die remote UIDs und GIDs lokal abgebildet und da auf allen Linux Mashinen root UID 0 hat, wird, wie im vorliegendem Fall, root root angezeigt. Jedoch werden Dateiopertaion mit den Rechten des durch anonuid und anongid angegebenen Benutzers durchgeführt. Wenn dieser Nutzer per ACL Schreibrechte hat, dann darf er auch löschen. Bin mir nur gerade nicht sicher, ob die Remote-ACLs auch lokal durch ein + gekennzeichnet werden. Wenn Ja, dann liege ich mit meiner Annahme natürlich daneben. Daher wäre auch solch ein Szenario denkbar gewesen, aber die Lösung (s.u) ist ja nun eine andere.Was hat das damit zu tun, die Rechte bleiben bei NFS die selben wenn die userids überall übereinstimmen. Und dass "bart" UID 0 hat ist sehr unwahrscheinlich.Handelt es sich dabei um ein lokales Verzeichnis, oder um evtl. eine NFS-Freigabe?
Kann ich auch nicht verstehen. Geht eigentlich nicht, ausser es wären acl im Spiel, die aber nicht erkennbar sind. Partition ist ext3?Nun gehe ich als Benutzer "bart" hin & und fuehre "rm -rf *" im Verzeichnis, in welchem dummy liegt, aus. Ergebnis: dummy ist - entgegen meiner Erwartungen - geloescht, es gibt keine Fehlermeldung.Das Verhalten ist genau so wie es sein soll, wenn dummy in einem Verzeichnis liegt auf das Bart Zugriffsrechte hat. Denn dafür sind schlicht und einfach die Verzeichnisrechte zuständig, dass die Datei nicht w für other hat spielt dabei keine Rolle. Wenn man rm nicht mit -f aufruft wird allerdings eine Rückfrage gestellt ob man die Datei löschen will oder nicht, da sie "schreibgeschützt" ist.
Genau das war die Lösung. Daran hatte ich anfangs auch nicht gedacht. Gruß, Torsten