ubuntuusers.de

Ich musste meinen Fileserver der lange Jahre unter Suse gelaufen ist, neu aufsetzen, da sich der Server verabschiedet hat.

Habe den Samba-Server unter 16.04 im Sommer installiert.

Habe damals die config des alten relativ übernommen. Anfangs lief alles ganz gut. Doch so nach und nach begannen Probleme. Die ersten Dinge waren, dass die Freigaben nicht mehr unter den jeweiligen Gruppen liefen. Die Linuxgruppen sind dem Samba Server aber bekannt. Erst nachdem ich alle Freigaben auf die Standardgruppe der User umgestellt hatte war wieder Zugriff möglich. Meine Freigaben haben alle die Berechtigung 0770.

Warum das so ist, kann ich nicht nachvollziehen. Dann hat sich ein weiters Problem ergeben. Ich vermute das liegt an Windows ACLs.

In meinen Netzwerk sind viele Clients unter MacOSX und einige Windowsclients mit Win7 bzw Win10 Das Problem mit den ACLs ist dass die Win10 Clients Dateien mit diesen Rechten auf den Server schreiben.

-rwxrwx---+ 1 tobiaslie bioaustria  12909 Aug 11 15:00 Änderungsprotokoll Ackerfrüchtestandard.xlsx

Diese Daten sind von einem Windows Client jederzeit wieder zu öffnen. Die MacClients bringen die Meldung dass das Dateiformat oder die Dateierweiterung ungültig ist. Das ist unabhängig von der OfficeVersion. Openoffice meldet dass der Zugriff aufgrund fehlender Zugriffsrechte nicht erlaubt ist. Was meiner Meinung eher stimmt. Was eher hinkommt, denn wenn ich mir die ACLs anzeigen lasse bekomme ich mit getfacl [Dateiname]

# file: Änderungsprotokoll Ackerfrüchtestandard.xlsx
# owner: tobiaslie
# group: bioaustria
user::rwx
user:10100:rwx
user:stefaniegil:rwx
user:tobiaslie:rwx
group::-w-
group:bioaustria:---
mask::rwx
other::---

Meine 1. Frage daher, wie kann Samba konfigurieren, bzw auch die WindowsClients, damit ich das ACL - Problem nicht mehr habe.

Die 2. Frage bezieht sich dann auf das eingangs beschriebe Problem, warum alle Sambafreigaben nur mit der Userhauptgruppe funktionieren.

Hier meine smb.conf

[global]
unix extensions = yes
dns proxy = no
writeable = yes
workgroup = BIOAUSTRIA
dns proxy = no
#   wins support = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user

# Freigaben
[marketing_linz]
	create mode = 0770
	directory mode = 0770
	path = /data/marketing_linz
	writeable = yes
[bioaustria]
	create mode = 0770
	directory mode = 0770
	path = /data/bioaustria
	writeable = yes
...

Habe die Lösung gefunden.

habe einfach die Einträge

        inherit acls = no
        inherit permissions = no

hinzugefügt.

Windows legt zwar die ACLs an, das beeindruckt die anderen User aber nicht. Die Dateirechte werden nur über Linux gesteuert.

Da verstehe ich leider manches nicht richtig.

        inherit acls = no
        inherit permissions = no

Dies sind doch normalerweise die Default-Einstellungen. Es sei denn, Du hast vfs objects = acl_xattr gesetzt. Davon sehe ich aber nichts in Deiner smb.conf (?) Meines Wissens ist dies nur für Domain-Controller Default (?):

    Note that using the VFS modules acl_xattr or acl_tdb which store 
    native Windows as meta-data will automatically turn this option on 
    for any share for which they are loaded, as they require this option 
    to emulate Windows ACLs correctly.

    Default: inherit acls = no

Windows legt zwar die ACLs an, das beeindruckt die anderen User aber nicht. Die Dateirechte werden nur über Linux gesteuert.

Das ist doch das Standard-Verhalten ohne VFS modules = acl_xattr. Siehe dazu https://www.samba.org/samba/docs/man/manpages-3/vfs_acl_xattr.8.html 🇬🇧.

