Man sollte immer das grundsätzliche Problem im Hinterkopf haben:
ZFS ist ein Unix Dateisystem bei dem die Dateirechte gegenüber dem Betriebssystem ausschließlich über UID und GID Kennungen betrachtet werden. Das betrifft Solaris genauso wie andere Unix Abkömmlinge wie OSX/ BSD oder das unixoide Linux.
Wenn man nun darauf Fileservices wie AFP, NFS oder SMB aufsetzt, so ergeben sich daraus zwei Anforderungen. Erstens muss das entsprechende Protokoll unterstützt werden, also AFP (melde dich im Netz so wie ein Mac), NFS (kein Problem, wurde von Sun unter Solaris entwickelt) oder SMB (verhalte dich im Netz so wie ein Microsoft SMB Server).
Das zweite ist die Frage der Datei-Permissions. Solange es sich um Unix-Services wie AFP oder NFS handelt, ist das recht problemlos. Die kennen ja auch auf dem Ursprungssystem nur UID/GID Dateisysteme und Strukturen. Bei SMB sieht das ganz anders aus. Windows geht mit NTFS weit über die Möglichkeiten von herkömmlichen Unix Dateisystemen hinaus. Das betrifft die viel feineren Rechte, die ganzen Vererbungssachen und bei Gruppen z.B. die Möglichkeit von Gruppen in Gruppen. Der einfache Ansatz wäre jetzt, nur die Unixoptionen anzubieten. SAMBA geht diesen Weg.
Solaris versucht jedoch mit dem eigenen SMB Server die Optionen des NTFS Dateisystems anzubieten. Dazu brauchts eine zusätzliche SMB Gruppenverwaltung, die Speicherung von Windows SID als erweiterte ZFS Attribute, die weitgehende Unterstützung der Windows ntfs ACL (gelungen bis auf Deny Rules, die werden anders gehandhabt) und eine "Übersetzung" der Windows SID in die tatsächlichen UID/GID Dateiattribute beim SMB Zugriff. Die Unixrechte müssen ja auch für Solaris SMB gelten, auch wenn der auf die Windows SID schaut.
Der Schlüssel dazu ist idmapping . Wenn man eine Active Directory hat, passiert das temporär/ automatisch mit ephemeral Mappings im Hintergrund. Man hat damit als User nichts zu tun. Selbst ein Backup/ Restore auf einen anderen Server erhält alle Rechte bei. Das tut einfach ohne dass man etwas machen muss.
Im Workgroup Mode ist das schwieriger. Da ist es ähnlich wie bei Windows. Wenn man Windows neu aufsetzt und eine Platte importiert, passen die Rechte auch meist nicht mehr und müssen neu gesetzt werden (unbekannte SID). Unter Solaris sollte das klappen wenn man den Hostname beibehält und alle User und Groupsettings (sowohl Unix wie SMB) exakt gleich neu anlegt. Waren nur User-Rechte gesetzt, genügt es, die User mit der gleichen UID/GID neu anzulegen. SMB Groups machen es da etwas schwieriger da man die Option hat über ein festes Mapping Windows Group => Unixgroup zu arbeiten oder das zu ignorieren und nur mit SMB Groups zu arbeiten (default Verhalten).
ZFS ist ein Unix Dateisystem bei dem die Dateirechte gegenüber dem Betriebssystem ausschließlich über UID und GID Kennungen betrachtet werden. Das betrifft Solaris genauso wie andere Unix Abkömmlinge wie OSX/ BSD oder das unixoide Linux.
Wenn man nun darauf Fileservices wie AFP, NFS oder SMB aufsetzt, so ergeben sich daraus zwei Anforderungen. Erstens muss das entsprechende Protokoll unterstützt werden, also AFP (melde dich im Netz so wie ein Mac), NFS (kein Problem, wurde von Sun unter Solaris entwickelt) oder SMB (verhalte dich im Netz so wie ein Microsoft SMB Server).
Das zweite ist die Frage der Datei-Permissions. Solange es sich um Unix-Services wie AFP oder NFS handelt, ist das recht problemlos. Die kennen ja auch auf dem Ursprungssystem nur UID/GID Dateisysteme und Strukturen. Bei SMB sieht das ganz anders aus. Windows geht mit NTFS weit über die Möglichkeiten von herkömmlichen Unix Dateisystemen hinaus. Das betrifft die viel feineren Rechte, die ganzen Vererbungssachen und bei Gruppen z.B. die Möglichkeit von Gruppen in Gruppen. Der einfache Ansatz wäre jetzt, nur die Unixoptionen anzubieten. SAMBA geht diesen Weg.
Solaris versucht jedoch mit dem eigenen SMB Server die Optionen des NTFS Dateisystems anzubieten. Dazu brauchts eine zusätzliche SMB Gruppenverwaltung, die Speicherung von Windows SID als erweiterte ZFS Attribute, die weitgehende Unterstützung der Windows ntfs ACL (gelungen bis auf Deny Rules, die werden anders gehandhabt) und eine "Übersetzung" der Windows SID in die tatsächlichen UID/GID Dateiattribute beim SMB Zugriff. Die Unixrechte müssen ja auch für Solaris SMB gelten, auch wenn der auf die Windows SID schaut.
Der Schlüssel dazu ist idmapping . Wenn man eine Active Directory hat, passiert das temporär/ automatisch mit ephemeral Mappings im Hintergrund. Man hat damit als User nichts zu tun. Selbst ein Backup/ Restore auf einen anderen Server erhält alle Rechte bei. Das tut einfach ohne dass man etwas machen muss.
Im Workgroup Mode ist das schwieriger. Da ist es ähnlich wie bei Windows. Wenn man Windows neu aufsetzt und eine Platte importiert, passen die Rechte auch meist nicht mehr und müssen neu gesetzt werden (unbekannte SID). Unter Solaris sollte das klappen wenn man den Hostname beibehält und alle User und Groupsettings (sowohl Unix wie SMB) exakt gleich neu anlegt. Waren nur User-Rechte gesetzt, genügt es, die User mit der gleichen UID/GID neu anzulegen. SMB Groups machen es da etwas schwieriger da man die Option hat über ein festes Mapping Windows Group => Unixgroup zu arbeiten oder das zu ignorieren und nur mit SMB Groups zu arbeiten (default Verhalten).
Zuletzt bearbeitet:
Ich stehe auf funktionierende Automatismen.
