Dateiberechtigungen - SMB Freigabe

[MikeFrizz]

Mo 19. Feb 13:24:47 CET 2024

Mich plagt ein mieser Fehler. Und ich habe keine Peilung. Wie sieht der aus?

Eine Truenas Core Installation habe ich als Mitglied einer Active Directory Domain definiert und in Betrieb genommen. Die Anmeldung an der Domain hat gut funktioniert. Alle Gruppen und Benutzer werden in der Freigabenverwaltung angezeigt.
Bei einer SMB Freigabe habe ich massive Schwierigkeiten. Die SMB Freigabe zunächst mit dem ACL Preset "Restricted" eingerichtet. Als Gruppe habe ich eine Active Directorys Gruppe ausgesucht, die volle Kontrolle über die Dateien haben sollte. Ich sollte diese Regel rekursiv auf angewendet werden soll. Für Dateien, die vor der Festlegung dieser Regel existierten, hat die Rechtszuweisung funktioniert.
Legt ein Benutzer eine Datei an, egal mit welcher Anwendung, hat allein der anlegende Benutzer die Rechte Lesen, Schreiben, besondere Rechte.
Ein Dritter kann die Datei nur lesen. Das ist in einem Ingenieurbüro richtig schlecht. Doch was muss ich tun, damit eine neue Datei, von jedem Mitglied der Active Directotry Gruppe die jeweilige Datei bearbeiten kann?
Lasse ich die Regel über bestehende und eben noch gesperrte Dateien laufen, wird diese eben noch schreibgeschützte Datei voll geöffnet. Sie kann also von jedem aus der Gruppe geöffnet und bearbeitet werden.
Welchen Fehler mache ich? Habe ich etwas bei der Rechtevergabe vergessen? Wie lange dauert die Anpassung der Rechte bei sämtlichen Dateien.

Vielen Dank für eure Unterstützung

 

[bic]

Hmm, genau wegen dieser Lästigkeiten bei der Zusammenarbeit von unixartigen OS und Windows, habe ich für die gleiche Konstallation darauf verzichtet, SMB-Shares auf Truenas einzurichten. Ich verwende stattdessen Zvols, welche per iSCSi an einen Windows-Rechner angebunden sind und dort als interne Volumen auftauchen. Dadurch können diese auch genau so behandelt werden, daher Partionierung, Formatierung und Rechtevergabe erfolgt ausschließlich unter Windows. Vielleicht wäre das etwas für Dich?

 

[MikeFrizz]

Hmm, genau wegen dieser Lästigkeiten bei der Zusammenarbeit von unixartigen OS und Windows, habe ich für die gleiche Konstallation darauf verzichtet, SMB-Shares auf Truenas einzurichten. Ich verwende stattdessen Zvols, welche per iSCSi an einen Windows-Rechner angebunden sind und dort als interne Volumen auftauchen. Dadurch können diese auch genau so behandelt werden, daher Partionierung, Formatierung und Rechtevergabe erfolgt ausschließlich unter Windows. Vielleicht wäre das etwas für Dich?

Danke für deine Antwort. Deine Lösung taugt leider nix für die Integration innerhalb einer Active Directory Domain. Der Fehler ist systemimmanent. Also in Angedenken der Eigenheiten von ZFS absolut zu beherrschen.
Nach Veränderungen von Freigaben, nicht unbedingt nach einer Neudefinition einer solchen, ist es sinnvoll, ich würde sogar sagen zwingend erforderlich, das System neu zu starten. Ich wäre dankbar, wenn man mir mitteilte, der ZFS-Cache könnte auch während des Betriebs geleert oder aktualisiert werden. Denn hier legt der Hase begraben.
Nach einem Neustart tritt der von mir oben beschriebene Fehler nicht auf.
Vielen herzlichen Dank für jegliche Mitwirkung
Michael

 

[bic]

Deine Lösung taugt leider nix für die Integration innerhalb einer Active Directory Domain.

Aber selbstverständlich taugt diese dafür, sogar hervorragend , da die Zvols an dem als iSCSI-Initiator dienenden Windows-PC als Direct Attached Storage (DAS) auftauchen. Hier mal bei mir privat auf dem Domänencontroller (G:,H: und I:):

Die Integration in eine Active Directory Domain erfolgt daher genau so, als wären es tatsächlich DAS-Volumen, was, wenn man sich die Geschichte von SCSI anschaut, auch verständlich wird (iSCSI ist vereinfacht gesagt, lediglich die Umsatzung des SCSi-Busses auf IP).

Jedenfalls brauchst Du so auf der Truenas außer dem Root keine weiteren User und sparst Dir das ganze Rechteprimborium, selbst die sogenannte "Verzeichnisdienstintegration" kann man sich sparen, denn Truenas stellt die Volumen lediglich als Blockspeicher zur Verfügung und kennt deren Inhalte überhaupt erst gar nicht.

Ich finde ein solches Vorgehen jedenfalls als ideal und nutze dies derart seit der Einführung des Active Directory mit Windows Server 2000 (damals allerdings nicht mit Truenas, sondern mit Open-e).

Mach Dich doch mal schlau

 

[MikeFrizz]

Jedoch ist die Abarbeitung von GPOs ist so nicht möglich. Und, das Brimborium mit den Rechten ist unerlässlich.

 

[bic]

Jedoch ist die Abarbeitung von GPOs ist so nicht möglich. Und, das Brimborium mit den Rechten ist unerlässlich.

Ich glaube, Du hast das Prinzip nicht verstanden, die Rechte werden für die Volumen komplett unter Windows verwaltet. Truenas agiert in diesem Fall ja nicht als NAS, sondern als SAN und für einen Windowsrechner ist es Wurscht, ob er Platten per z.B. ATA, SCSI, sonstwas oder eben iSCSI einbindet, für den sind es jedenfalls alles interne (DAS) Platten. Und da wirst Du mir jetzt wohl nicht erzählen wollen, dass DAS-Volumen in einem AD-Controller oder irgendeinem in eine AD intergierten PC "die Abarbeitung von GPOs" verunmöglichen sollen

 

[MikeFrizz]

muß ich mich also mal mit beschäftigen, mit dem Thema. Danke für den Hinweis.