[Eisfair] [e64]: Gruppenverzeichnis Rechte (einschl. smb)
Marcus Röckrath
marcus.roeckrath at gmx.de
Do Aug 15 18:20:09 CEST 2024
Hallo Rolf,
Rolf Bensch wrote:
> schon klar. Das erklärt aber "492" nicht.
4xx lässt auf einen Systemuser schliessen, deren Nummern dynamisch vergeben
werden, so dass sich aus der Nummer nicht auf den Namen - und damit das
Paket - schliessen lässt.
Du hast wahrscheinlich mal ein Paket installiert gehabt, welchen einen
Systemuser angelegt hat, welcher dann due UID 492 bekommnen hat.
Dieses Paket musst du dann später wieder deinstalliert haben, womit der
Systemuser entfernt wurde.
Es ist halt nun nicht mehr nachvollziehbar, welchen Weg das genau genommen
hat.
>> IMHO ist ACL schon lange aktiv und kann von Anwendungen auch genutzt
>> werden und muss auch nicht exlizit an- oder abgeschaltet werden.
>>
>> Samba setzt in Abhängigkeit von den Fähigkeiten des Kernels:
>>
>> acl group control = yes
>> force unknown acl user = yes
>> inherit acls = yes
>> map acl inherit = yes
>
> Hier sind alle *acl* ind er Samba-Config aus "yes" gesetzt.
Weil der Kernel die Fähigkeit besitzt:
grep posix_acl_ /proc/kallsyms
>> Weiterhin gibt es in der Samba-Konfiguration noch die Option
>> SAMBA_ACL_ATTR.
>
> Hier gibt es ein "SAMBA_ACL_XATTR = no". Darüber hinaus sehe ich im ECE
> keine Möglichkeit ACLs zu beeinflussen. Dadurch bleibt für mich die Frage
> wodurch das aktiviert wurde.
Dies würde bei yes setzen:
acl_xattr:ignore system acls = no
acl_xattr:default acl style = posix
In der Penne habe ich im Datengrab häufig Dateien mit ACLs gehabt, die
allesamt von Win-Clients den Weg auf den Server gefunden haben.
--
Gruß Marcus
[eisfair-Team]
Mehr Informationen über die Mailingliste Eisfair