Samba, Schreibberechtigung für Gruppe

PaulAtreides

Well-Known Member
user1 und user2 sind mitglied in der Gruppe fileserver. Warum hat user2 keine schreibberechtigung für file.text wenn ich die datei in Windows öffnen möchte?

drwxrws--- 4 fileserver fileserver 12 25 Feb. 14:44 .
drwxr-x--- 27 fileserver fileserver 27 14 Aug. 2020 ..
-rwxrwx--- 1 user1 fileserver 21662 10 März 2021 file.text

smb.conf
nfs4:mode = simple
nfs4:acedup = merge
nfs4:chown = no
map acl inherit = yes
nt acl support = yes
 

Yamagi

Possessed With Psi Powers
Teammitglied
Weil ACL die klassischen Unix-Berechtigungen überschreiben. ACL sind ein Quell ewiger Freude... Mache einmal getfacl file.text zum Anzeigen der ACL der Datei. Daran müsste man es sehen können. :)
 

PaulAtreides

Well-Known Member
owner@:rwxpD-aARWcCo-:-------:allow
group@:rwxp--aARWc---:-------:allow
everyone@:------a-R-c---:-------:allow
Da fehlt wohl ein C bei der Gruppe

Wie kann man für das gesamte Verzeichnis der Gruppe das Rechte zum Schreiben geben, inklusive Vererbung

Oder sollte man ACL lieber in ZFS und Samba ausstellen?
 

Yamagi

Possessed With Psi Powers
Teammitglied
Ja, meist fährt man ohne ACL besser. Die ACL braucht man in dem Moment, wo man volle Windows-Berechtigungen auf dem Share nutzen möchte. Damit das sauber klappt, müssen das Samba, FreeBSD und der Client aber idealerweise in der gleichen Domäne sein.

Setzen kann man die ACL mit setfacl.
 

CommanderZed

OpenBSD User
Teammitglied
Du könntest das mit den ACL lassen und ganz klassisch auf Share-Ebene das Mapping auf die Unix-Berechtigungen machen.
 

PaulAtreides

Well-Known Member
Wenn ich das nur in der samba config ausstelle funktioniert das nicht. Dann meckert er immer noch mit den Gruppenrechten. Was muss man bei ZFS ausstellen?
 

PaulAtreides

Well-Known Member
Geht leider immer noch nicht. Bei der Datei zeigt er unter windows zusätzlich zu den normalen Berechtigungen auch noch spezielle Berechtigungen an.

[global]
# Logging
# log level = 3
log file = /var/log/samba4/log.%m
max log size = 50

# Domain & controller & workgroups
server string = NAS Server
workgroup = FIRMA
server string = ATHENA
netbios name = ATHENA

# Network restriction
bind interfaces only = yes
interfaces = lo0 lagg0

# Security model
security = user
encrypt passwords = true

# Time server
time server = yes
load printers = no

template homedir = /fileserver/users/%U
allow insecure wide links = yes

[data]

comment = Daten
path = /fileserver/data
valid users = +fileserver

browsable = yes
writable = yes
read only = no
guest ok = no
public = no
follow symlinks = yes
wide links = yes

# Max
create mask = 0770
# Min
force create mode = 0770
# Max
directory mask = 2775
# Min
force directory mode = 2770

hide unreadable = yes
vfs objects = shadow_copy2 recycle crossrename

shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = -%Y-%m-%d-%Hh%M
shadow: snapprefix = ^zfs-auto-snap_(15min){0,1}(hourly){0,1}(daily){0,1}(monthly){0,1}

recycle:directory_mode = 0750
recycle:subdir_mode = 0750
recycle:exclude = *.tmp *.temp *.swp
recycle:keeptree = yes
recycle:repository = Papierkorb/%U
recycle:versions = yes
recycle:touch = yes
recycle:touch_mtime = yes

crossrename:sizelimit = 50
 

CommanderZed

OpenBSD User
Teammitglied
Du solltest dir evtl. durchlesen was die Optionen genau bedeuten und sie dann anpassen oder ergänzen - eigentlich ist die Samba-Doku hier recht gut strukturiert.