Was passiert, wenn man zwar das VFS-Modul acl_xattr lädt, aber dann doch inherit acls = no setzt, weiß ich nicht. Irgendwie ist diese Kombination wohl nicht vorgesehen.

Gruß – Max-Ulrich

Hallo,

Ich hatte mich bisher noch nie mit ACLs auseinandergesetzt.

Darum habe ich bei einer Testfreigabe am gleichen (produktiven) Server div. Dinge probiert. Mit der Einstellung so wie ich sie geschrieben habe funktioniert es. Das ACL Thema hat mich mehr oder weniger überrollt. Es war plötzlich da. Da die User geklagt haben, dass die Dateien nicht öffnen können. Dann habe ich mal begonnen zu suchen, woher das kommt. Dann ist mir eben aufgefallen, dass die Windowsclients das verursachen. Eigenartige war nur, dass bei eineigen Dateien in den ACLs keine Gruppenrechte gesetzt waren. Jedoch ein anderer User unter Windows die Datei öffnen und auch bearbeiten konnte. Mac User oder auch unter Linux nicht, obwohl die UNIX Gruppenrechte von Linux und auch Sambarechte gepasst hatten.

Ich werde jedenfalls noch weiter testen und beobachten.

Gruß Georg

Mit der Einstellung so wie ich sie geschrieben habe funktioniert es.

Das ist schon 'mal gut. ☺ – Nur hätte ich ganz gerne auch wirklich verstanden, warum.

Bleiben wir halt dabei: Never touch a running system…

Gruß – Max-Ulrich

Hallo Max-Ulrich,

Ich belasse des mal so. Ich betrachte das ganz aber nicht als abgeschlossen.

Ich werde mir in den nächsten Tagen einen neuen virtuellen Samba-Server einrichten. Nur mal zu Testzwecken.

Dieser soll auch die Verbindung zum meine, Ldap-Server können. des weiteren werde ich mich nachmals mit der ACL Geschichte auseinander setzen. Und weiters möchte ich auch die Papierkorbgeschichte in Samba mal angehen.

Darum habe ich das Thema auch wieder als unerledigt gesetzt.

Gruß Georg

Und weiters möchte ich auch die Papierkorbgeschichte in Samba mal angehen.

So seltsam das ist, aber das hat ziemlich direkt mit der ACL-Geschichte zu tun. Es geht nämlich hier wie dort um ein VFS-Modul, das aktiviert werden muss. Auf einem Standalone-Server läuft der Netzwerk-Papierkorb ja, doch wie es bei einem AD-DC ist, weiß ich leider nicht. Da scheint es Probleme zu geben (?).

Überhaupt vermisse ich verlässliche Informationen, welche VFS-Module jetzt bei Ubuntu standardmäßig aktiv sind und welche nicht. Offenbar ist bei Dir das Modul ACL-xattr standardmäßig aktiv, sonst würdest Du ja die Option inherit acls = no nicht brauchen. In man smb.conf steht darüber aber nichts, und in Deiner smb.conf entdecke ich auch nichts derartiges.

Oder betreibst Du Deinen Samba-Server vielleicht als AD-DC? Dann wäre das mit den ACLs klar. Dafür wäre es dann interessant, ob Du den Papierkorb eingerichtet bekommst.

Obwohl Samba-4 ja im "Normalfall" (Standalone-Server, übliche Optionen) fast völlig mit Samba-3 identisch ist, gibt es noch manche Rätsel, sobald man vom ausgetretenen Pfad abweicht. Ich jedenfalls blicke da immer noch nicht völlig durch.

Gruß – Max-Ulrich

Ich betreibe ihn als Standalone Server, kein AD.

Habe den Server so konfiguriert wie ich es aus Samba 3 gewohnt war. Hier gab es meines Wissens noch kein ACL. Der alte langjährige Server unter Suse SLES9, ist im Sommer auf Grund eines Platinendefekts gestorben. Hier waren die ACLs kein Thema. Der derzeitige Server unter Ubuntu 16.04 läuft bereits virtuell unter KVM auf Ubuntu 16.04.

Aber wie in meinem Beitrag zuvor angekündigt, ich erstelle mir einen neuen Testserver. Mit Samba habe ich auf Grund der vielen Möglichkeiten immer so div. Probleme, darum will ich wenn es mal läuft wenig herumprobieren.

