POSIX AccessControlList - setfacl und Operation not supported

[Christian Seiler]

Hallo Frank,

h1028341:/robert # setfacl -m user:robert:rwx test.test
setfacl: test.test: Operation not supported

Du musst das Dateisystem mit acl-Unterstützung mounten, d.h.:

mount /dateisystem -o remount,acl

Was heißt denn "remount,acl"?

Das heißt, dass das, was unter /dateisystem eingehängt ist, "neu gemountet" werden soll, mit anderen Optionen.

Beispiel:

mount / -o remount,ro

Das würde das Dateisystem, das in / gemountet ist, readonly neu mounten (funktioniert allerdings nur, wenn niemand mehr etwas zum Schreiben offen hat).

Genauso würde

monut / -o remount,acl

das Dateisystem / mit der Option acl neu gemountet werden. Im Gegensatz zu ro ist das aber ein viel geringerer Eingriff, der eigentlich immer funktioniert.

Als Dateisystem wäre dann "reiserfs" (s.u.) einzutragen, oder?

Nein, mit /dateisystem meinte ich, dass Du ja unter Umständen mehrere Partitionen an verschiedene Stellen gemountet hast, z.B. /, /home, /srv oder sowas. Aber wie man aus Deinem Posting erkennt:

/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)

Hast Du nur ein Dateisystem nach / gemountet, d.h. bei Dir sollte funktionieren:

mount / -o remount,acl

kann ich mit o.g. was "kaputt" machen am laufenden Betrieb?

Mit dem Mount-Befehl und acl als Option? Nein. Entweder der funktioniert und Du hast ACLs (d.h. setfacl funktioniert hinterher) oder er funktioniert nicht und Du müsstest den Kernel neu kompilieren.

Das Problem: Der Befehl mount ist temporär, d.h. beim nächsten Reboot ist er weg. Damit das dauerhaft bleibt:

In Deiner /etc/fstab dürfte irgendwo eine Zeile zu finden sein, die ungefähr so aussieht (auf Grund Deiner Angaben habe ich versucht, das möglichst gut zu interpolieren, allerdings kann es durchaus noch kleinere Abweichungen geben):

/dev/vzfs   /   reiserfs     usrquota,grpquota     0 1

Diese Zeile müsstest Du nun ändern in:

/dev/vzfs   /   reiserfs     usrquota,grpquota,acl     0 1

Damit bleibt die ACL-Option auch beim nächsten Booten erhalten.

Das wäre dann in dem Fall ein Reboot über die Admin-Config. Von allein booted der sich glaub ich nicht neu.

Oder wenn der Server, der die VServer hostet, mal abschmieren sollte und der Provider den neu starten muss. Das dürfte zwar extrem selten sein, kann aber schonmal vorkommen. Wäre doch ziemlich blöd, wenn dann die ACLs nicht mehr gingen und Du weil das dann schon viel zu lange her ist nicht mehr wüßtest, was denn nun am System kaputt sei. ;-) Daher sind solche Änderungen grundsätzlich *immer* korrekt nachzutragen, damit spart man sich _enorm_ viele Probleme.

Im _Normfalfall_ sollten die meisten vorkompilierten Kernel ACL-Unterstützung bieten, wenn dies wider Erwarten nicht der Fall sein sollte, müsstest Du wohl oder übel Deinen Kernel mit ACL-Unterstützung für das von Dir gewählte Dateisystem neu kompilieren.

Beim VServer geht das bestimmt nicht.

Dann musst Du hoffen, dass der Kernel das schon kann. Wobei ich schon sagte, dass das in der Regel der Fall ist, es würde mich stark wundern, wenn nicht.

Viele Grüße,
Christian