TrueNAS - Windows-SMB-Freigabe per ACL - Ordner nur sehen

[DirkTripleD]

Guten Tag allerseits,

ich habe lange nach einer Lösung gesucht und finde leider nichts passendes.

Ich liebe TrueNAS, habe aber lange nichts mehr mit Linux gemacht und bin anscheinend zu doof...

Alles klappt wunderbar, nur bei folgendem habe ich ein Verständnisproblem:

Auf dem TrueNAS-Server sind in der Freigabe folgende Ordner enthalten:

01 - Ordner 01
02 - Ordner 02
03 - Ordner 03

usw.

Es gibt für alle Ordner einen berechtigten user1. Alles klappt wunderbar.

Jetzt soll der Ordner "03 - Ordner 03" nur für user2 zugänglich sein. Dafür habe ich logischerweise user2 angelegt.

Nach verschiedenen Fehlermeldungen bei der Rechteveränderung an dem Ordner unter Windows habe ich zusätzlich den User "fileadmin" angelegt und auf dem TrueNAS unter "Freigaben" -> "Windows Freigaben (SMB)" -> "Dateisystem-ACL bearbeiten" dem User unter Berechtigungen zusätzlich "Full Control" erteilt.

Wenn ich jetzt wieder unter Windows mit dem user "fileadmin" in der Freigabe die Dateisystem-Berechtigungen anpasse (ich habe den Ordner "03 - Ordner 03" mit User fileadmin erstellt, damit er der Besitzer ist), dann bekomme ich nur folgendes hin:

1) User user1 sieht die Freigabe nicht

2) User user1 sieht die Freigabe, kann den Ordner auch öffnen, sieht dann nichts (also die Dateien vom user2 nicht, das ist ja schonmal gut) außer selbst erstellte, leere Dateien.

Letzteres hat den komischen Nebeneffekt, dass wenn er beispielsweise Textdateien dort erstellt, dies mit einer Fehlermeldung abbricht, die Textdatei aber mit dem Namen "Textdokument (neu)" vorhanden ist. Die der user1 aber logischerweise weder öffnen / bearbeiten noch löschen kann.

Noch zu 1) Wenn der user1 den "03 - Ordner 03" nicht sieht und jetzt selber einen "03 - Ordner 03" erstellen will, dann bricht das mit einer "Umbenennungsfehlermeldung" ab, das finde ich auch nicht so geeignet. Und wenn er jetzt den Ordner "03 - Ordner 03b" erstellen würde, dann sähe das wieder blöd für die aus, die alle Ordner sehen...

Beides ist nicht das, was ich will. Der user1 soll den Ordner sehen, ihn aber nicht öffnen dürfen (Fehlermeldung: Sie haben keine Rechte).

Was mache ich falsch?

Vielen Dank & viele Grüße

d i r k

 

[micneu]

bitte screenshot zu:
- Windows Share ACL (Filesystem)

warum machst du die berechtigung auf benutzer, ich habe gute erfahrung damit gemacht alles über gruppen zu machen, so kann ich dann die benutzer bei bedarf immer in die entsprechenden gruppen zu packen
z. b.
bilder_rw = lesen/schreiben auf die freigabe
bilder_ro = nur lesen

 

[DirkTripleD]

Hallo micneu,

danke, ich wusste, dass das kommt... Weil das System total simpel ist, normalerweise mache ich da sauch so, für bisher einen User habe ich es mir diesmal aber erspart.

Es ist übrigens eine Freigabe mit so 30 Ordnern, deswegen wollte ich nicht eine weitere Freigabe für nur einen Ordner hinzufügen, kann aber auch sein, dass ich das System total falsch verstehe... Also ich habe eine Windows-Freigabe!

Danke!

 

[micneu]

wie du hast eine windows freigabe?
ich mache es immer so das ich bestimmte bereiche trenne und entsprechend habe ich auch gruppen, ich gebe immer nur rechte auf die erste ebene und die ist recursive. in meinem job hatte ich schon mit einigen fileservern zu tun und habe mit schmerzen gelernt das es nicht gut ist in tiefverzweigten verzeichnis struckturen rechte zu geben.

 

[DirkTripleD]

Hallo micneu,