Hier villeicht mal einen einfachen share von meinen privaten NAS:

[jajakai]
comment = jajakai
path = /mnt/daten/jajakai
read only = no
browseable = yes
valid users = jan,mini,kai
create mode = 0770
directory mode = 0770
force group = jajakai

Die Gruppe kenn ich eigentlich nur mit @unixgruppenname, also in meinen beispiel

valid users =@jajakai

Kann aber sein das dies mit AD o.ä. mit dem + korrekt ist.

Damit kommt man eigentlich doch recht weit. Man setzt neu erstellte Dateien mit der richtigen Gruppe und dem richtigen chmod. Alte Dateien sollte man dann ggf. anpassen so das die Gruppe entsprechende schreib und Leseberechtigungen hat. Und dann sollte der Fisch eigentlich gelutscht sein.
 

PaulAtreides

Well-Known Member
A name starting with a '@' is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database.

A name starting with '+' is interpreted only by looking in the UNIX group database via the NSS getgrnam() interface.
NIS hab ich nicht, also ist + richitg

In dem Share Verzeichnis gibt es Verzeichnisse mit verschiedenen Gruppenberechtigungen.
Jeder User ist in der Gruppe "fileserver". Es gibt aber auch noch die Gruppen "vertrieb","einkauf","buchhaltung" wo nicht jeder Mitglied ist.

Das Verzeichnis und die Daten darin, worum es gerade geht, wo der User aus der Gruppe keine Schreibrechte bekommt, ist in der Gruppe "fileserver"

Mit "force group" kann ich kein vernünftiges rechte managment umsetzen
 

CommanderZed

OpenBSD User
Teammitglied
NIS hab ich nicht, also ist + richitg

In dem Share Verzeichnis gibt es Verzeichnisse mit verschiedenen Gruppenberechtigungen.
Jeder User ist in der Gruppe "fileserver". Es gibt aber auch noch die Gruppen "vertrieb","einkauf","buchhaltung" wo nicht jeder Mitglied ist.

Das Verzeichnis und die Daten darin, worum es gerade geht, wo der User aus der Gruppe keine Schreibrechte bekommt, ist in der Gruppe "fileserver"

Mit "force group" kann ich kein vernünftiges rechte managment umsetzen

Ah, ja das kenn ich.
Sowohl in meinen privaten beispiel als auch auf der Arbeit (Ca. 400 User auf einem Fileserver, seit ca. 15 Jahren so strukturiert) habe ich / wir das einfach dadurch gelöst das jede "Gruppe" ihren eigenen Share hat mit der jeweiligen Benutzergruppe e.t.c. und keinen "globalen" mit divers berechtigten Unterordnern.

Hat natürlich auch nachteile, (z.B. das man schnell auf mehrere dutzend shares kommt ab einer gewissen größe die man dann ggf. auf den Clients auch immer hinterlegen muss e.t.c.) ist aber meiner erfahrung nach wesentlich streßfreier was diese Samba-Unix-Berechtigungssache angeht aus genau den Problemen vor denen du stehst.
Zudem gibts auch weitere vorteile z.B. wenn Abteilungsordner (Shares) nicht für alle sichtbar sein sollen weil z.B. noch nicht breit bekannt werden soll das ein bestimmtes Projekt existiert oder man dynamisch immer mal wieder unterschiedliche Gruppen gleichzeitig berechtigen möchte ohne auf ACLs o.ä. zurückzugreifen.

In meinem privaten Beispiel ist der o.G. Share z.B. für alle 3 WG-Mitglieder, aber es gibt auch noch einen bei dem nur ich schreibend und der rest lesend zugreifen kann e.t.c.

Im nachhinnein natürlich u.U. etwas blöd umzusetzen.

Beispiele:

[vertrieb]
comment = Vertrieb
path = /fileserver/data/vertrieb
read only = no
browseable = yes
valid users = @vertrieb
create mode = 0770
directory mode = 0770
force group = vertrieb

[einkauf]
comment = Einkauf
path = /fileserver/data/einkauf
read only = no
browseable = yes
valid users = @einkauf @gsl @edv
create mode = 0770
directory mode = 0770
force group = einkauf
 

