TrueNAS v13 - Problem mit SMB Berechtigungen

[Supaman]

Hi Folks,

folgende Ausgangssituation:

Ich habe hier ein AD mit einem Univention Corporate Server auf letztem Patch Stand mit AD 2008r2. Ich bin dabei den TrueNAS v12 Fileserver neu zu strukturieren, sprich Neuinstallation auf letzte Version (v13 Core) und bin bei der Vergabe der Verzeichnis Berechtigungen auf Merkwürdigkeiten gestossen.


Wenn ich auf einem TrueNAS v12 Core eine SMB Freigabe mit ACLs lt. gängiger Anleitung erstelle, ist alles so, wie es sein soll - die ACL Gruppen und Berechtiungen werden bis zur Datei herunter korrekt durch vererbt.

Wenn ich *exakt* die gleichen Einstellungen für die ACLs für Share + Filesystem mit einem TrueNAS v13 für eine Freigabe setze,
ist das bis zur Ordner Ebene in Ordnung, wenn ich mir die Berechtigungen einer Datei an sehe, gibt es folgende Unterschiede:

#1 Fehlermeldung v13
"Da die Berechtigungen auf Datei [xxx.txt] in der falschen Reihenfolge sind, werden einige Einträge möglicherweise nicht funktionieren.

#2
zusätzliche Berechtigungseinträge bei v13:
a) Jeder mit "[x] nur lesen"
b) Name des Users mit "lesen,schreiben, spzielle Berechtigungen"


Ich habe *alles* mehrfach durchgespielt - TN v13 stable und 13.1 - Reihenfolge der ACLs ist irrelevant - bis hin zur TrueNAs neuinstallation - die Fehlermeldung und zusätzliche Berechtigungseinträge bleiben.
Ich habe auch auf Seite von TrueNAS abseites keine weiteren Konfigurationsmölichkeiten gefunden. Bei v12 alles so wie es sein soll.

Meine aktuelle Erkenntnis wäre:
a) TrueNAS v13 und der UCS vertragen sich möglicherweise nicht - Microsoft AD zum testen leider steht nicht zur Verfügung
b) TrueNAS v13 ist in Bezug auf SMB verbuggt

Irgendwelche Ideen ?

 

[gea]

Im Prinzip nutzt jedes *BSD, Linux oder viele Unixe SAMBA als SMB Server. Unterschiede zwischen denen gibt es in erster Linie in der installierten SAMBA Version und unterschiedlichen (vorkonfigurierten) smb.conf Konfigurationsdateien.

Es gibt natürlich das grundlegende Problem dass Windows ntfs ACL in Linux nicht oder nur teilweise meist im AD Modus unterstützt werden (meist nur einfache Posix ACL statt ntfs/NFS4 ACL), dass SAMBA keine eindeutigen Windows SID kann und man daher immer mit Mappings uid <->SID arbeiten muss und es keine lokalen Windows kompatiblen SMB Gruppen (die Gruppen enthalten können) gibt. Man kann jetzt also nur schauen welches SAMBA man hat und wo das anders konfiguriert ist.

SMB ACL ist übrigens der Grund warum ich kein Linux und kein SAMBA nutze. Der OS eigene Solaris SMB Server bietet gerade diese Optionen wie nfs4 ACL (Superset von ntfs ACL mit Vererbung, Posix ACL und traditionellen Unix Permissions, ntfs artige NFS4 ACL im ZFS Dateisystem hinterlegt und nicht vom SMB Server SAMBA gefakt,), Windows SID oder lokale SMB Gruppen und umgeht damit viele Kompatibilitätsprobleme vom Ansatz her. SAMBA muss man da sehr sorgfältig konfigurieren.

Die ACL Reihenfolge sollte kein grundsätzliches Problem sein. Hintergrund ist dass Windows zuerst Deny dann Allow Regeln auswertet während unter Linux/Unix eher die Reihenfolge der Regeln wichtig ist, ein allow gefolgt von einem deny also ein allow als Folge hat während Windows das als deny interpretiert. Deny Regeln sollte man daher vermeiden oder nicht von Windows aus remote setzen.