ja, sage ich im Vorfeld den Kunden normalerweise auch immer (also dass sie sich mit mir über die Struktur Gedanken machen sollen), ist aber eine temporäre Redaktion, ist jetzt leider so gewachsen...Allgemein würde ich es eher auch anders machen, ich hätte aber gerne ein "best practices" für "meinen" Fall, falls es so etwas gibt...

Zuerst hieß es "die brauchen gar keinen Server", dann "für zwei, drei Dokumente". Dann haben sie auf einmal den Server mit Dateien befüllt, sogar den Videos der Staffel 1 - obwohl ich im Vorfeld explizit gesagt habe, der ist nur für Office-Dokumente!

Ist in der Medienbranche leider so (chaotisch).

 

[micneu]

da bin ich dann raus, viel glück

 

[bic]

Ist in der Medienbranche leider so (chaotisch).

Ich sag es ja immer wieder, macht das Ganze doch mit Zvols. Dann verbleibt die gesamte Rechtevergabe bei Windows und man erspart sich die Rumturnerei zwischen den SMB-ACLs und den Windowsrechten

 

[DirkTripleD]

Hi bic, ok, danke, muss ich auf meinem System mal alles durchtesten, wie das dann aus User-Sicht aussieht...

Ich frage mich gerade nur, wie ich das mit den VPN-Zugriffen von Notebook-Clients fürs Home-Office dann mache. Außerdem sitzen zwei Mitarbeiter auch an einem anderen Standort per Site-2-site-VPN angebunden (OMADA SDN).

 

[Patrick M. Hausen]

Ich sag es ja immer wieder, macht das Ganze doch mit Zvols

Und iSCSI oder wie? Kannst du nicht von mehreren Clients aus gleichzeitig mounten, was den Sinn eines Fileservers irgendwie konterkariert.

 

[bic]

Und iSCSI oder wie? Kannst du nicht von mehreren Clients aus gleichzeitig mounten, was den Sinn eines Fileservers irgendwie konterkariert.

Selbstverständlich per iSCSI.

"Fileserver" spielt dann der Initiator, wobei hierfür auch ein schwächlicher Mini-PC ausreicht. Klar ist das Ganze dann keine NAS im orignären Sinne, sonder eher ein im Initator eingebundenes SAN darstellt. Vorteil ist aber eben, dass die über das iSCSI-Target bereitgestellten Datenträger wie normale, interne Festplatten gehandhabt werden und so kein Bruch in der Rechte-/Freigabeverwaltung unter Windows entsteht (hiergegen hilft auch eine AD-Integeration des NAS nicht wirklich) und man Software verwenden kann, welche i.d.R. nicht mit/auf Netzwerkfreigaben arbeitet. Jedenfalls fahre ich das seit vielen Jahren so (seit W2000 und damals mit Open-e), möchte es nicht mehr missen und verwende es selbst zu Hause. Schön ist dann auch noch, wenn man denn eine zweite replizierte Maschine hat, diese bei Ausfall der ersten innerhalb von wenigen Minuten im Initator eingebunden ist, ohne dass man dann an den Rechten etwas drehen muss.

Aber jeden Tierchen sein Pläsierchen

 

[DirkTripleD]

@bic: Ok, jetzt habe auch ich es begriffen...

Ich habe das früher oft so ähnlich gemacht, die letzten 10 Jahre aber nicht mehr, werde aber nochmal darüber nachdenken. Bei obigem Szenario macht es imho keinen Sinn (für mich).

 

[bic]

Bei obigem Szenario macht es imho keinen Sinn (für mich).

Gut, das muss nun wirklich jeder für sich entscheiden.

Ich selbst benutze -seit es mit W2000 eingeführt wurde- das AD und es hatte mich von Anfang an gestört, die Benutzer-, Gruppen- und Computerverwaltung des ADs nicht auch auf dem NAS verwenden zu können und das Ganze daher doppelt machen zu müssen. Obwohl die Verwaltung des ACLs schon damals bei Open-e benutzerfreundlicher war, als heute bei Truenas, ist so etwas fehlerträchtig und nichts ist schlimmer, als wenn durch eine Fehlkonfiguration User Dinge zu sehen bekommen, welche sie nicht sehen sollen oder dürfen. Der Schritt zum SAN war daher nur logisch. Aber wie gesagt, das muss jeder für sich selbst entscheiden.

 

[DirkTripleD]

Welches OS läuft denn bei Dir auf dem Mini-PC / NUC oder wie auch immer?

 