PaulAtreides

Well-Known Member
Das ist doch bescheuert wenn die gesamten UNIX Rechte von Samba ignoriert werden und man das nur mit force group hinbekommt.
Bei der Leseberechtigung hält Samba sich ja auch an die UNIX Rechte
 
Zuletzt bearbeitet:

PaulAtreides

Well-Known Member
Ich habe mir das Logfile mit Log Level 5 angesehen, wenn auf die Datei zugegriffen wird.

Dabei kommen dutzendfach immer die gleichen Meldungen.

unix_mode: unix_mode(Share) returning 0770
../../source3/smbd/dosmode.c:423(get_ea_dos_attribute)
get_ea_dos_attribute: Cannot get attribute from EA on file Share: Error = Attribute not found

Did not find user fileserver

user2 opened file Share/test.docx read=No write=No

pdb_default_uid_to_sid: Did not find user fileserver (1005)

pdb_getsampwnam (TDB): error fetching database.
Key: USER_fileserver
 

mr44er

moderater Moderator
Teammitglied
store dos attributes = no

Das wird aber nur eine Falschmeldung sein.

Ich rate, dass der user "fileserver" nicht korrekt angelegt ist oder nicht (mehr) die id 1005 hat.

smbpasswd -a fileserver -> einfach nochmal durchlaufen lassen, das überbügelt und schadet nicht im Sinne, dass es dann irgendwo doppelt wäre.

Wenn du mal deine smb4.conf postest und ein ls -l wäre das hilfreich.
 

christian83

Well-Known Member
Das ist doch bescheuert wenn die gesamten UNIX Rechte von Samba ignoriert werden und man das nur mit force group hinbekommt.
Bei der Leseberechtigung hält Samba sich ja auch an die UNIX Rechte
Ich habe es auch nie hinbekommen Samba sauber zu konfigurieren ohne an den ganzen Rechten herumdrehen zu müssen. Ich würde dir raten mal zu schauen ob du nicht NFS einsetzen kannst. Da fällt viel Ärger weg und schneller ist es meiner Erfahrung nach auch.
 

PaulAtreides

Well-Known Member
store dos attributes = no

Das wird aber nur eine Falschmeldung sein.

Ich rate, dass der user "fileserver" nicht korrekt angelegt ist oder nicht (mehr) die id 1005 hat.

smbpasswd -a fileserver -> einfach nochmal durchlaufen lassen, das überbügelt und schadet nicht im Sinne, dass es dann irgendwo doppelt wäre.

Wenn du mal deine smb4.conf postest und ein ls -l wäre das hilfreich.

Der User "fileserver" war falsch angelegt. Ich habe den User neu angelegt und Samba inklusive Datenbank gelöscht und neu installiert.
An der Urspünglichen Config habe ich nichts geändert.

Den Benutzer und die Gruppe von "file.txt" habe ich auf "fileserver"" geändert.
Die Datei können alle öffnen, abgesehn von einem Windows PC.
Zum testen habe ich ein neuen Benutzer unter Windows angelegt. Das hat das Problem leider nicht behoben.

Ich versteh das nicht.
 

PaulAtreides

Well-Known Member
Ich habe es auch nie hinbekommen Samba sauber zu konfigurieren ohne an den ganzen Rechten herumdrehen zu müssen. Ich würde dir raten mal zu schauen ob du nicht NFS einsetzen kannst. Da fällt viel Ärger weg und schneller ist es meiner Erfahrung nach auch.

So wie ich das verstanden habe gibt es leider kein automatisches mapping zwischen Windows und Unix Usern. Man muss die uid in die reg eintragen. Nicht so toll :/
 

PaulAtreides

Well-Known Member
Hab das Problem gelöst. Es hat sich herausgestellt, dass das Problem nur bei einem Rechner aufgetreten ist. Durch hinzufügen von Vertrauenswürdigen Speicherorten im TrustCenter von Office konnte ich das Problem lösen. Warum das bei den anderen Rechnern nicht nötig ist, weiß ich nicht.
 
Oben