Gruß Georg

Ich habe jetzt bei meinem "Standalone-Server" Ubuntu Mate 16.04 nochmal nachgesehen:

farber@Desktop-PC:~$ testparm -v | grep acl
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[printers]"
Processing section "[print$]"
Processing section "[Öffentlich]"
Processing section "[Bilder]"
Processing section "[Musik]"
Processing section "[Downloads]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

	acl check permissions = Yes
	acl group control = No
	acl map full control = Yes
	acl allow execute always = No
	force unknown acl user = No
	inherit acls = No
	nt acl support = Yes
	profile acls = No
	map acl inherit = No

Auch eine "jungfäuliche" VM mit Xubuntu 16.04 gab das gleiche Ergebnis. Das heißt, inherit acls = No ist Standard. Und von VFS-Modul = acl_xattr ist nichts zu finden. Weshalb bei Dir die Option inherit acls = No etwas geändert hat, verstehe ich nach wie vor nicht.

Ist es denkbar, dass die Standard-Optionen in der Server-Version von Ubuntu anders sind? Könntest Du dieser Frage bitte 'mal nachgehen?

Gruß – Max-Ulrich

Ich habe jetzt nachgesehen. Die Einstellungen sind bei der Serverversion nicht anders.

Die inherit acls = No ist Standard

Dann ist dieser Eintrag überflüssig.

Dann wird nur mein Eintrag inherit permissions = no etwas bewirken.

Ich werde den Eintrag inherit acls = No mal auskommentieren. Am kommenden Wochenende startet sich der Server sowieso neu, da ja die Images der virtuellen Maschinen gesichert werden. Ab Montag sehe ich dann mehr.

Wenn ich mir die Dump Ausgabe so ansehe, dann müsste ich eigentlich die Standardeinträge:

acl check permissions = Yes
nt acl support = Yes

auf No setzen.

Somit richten die ACLs dann kein Unheil mehr an.

Gruß Georg

Die Sache bleibt nebulös. 😕

Dann wird nur mein Eintrag inherit permissions = no etwas bewirken.

Der ist genau so Default:

…
Press enter to see a dump of your service definitions

	acl check permissions = Yes
	inherit permissions = No

Außerdem dürfte dieser Eintrag das Verhalten gegenüber ACL nicht beeinflussen. Beide Einträge müssten also überflüssig sein, sind es aber offenbar doch nicht. Äußerst seltsam…

Ganz ins Unreine gedacht kann ich mir folgendes vorstellen:

• im Samba-Wiki 🇬🇧 steht folgender Passus:

  Enable extended ACL support in smb.conf
  
  The following is only required on Domain Members and not on Domain Controllers, where this setting is hard coded enabled.
  
  Add the following to your [global] section of your smb.conf:
  
         vfs objects = acl_xattr
         map acl inherit = yes
         store dos attributes = yes
  
  See the smb.conf man page for further details on the parameters.

  Von Standalone-Servern ist hier nicht die Rede (auch sonst nirgends in diesem Zusammenhang…). Sollten die Settings für DCs jetzt auch für Standalone-S gelten, könnte dies manches erklären:

• Falls (entgegen meinen Erwartungen) vfs objects = acl_xattr jetzt auch ohne Eintrag in smb.conf gilt, dann impliziert dies inherit acls = yes, ebenfalls ohne Eintrag in smb.conf. Möglicherweise zeigt testparm -v diese implizite Funktionalität gar nicht an (??). In the smb.conf man page (oben vorgeschlagen) steht leider diesbezüglich nichts drin.

• Sollte diese Vermutung nicht zutreffen, so ist entweder die Dokumentation fehlerhaft (unvollständig ist sie ja sowieso), oder die globalen Einstellungen (beidesmal No) werden nicht richtig auf die einzelnen Shares übernommen. Dies wäre dann aber ein kaum vorstellbarer Samba-Bug.

Doch vielleicht liegt der Hund noch irgendwo ganz anderes begraben. Samba ist für Überraschungen immer zu haben!

Gruß – Max-Ulrich