[bic]

Welches OS läuft denn bei Dir auf dem Mini-PC / NUC oder wie auch immer?

W2019, aber das unerheblich, da auch ätere Server- und die PC-Versionen von Windows (soweit diese ins AD aufgenommen werden können) und selbstverständlich auch Linux als iSCSI-Initiatoren dienen können und die Truenas-Zvols immer als interne Platten angesehen und hier mit den üblichen Gepflogenheiten behandelt werden können. Rein theoretisch sollte dies z.B. auch mit einer Windows-VM auf Truenas selbst funktionieren, habe ich aber noch nicht probiert.

 

[bic]

Hier mal zur Ergänzung:

Drei Truenas-Zvols auf einem wirklich kleinen Rechner, nämlich einem Asus Tinker Board 2S SBC (arm 6-Kern RK3399 SoC) unter Debian12. Die Volumen können dann ganz normal gemountet und mit den ACLs des Rechners verwaltet werden.

 

[Patrick M. Hausen]

Aber TrueNAS/Samba verwendet doch dieselben Windows-ACLs wie ... Windows? Was gewinnt man, wenn man einen extra Fileserver dazwischen schaltet? Oder sogar Linux - das ist dann doch auch wieder Samba.

 

[DirkTripleD]

@bic: Ok, danke, ich verwende aber bei den oben genannten Installationen serverseitig keine Microsoft-Produkte.

Aus verschiedenen Gründen, teilweise, weil mehrere Server vorhanden sein können usw.

Der TrueNAS synchronisiert auch beispielsweise zu Hetzner, macht vom SSD-RAIDZ Snapshots auf ein HDD-RAIDZ (vom Kunden theoretisch sogar lesbar im Nur-Lese-Modus), ich brauche immer IPMI usw... Also für mich ist das mit dem NUC keine Lösung. Ich habe sogar entnehmbare Wechsellaufwerke in den Servern usw. Eigentlich könnte ich auch LTO im TrueNAS gebrauchen, das mache ich aber mittlerweile anders.

Und das sage ich, obwohl ich ca. 10 NUCs hier stehen habe (für andere Sachen).

 

[bic]

Aber TrueNAS/Samba verwendet doch dieselben Windows-ACLs wie ... Windows? Was gewinnt man, wenn man einen extra Fileserver dazwischen schaltet? Oder sogar Linux - das ist dann doch auch wieder Samba.

Naja, dass ist jetzt aber stark vereinfacht, aber davon einmal abgesehen, hängt man ein NAS mit SMB-Shares in ein Netzwerk mit einem Windows AD, kann man vielleicht und wenn alles klappt, die Benutzer und Gruppen und deren Authentikation aus dem AD übernehmen. Das war es dann aber schon, denn die Zugriffssrechte auf die Shares muss man dann explizit auf dem NAS regeln (daher zusätzlich zum AD) und das ist umständlich, mühselig und fehlerträchtig. Per iSCSI eingehängte Volumen kann man demgegenüber wie interne Laufwerke behandeln, damit bleibt die Rechteverwaltung konsistent - die Gefahr hier Fehler zu machen verringert sich.

An sonst gibt es eigentlich kein extra Fileserver, denn idealer Weise hängt man die iSCSi Volumen in den Rechner ein, welcher ohnehin die Severrolle für Datei- und Speicherdienste im AD ausführt, das kann (bei kleinen) Netzwerken gern auch der Domänen-Controller selbst sein:

Aber auch in einem Netzwerk, welches ein Server unter einem unixartigen OS orchestriert (z.B. unter Zentyal), macht die Einbindung in diesem Server sinnvoll, da auch dann die Rechteverwaltung auf diesen Server beschränkt bleibt und man das NAS diesbzgl. nicht "anfassen" muss.

Anders sieht es natürlich aus, wenn man sein Netzwerk ohne ein AD oder ähnliches, quasi nur mit Workgroups betreibt, dann kommt es ohnehin auf einen Tick mehr Verwaltungsaufwand und eine zusätzliche Fehlerquelle nicht mehr an.

Übrigens - dass ich oben die Einbindung von iSCSI-Volumen unter Debian dargestellt habe, hatte lediglich den Hintergrund zu zeigen, dass die Hardwareanforderungen diesbzgl. derart gering sind, das hierfür ein SBC reicht.