Group Berechtigungen über SMB funktionieren nicht

[ghostadmin]

Folgendes, ich habe z.B. einen Ordner z.B. /var/spool/asterisk/monitor der in einem root SMB Share enthalten ist.
Gebe ich nun einer Gruppe z.B. asterisk Rechte auf diesen Ordner bzw. den Files schreiben und lesen zu können und stecke ich den entsprechenden SMB User in die Gruppe dann kann ich nicht auf die Files zugreifen. Warum ist das so?
Es funktioniert erst wenn der Owner geändert wird.
Wenn Rechte auf everyone vergeben werden, funktioniert es ebenfalls.
Also als ob /etc/group ignoriert werden würde.

Der Ordner hat 755 und das File 660

Alle übergeordneten Ordner haben auch entsprechend +x für everyone.

In der smb.conf steht directory mask 0775 also wird nur write für everyone entfernt.

 

[Dalai]

Wie sieht denn die Freigabe genau aus?

MfG Dalai

 

[ghostadmin]

Nichts besonderes:


[all]
browseable = no
path = /
writable = yes
read only = no
create mask = 0775 # allows max 664 when createing files
directory mask = 0775 #allows max 775 when creating folders

 

[Dalai]

Ohne es jetzt genau zu wissen: Es kann sein, dass die primäre Gruppe eines Nutzers dafür ausschlaggebend ist, welche Rechte ein Nutzer auf ein Verzeichnis auf einer Freigabe hat. Ein Nutzer hat ja irgendeine primäre Gruppe und mit der verbindet er sich und von ihm angelegte Dateien und Verzeichnisse bekommen auch genau diese Gruppe (sofern man in der Freigabe nicht "force group" benutzt). Ich bin mir deshalb nicht ganz sicher, weil ich schon lange ACLs benutze. Die sind viel feiner einstellbar und man muss sich kaum Gedanken um Besitzer/Besitzgruppe eines Verzeichnisses machen - einfach passende ACLs drauf, diese in der Freigabe natürlich einschalten, fertig.

MfG Dalai

 

[ghostadmin]

Korrekt, die primäre Gruppe die in passwd gesetzt ist, ging sogar. Ist mir wohl entfallen ...

Also ignoriert Samba das group file. Jetzt habe ich nt acl support = yes im share gesetzt und es funktioniert.

Musste die ACL auch nicht neu setzen, hat alles gepasst:
# owner: asterisk
# group: asterisk
user::rw-
group::rw-
other::---

 

[Dalai]

Jetzt habe ich nt acl support = yes im share gesetzt und es funktioniert.

Öhm, "nt acl support" ist per default schon yes. Das ist also nicht der Grund.

Musste die ACL auch nicht neu setzen, hat alles gepasst:
# owner: asterisk
# group: asterisk
user::rw-
group::rw-
other::---

Da liegt keine ACL drauf, das sind nur die Basisrechte. Ein

getfacl --skip-base Verzeichnis

dürfte das bestätigen.

MfG Dalai

 

[ghostadmin]

Öhm, "nt acl support" ist per default schon yes.

bei mir augenscheinlich nicht, vielleicht wurde das bei neueren Versionen geändert

Da liegt keine ACL drauf, das sind nur die Basisrechte. Ein

getfacl --skip-base Verzeichnis

dürfte das bestätigen.
MfG Dalai

ACL müssen ja nicht unbedingt erweiterte Rechte sein

 

[Dalai]

bei mir augenscheinlich nicht, vielleicht wurde das bei neueren Versionen geändert

Ich hab nachgeschaut: Samba 3.0.28 (Ubuntu 8.04): Default ist yes, Samba 3.6.3 (Ubuntu 12.04): Default ist yes. Möglich, dass in neueren Sambas der Default dafür geändert wurde, ich halte das aber für unwahrscheinlich, weil mit der Einstellung nichts schiefgehen kann.

Ganz sicher rausbekommen kannst du den Standard, indem du die Einstellung setzt und den Wert in der Ausgabe von "testparm" suchst - taucht er auf, weicht er vom Standard ab, taucht er nicht auf, entspricht er dem Standard.

ACL müssen ja nicht unbedingt erweiterte Rechte sein

Haarspalter .

MfG Dalai

 

[ghostadmin]

Ich hab nachgeschaut: Samba 3.0.28 (Ubuntu 8.04): Default ist yes, Samba 3.6.3 (Ubuntu 12.04): Default ist yes. Möglich, dass in neueren Sambas der Default dafür geändert wurde, ich halte das aber für unwahrscheinlich, weil mit der Einstellung nichts schiefgehen kann.

es ist Samba 4

Ganz sicher rausbekommen kannst du den Standard, indem du die Einstellung setzt und den Wert in der Ausgabe von "testparm" suchst - taucht er auf, weicht er vom Standard ab, taucht er nicht auf, entspricht er dem Standard.

Aber funktionieren tut es doch mit diesem Setting, ohne nicht