Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Ich beantworte mal selbst.
Die Volumes (ZVol) sind unter Comstar/ Volumes aufgelistet, es müssen also "nur noch" die LUNs/Targets/Views etc. neu eingerichtet werden. Voila, die Daten bzw. Filesysteme (NTFS) sind komplett wieder da wenn man die Targets verbindet. Wenn doch nur alles so schön einfach wäre
Klasse Sache, vielen Dank zos!
Für mich ist fehlendes Airplay bei Sonos auch ein Ärgernis, deshalb habe ich sofort versucht. Auf meiner produktiven OmniOS funktioniert es nicht, dann habe ich eine frische OmniOS r151020 virtualisiert, dort geht es aber auch nicht. Das Verzeichnis /opt/local gibt es schon gar nicht, nachdem ich es manuell angelegt habe, läuft das Script weiter durch, der service airsonos existiert aber nicht. Ich habe nach der Installation der r151020 direkt den wget Befehl für airsonos abgesetzt. Gibt es weitere Voraussetzungen die ich erfüllen muss, bevor ich mit der airsonos Installation beginnen kann?
Ok, ich arbeite viel mit dem Repo von SmartOS, von daher sind die bei Dir fehlenden Ordnerstrukturen bei mir vorhanden.
Ich habe das Script soeben so angepasst, dass es ggf. fehlende Ordnerstrukturen zunächst anlegt. Ein ebenfalls soeben erfolgter Test mit einer frischen OmniOS Installation (nur Napp-it vorhanden) lief jetzt durch (vorher nicht).
Also aktivere das letzte BE und versuche es nochmal, sollte jetzt wohl klappen...
Ich habe das Script soeben so angepasst, dass es ggf. fehlende Ordnerstrukturen zunächst anlegt. Ein ebenfalls soeben erfolgter Test mit einer frischen OmniOS Installation (nur Napp-it vorhanden) lief jetzt durch (vorher nicht).
Also aktivere das letzte BE und versuche es nochmal, sollte jetzt wohl klappen...
Zuletzt bearbeitet:
Prima zos, vielen Dank. Hat nun auf Anhieb geklappt. Bei drei Sonos Speakern im Haus ist das einfach nur klasse.
Info from OmniTi (OmniOS)
If you are user of LTS (r151014) or Stable (r151020), please "pkg update" and be ready for a new BE and a reboot.
Included in this update are:
- bge fixes on HP Gen9 systems
- MSI-X for NVMe is disable on VMware (where MSI-X is a problem)
- mmap() now properly modifies a file's timestamps in ZFS.
- Default NFS server threads are now increased.
- i40e now uses multiple receive and transmit rings
- One mpt_sas panic bugfix
The install media has been updated too, as the bge fix will help HP Gen9 users. Install media pointers can be found here:
Installation
and for OmniOS bloody:
Because I'm experimenting with Kayak-for-ISO, I want to have fresh illumos-omnios bits (esp. Loader itself) on the public server. I've just pushed new packages (full build) out to the bloody repo. Update highlights include:
- AIO improvements in LX
- Some loader bugfixes
- blkdev fixes for devices with blksize > 512 bytes.
- illumos 7777 "Expose xdf minor nodes when in PV-HVM mode" fix from Delphix. We are taking this pre-integration because of its potential to help the new Kayak-based ISO installer.
I will not be cutting traditional install media, given I'm getting closer on the Kayak-for-ISO front. Existing users should "pkg update". New users should either install the old bits and upgrade, or take their chances on the WIP Kayak-for-ISO installer.
Watch this space for an updated Kayak-for-ISO, which will at least have a controlling-terminal fix in it (so you can do job control on shells, AND invoke format(1M) w/o it complaining about /dev/tty).
Happy updating!
Dan
If you are user of LTS (r151014) or Stable (r151020), please "pkg update" and be ready for a new BE and a reboot.
Included in this update are:
- bge fixes on HP Gen9 systems
- MSI-X for NVMe is disable on VMware (where MSI-X is a problem)
- mmap() now properly modifies a file's timestamps in ZFS.
- Default NFS server threads are now increased.
- i40e now uses multiple receive and transmit rings
- One mpt_sas panic bugfix
The install media has been updated too, as the bge fix will help HP Gen9 users. Install media pointers can be found here:
Installation
and for OmniOS bloody:
Because I'm experimenting with Kayak-for-ISO, I want to have fresh illumos-omnios bits (esp. Loader itself) on the public server. I've just pushed new packages (full build) out to the bloody repo. Update highlights include:
- AIO improvements in LX
- Some loader bugfixes
- blkdev fixes for devices with blksize > 512 bytes.
- illumos 7777 "Expose xdf minor nodes when in PV-HVM mode" fix from Delphix. We are taking this pre-integration because of its potential to help the new Kayak-based ISO installer.
I will not be cutting traditional install media, given I'm getting closer on the Kayak-for-ISO front. Existing users should "pkg update". New users should either install the old bits and upgrade, or take their chances on the WIP Kayak-for-ISO installer.
Watch this space for an updated Kayak-for-ISO, which will at least have a controlling-terminal fix in it (so you can do job control on shells, AND invoke format(1M) w/o it complaining about /dev/tty).
Happy updating!
Dan
Zuletzt bearbeitet:
Hallo an alle, da mich virtualisierung interessiert und ich selber esxi 6u2 nutze bin ich auf euer Thread aufmerksam geworden.
Aktuel nutze ich esxi mit 4 VM's , alle 4 auf Debian basis.
Nun hab mal Spasshalber auf ne extra Platte Debian + Virtualbox drauf gemacht und paar Benchmarks gemacht, ala sysbench usw. ich muss sagen der Unterschied ist deutlich alle noch auf Sockel 2011v0@C602 32 DDR3@1866 mit 2660v2. Mein System ist bis auf Ram und HDD's eigentlich oversized und auch etwas älter. möchte gerne auf 1151@c236 mit nem xeon 1230 v5, ebenfalls mit 32 gb ram umsteigen und etwas Strom sparen.
Deshalb würde ich gerne von @gea wissen ob ich bei esxi bleiben muss oder ob omniOS stabil und performant seine NAS arbeit und gleichzeitig 3 x Linux virtualisieren kann + pci passthrough. Einer von den VM's dient als Netzwerk-Videostream und die anderen 2 meistens im idle mit jeweil 2GB ram und 1 Kern. Zugriff auf Nas hätten 4 Rechner und die 3 VM's, und das alles ohne 10gbe hab mal hier gelesen das viele 10gbe privat nutzen, dafür fehlen mir die Mittel und brauchen tue ich es eigentlich auch nicht. Hier sind für mich Erfahrungsberichte sehr wichtig ....
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
PCI Passthrough geht schon mal nicht, wozu auch? TV Karte oder sowas wird nix werden.
Die LX Zonen liegen direkt auf ZFS. Welche Soft läuft denn auf den Debian VMs ? Evtl. geht das ja sogar direkt mit Illumos.
cu
Die LX Zonen liegen direkt auf ZFS. Welche Soft läuft denn auf den Debian VMs ? Evtl. geht das ja sogar direkt mit Illumos.
cu
@ludwinator
vm's: tv-headent , zoneminder(debian), debian 8 für testzwecke mit ssh und paar Scripte.
wenn LX mit PCI Passthrough nichts anfangen kann, bleibt nur noch virtualbox auf omniOs übrig, ich denke mal da würde PCI Passthrough funktionieren, oder nicht ?
das würde natürlich voraussetzen dass extpack mit installiert ist/wird ...
vm's: tv-headent , zoneminder(debian), debian 8 für testzwecke mit ssh und paar Scripte.
wenn LX mit PCI Passthrough nichts anfangen kann, bleibt nur noch virtualbox auf omniOs übrig, ich denke mal da würde PCI Passthrough funktionieren, oder nicht ?
das würde natürlich voraussetzen dass extpack mit installiert ist/wird ...
Zuletzt bearbeitet:
Die Linux VMs könnte man unter OmniOS als LX Container virtualisieren. Die beeinträchtigen OmniOS auch nicht was Stabilität angeht und kaum was Performance angeht.
Wenn man aber Pass-through möchte (überhaupt oder ohne größere Probleme), geht nichts an ESXi vorbei.
Mit ESXi + OmniOS hätte man noch die Option, Linux voll unter ESXi zu virtualisiseren (inkl. pass-through) oder als Lightweight LX Container unter OmniOS mit direktem Zugriff auf dessen ZFS Dateisysteme aber ohne Pass-through von PCi-e Karten.
Hallo,
Hatte letzte Woche einen Consultant in der Firma, der unter anderem ein ZFS-basiertes TrueNAS System angeboten hat.
Das Wichtigste beim Sizen des Storage-System war für ihn, dass er das System als RAID10 konfigurieren wollte und auf die Frage, warum kein RAIDZ-1 oder RAIDZ-2 kam, die Antwort, dass die maxiale IOPS-Zahl vdev abhängig ist, sprich:
RAIDZ-2 mit 6 Platten hätte dieselbe IOPS-Zahl wie ein Mirrored(2Disks) vdev, da die IOPS an das vdev gestellt werden.
Frage an die Experten: Ist das korrekt?
Ich kann mir nicht vorstellen, ob das stimmt.
Werden die IOPS unter ZFS nur an die VDEVs gestellt und das darunterliegende Disk-Layout hat keinen Einfluss auf die IOPS?
Hatte letzte Woche einen Consultant in der Firma, der unter anderem ein ZFS-basiertes TrueNAS System angeboten hat.
Das Wichtigste beim Sizen des Storage-System war für ihn, dass er das System als RAID10 konfigurieren wollte und auf die Frage, warum kein RAIDZ-1 oder RAIDZ-2 kam, die Antwort, dass die maxiale IOPS-Zahl vdev abhängig ist, sprich:
RAIDZ-2 mit 6 Platten hätte dieselbe IOPS-Zahl wie ein Mirrored(2Disks) vdev, da die IOPS an das vdev gestellt werden.
Frage an die Experten: Ist das korrekt?
Ich kann mir nicht vorstellen, ob das stimmt.
Werden die IOPS unter ZFS nur an die VDEVs gestellt und das darunterliegende Disk-Layout hat keinen Einfluss auf die IOPS?
Man kann sich das so vorstellen.
Wenn man ein Raid-Z vdev hat, muss man beim lesen/schreiben eines Datenblocks die Köpfe aller Platten im vdev positionieren bis der Block gelesen werden kann. Das bedeutet, dass ein Raid-Z (wie auch ein Raid 5/6) soviel raw-iops liefert wie eine einzelne Platte .
Die "gemessenen" iops sind meist höher, da ZFS sowohl beim Schreiben wie beim Lesen mit einem RAM basierten Cache arbeitet.
Bei einem Mirror sind die Schreib-iops auch wie eine Platte, die Lese-iops aber doppelt so hoch, da ZFS von beiden Platten eines Mirrors parallel liest.
Die sequentielle Performance eines Raid skaliert mit der Anzahl der Datenplatten
Hat man mehrere vdevs pro Pool, so skalieren die iops mit der Anzahl der vdevs.
Für die Hauptanwendungen allerdings für die man hohe iops möchte wie VM Storage oder Datenbanken sollte man heutzutage auf SSD oder NVMe only Pools gehen.Aufgrund der überragenden iops im Vergleich zu Platten sind dann auch Raid-Z kein Problem.
Wenn man ein Raid-Z vdev hat, muss man beim lesen/schreiben eines Datenblocks die Köpfe aller Platten im vdev positionieren bis der Block gelesen werden kann. Das bedeutet, dass ein Raid-Z (wie auch ein Raid 5/6) soviel raw-iops liefert wie eine einzelne Platte .
Die "gemessenen" iops sind meist höher, da ZFS sowohl beim Schreiben wie beim Lesen mit einem RAM basierten Cache arbeitet.
Bei einem Mirror sind die Schreib-iops auch wie eine Platte, die Lese-iops aber doppelt so hoch, da ZFS von beiden Platten eines Mirrors parallel liest.
Die sequentielle Performance eines Raid skaliert mit der Anzahl der Datenplatten
Hat man mehrere vdevs pro Pool, so skalieren die iops mit der Anzahl der vdevs.
Für die Hauptanwendungen allerdings für die man hohe iops möchte wie VM Storage oder Datenbanken sollte man heutzutage auf SSD oder NVMe only Pools gehen.Aufgrund der überragenden iops im Vergleich zu Platten sind dann auch Raid-Z kein Problem.
Zuletzt bearbeitet:
Danke für diese Info. Verhält es sich bei SSDs dann auch so, schließlich habe ich da keine zu positionierenden Köpfe mehr, oder ist da auch so, dass die schwächste SSD die IOPS des vdevs vorgibt?
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Es ist eigentlich immer so, daß das schwächste Glied die Gesamtperformance vorgibt, nicht nur bei HDDs oder SSDs
Zuletzt bearbeitet:
Hi,
Ich habe bei meinen Schwiegereltern ein Freenas Laufen. Leider hatte ein SATA Kabel einen Wackelkontakt und die HDD war deshalb für ein paar Wochen offline. Nachdem ich das Kabel getauscht hab wurde die Platte wieder erkannt und ich habe einen Scrub gestartet. Der Pool sieht nun so aus:
Die Frage ist nun: Wie bekomme ich den am sichersten wieder in ordnung?
- ZFS schlägt selber vor: zpool clear! kann ich danach einfach einen Scrub machen und die Platte wird repariert?
- Meine Vorgehensweise wäre: Platte mit sich selbst replacen
Was ist eure meinung dazu?
Gruß,
Marc
Ich habe bei meinen Schwiegereltern ein Freenas Laufen. Leider hatte ein SATA Kabel einen Wackelkontakt und die HDD war deshalb für ein paar Wochen offline. Nachdem ich das Kabel getauscht hab wurde die Platte wieder erkannt und ich habe einen Scrub gestartet. Der Pool sieht nun so aus:
Die Frage ist nun: Wie bekomme ich den am sichersten wieder in ordnung?
- ZFS schlägt selber vor: zpool clear! kann ich danach einfach einen Scrub machen und die Platte wird repariert?
- Meine Vorgehensweise wäre: Platte mit sich selbst replacen
Was ist eure meinung dazu?
Gruß,
Marc
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
die Errors die du da siehst kommen halt daher, weil sich die Blöcke+Prüfsummen inzwischen geändert haben, ganz klar.
Ist der Scrub schon durchgelaufen? Wenn ja würde ich den clear versuchen, evtl. noch einen scrub hinterher.
Alternativ kannst du mit zpool remove Storage ada2 und einen neuen zpool attach die Platte wieder mit der anderen spiegeln.
cu
Ist der Scrub schon durchgelaufen? Wenn ja würde ich den clear versuchen, evtl. noch einen scrub hinterher.
Alternativ kannst du mit zpool remove Storage ada2 und einen neuen zpool attach die Platte wieder mit der anderen spiegeln.
cu
hoppel118
Neuling
- Mitglied seit
- 07.04.2012
- Beiträge
- 232
Hallo Leute,
mein openmediavault3-server (aktuelles debian jessie) hat mich heute morgen darüber informiert, dass es einen Checksum-Error gibt/gab:
Hier die erste Email:
und hier die zweite Email eine knappe halbe Stunde später:
Der zweiten Mail nach (entspricht der Ausgabe von "zpool status") gibt es also keine bekannten data errors. Beim angestoßenen Scrub gab es eine Reparatur mit 0 Fehlern. Hört sich also gar nicht so schlecht an.
Was würdet ihr nun tun? Weiter beobachten oder doch besser gleich die entsprechende HDD austauschen? Ist sowas schon als kritisch zu beurteilen?
Würdet ihr diesen Fehler mit "zpool clear" löschen oder soll ich ihn besser drin lassen. Es sieht zwar nicht schön aus, wenn dort ein checksum error angezeigt wird, spiegelt aber die Realität wieder, so dass es wahrscheinlich sinnvoll ist, den Fehler nicht zu löschen, oder?
Viele Grüße Hoppel
mein openmediavault3-server (aktuelles debian jessie) hat mich heute morgen darüber informiert, dass es einen Checksum-Error gibt/gab:
Hier die erste Email:
und hier die zweite Email eine knappe halbe Stunde später:
Der zweiten Mail nach (entspricht der Ausgabe von "zpool status") gibt es also keine bekannten data errors. Beim angestoßenen Scrub gab es eine Reparatur mit 0 Fehlern. Hört sich also gar nicht so schlecht an.
Was würdet ihr nun tun? Weiter beobachten oder doch besser gleich die entsprechende HDD austauschen? Ist sowas schon als kritisch zu beurteilen?
Würdet ihr diesen Fehler mit "zpool clear" löschen oder soll ich ihn besser drin lassen. Es sieht zwar nicht schön aus, wenn dort ein checksum error angezeigt wird, spiegelt aber die Realität wieder, so dass es wahrscheinlich sinnvoll ist, den Fehler nicht zu löschen, oder?
Viele Grüße Hoppel
Zuletzt bearbeitet:
besterino
Legende
Beobachten.
hoppel118
Neuling
- Mitglied seit
- 07.04.2012
- Beiträge
- 232
Ok, danke für die Info. Mal sehen, was da in den nächsten Wochen so passiert oder nicht passiert.
Die Smartwerte der betroffenen HDD sind grundsätzlich erstmal im grünen Bereich. Werde demnächst bei Gelegenheit mal einen Selftest durchführen.
Gruß Hoppel
Zuletzt bearbeitet:
Ich habe eigentlich nix ... außer ...
Die letzten Wochen konnte ich meinen Umzug auf ein konsolidiertes Home-Lab auch und insbesondere aufgrund dieses Themas erfolgreich planen und durchführen.
Ich setze nunmehr Virtualisierung und NAS mit der napp-it-complete Edition auf einer Maschine ein. Der Energiebedarf meines bisherigen Setups mit Dell T20 und Synology RS815+ war so um die 135 Watt (lt. APC UPS). Bin gespannt, wie sich das ändert, wenn das Backup in die neue Maschine zurückgespielt wurde und ich die "alten" Geräte vom Netz nehme.
Mein Server ist eng an den von vladan.fr angelehnt. Mit 4 6TB-WD-Red im 2 x 2-fach-mirror Pool sowie 2 SSD (mirrored) für VMs, 64GB RAM und E5-2630-LV4 sowie Titanum Netzteil. Das Umflashen des LSI ging, wie im Link beschrieben, binnen weniger Minuten. Man darf nur nicht den Fehler machen, auf Großbuchstaben umzustellen, wenn man die ID der SAS Karte eingeben muss. Shift gedrückt und das Flashen wurde (bei mir) abgebrochen. Kleinbuchstaben und alles wuppte.
Also ... Dank an alle, die hier so munter über ihre Probleme berichten und, an diejenigen, die hier so munter Hilfestellung geben. Top.
Dank auch und insbesondere an Gea, der mit napp-it-all-in-one und seinem unermüdlichen Engagement hier und anderswo Input, Hilfestellung, etc. gibt. Unschätzbar wertvoll, auch Abseits der Complete-Edition für Home User, die ich gestern dann auch erstanden habe. Das ist das Mindeste, was ich denke, dass ich zu Deinem Einsatz beitragen kann
Die letzten Wochen konnte ich meinen Umzug auf ein konsolidiertes Home-Lab auch und insbesondere aufgrund dieses Themas erfolgreich planen und durchführen.
Ich setze nunmehr Virtualisierung und NAS mit der napp-it-complete Edition auf einer Maschine ein. Der Energiebedarf meines bisherigen Setups mit Dell T20 und Synology RS815+ war so um die 135 Watt (lt. APC UPS). Bin gespannt, wie sich das ändert, wenn das Backup in die neue Maschine zurückgespielt wurde und ich die "alten" Geräte vom Netz nehme.
Mein Server ist eng an den von vladan.fr angelehnt. Mit 4 6TB-WD-Red im 2 x 2-fach-mirror Pool sowie 2 SSD (mirrored) für VMs, 64GB RAM und E5-2630-LV4 sowie Titanum Netzteil. Das Umflashen des LSI ging, wie im Link beschrieben, binnen weniger Minuten. Man darf nur nicht den Fehler machen, auf Großbuchstaben umzustellen, wenn man die ID der SAS Karte eingeben muss. Shift gedrückt und das Flashen wurde (bei mir) abgebrochen. Kleinbuchstaben und alles wuppte.
Also ... Dank an alle, die hier so munter über ihre Probleme berichten und, an diejenigen, die hier so munter Hilfestellung geben. Top.
Dank auch und insbesondere an Gea, der mit napp-it-all-in-one und seinem unermüdlichen Engagement hier und anderswo Input, Hilfestellung, etc. gibt. Unschätzbar wertvoll, auch Abseits der Complete-Edition für Home User, die ich gestern dann auch erstanden habe. Das ist das Mindeste, was ich denke, dass ich zu Deinem Einsatz beitragen kann
Zuletzt bearbeitet:
Hier mal ein Update zu meiner Migration und meine lessons learned zur napp-it-all-in-one 
1) Ich habe ESXI jetzt, wie zuvor, auf einen USB Stick installiert. Davon habe ich eine Kopie gemacht und habe damit ein funktionierendes System in sekundenschnelle zurück.
2) napp-it-VM und Firewall-VM auf lokalem ESXI-datastore (=SSD). Beide VMs liegen, nach endgültiger Einrichtung, als Kopie auf einem zweiten lokalen ESXI datastore (ssd). Auf letzteren kopiere ich regelmässig auch alle anderen VMs, die dann aber ursprünglich auf der napp-it-NAS liegen. Damit habe ich alle VMs auch ohne napp-it für den Notfall zur Verfügung. Als Backup Programm verwende ich XSIBACKUP.
1) und 2) haben sich bei der ersten Havarie als nützlich erwiesen. Die erste lokale VM Platte hatte den Geist auch gleich wieder aufgegeben. Ein Recovery war aber schnell erledigt.
3) Probleme hatte ich beim Einrichten der Berechtigungen für SMB Shares. SMB ACL ist schon anders, als SAMBA. gea hat hier aber super geholfen, so dass ich jetzt produktiv bin. So bin ich vorgegangen:
a) SMB und NFS strikt getrennt (!)
b) Share ACL immer auf everybody@full_set
Das waren die Basics. Danach wurde es in einem Fall spannend. Ich wollte das Media-Share (Filme, Fotos, CDs, etc.) nur selbst im Schreibzugriff haben, die Familie und alle Devices sollen ausschliesslich lesend zugreifen können. Und so geht es:
c) Folder ACL auf root@full_set und family@readxs_set
d) c) auf das Filesystem mittels "reset ACLs" mit „current folder + recursive" übertragen
e) die Veränderungen lassen sich auf Konsole der napp-it-NAS mittels /user/bin/ls -v dann auch nachvollziehen
Damit klappt es, wie gewünscht von allen Devices (Sonos, Linux, macOS). Interessant waren noch folgende Stolpersteine:
a) read_set —> kein mount von Linux, Sonos und Mac Clients
b) readx_set —> mount von Linux Clients, Sonos funktioniert, von Mac Clients nicht
c) readxs_set —> mount von Linux, Sonos und Mac Clients funktionieren
sowohl bei b) als auch bei c) können weder Dateien angelegt, noch gelöscht werden … so, wie ich es will.
Vielleicht hilft es wem
Cheers
1) Ich habe ESXI jetzt, wie zuvor, auf einen USB Stick installiert. Davon habe ich eine Kopie gemacht und habe damit ein funktionierendes System in sekundenschnelle zurück.
2) napp-it-VM und Firewall-VM auf lokalem ESXI-datastore (=SSD). Beide VMs liegen, nach endgültiger Einrichtung, als Kopie auf einem zweiten lokalen ESXI datastore (ssd). Auf letzteren kopiere ich regelmässig auch alle anderen VMs, die dann aber ursprünglich auf der napp-it-NAS liegen. Damit habe ich alle VMs auch ohne napp-it für den Notfall zur Verfügung. Als Backup Programm verwende ich XSIBACKUP.
1) und 2) haben sich bei der ersten Havarie als nützlich erwiesen. Die erste lokale VM Platte hatte den Geist auch gleich wieder aufgegeben. Ein Recovery war aber schnell erledigt.
3) Probleme hatte ich beim Einrichten der Berechtigungen für SMB Shares. SMB ACL ist schon anders, als SAMBA. gea hat hier aber super geholfen, so dass ich jetzt produktiv bin. So bin ich vorgegangen:
a) SMB und NFS strikt getrennt (!)
b) Share ACL immer auf everybody@full_set
Das waren die Basics. Danach wurde es in einem Fall spannend. Ich wollte das Media-Share (Filme, Fotos, CDs, etc.) nur selbst im Schreibzugriff haben, die Familie und alle Devices sollen ausschliesslich lesend zugreifen können. Und so geht es:
c) Folder ACL auf root@full_set und family@readxs_set
d) c) auf das Filesystem mittels "reset ACLs" mit „current folder + recursive" übertragen
e) die Veränderungen lassen sich auf Konsole der napp-it-NAS mittels /user/bin/ls -v dann auch nachvollziehen
Damit klappt es, wie gewünscht von allen Devices (Sonos, Linux, macOS). Interessant waren noch folgende Stolpersteine:
a) read_set —> kein mount von Linux, Sonos und Mac Clients
b) readx_set —> mount von Linux Clients, Sonos funktioniert, von Mac Clients nicht
c) readxs_set —> mount von Linux, Sonos und Mac Clients funktionieren
sowohl bei b) als auch bei c) können weder Dateien angelegt, noch gelöscht werden … so, wie ich es will.
Vielleicht hilft es wem
Cheers
Zuletzt bearbeitet:
Bei Solarish muss man lediglich beachten
- Es wird üblicherweise der Solarish eigene, in ZFS integrierte SMB Server benutzt und nicht der optionale SAMBA.
Im Gegensatz zu SAMBA arbeitet der (trotz Unix Dateisystem) mit Windows SID statt Unix UID User Kennungen und Windows ntfs artiger ACLs. Da er multithreaded arbeitet ist er häufig etwas schneller als der optionale SAMBA. Shares sind hier eine strikte ZFS Eigenschaft.
Damit lassen sich ZFS Dateisysteme sichern/ wiederherstellen ohne dass z.B. Windows AD Rechte verloren gehen oder man erst etwas konfigurieren muss. Auch gehen ZFS Snaps als Windows Vorherige Version damit sofort und absolut problemlos.
- Das Besondere an Windows ACL z.B. im Vergleich zu klassischen Unix Permissions sind Vererbungen der Rechte. Diese sind bei Solarish im Dateisystem verankert und müssen nicht konfiguriert werden. Es genügt als z.B. auf dem freigegebenen Dateisystem root=full und familie=readx_set mit Vererbung (inheritance) auf Dateien und Ordner zu setzen. Alle neuen Dateien erben diese Rechte (sofern die ZFS Eigenschaft aclinherit auf pass-through steht. Das ist bei napp-it aber default).
-Das rekusrsive Setzen der Rechte braucht man nur wenn tieferliegenden Dateien andere Rechte zugewiesen wurden und man das beseitigen möchte.
- ACL auf Shares ermöglicht das zusätzliche globale Einschränken der Rechte ohne die Dateirechte ändern zu müssen. Wenn man Dateien mit Rechten sichern möchte eignet sich das nicht. Ich nehme das meist nur um kurzfristige den Zugriff einzuschränken.
- Es wird üblicherweise der Solarish eigene, in ZFS integrierte SMB Server benutzt und nicht der optionale SAMBA.
Im Gegensatz zu SAMBA arbeitet der (trotz Unix Dateisystem) mit Windows SID statt Unix UID User Kennungen und Windows ntfs artiger ACLs. Da er multithreaded arbeitet ist er häufig etwas schneller als der optionale SAMBA. Shares sind hier eine strikte ZFS Eigenschaft.
Damit lassen sich ZFS Dateisysteme sichern/ wiederherstellen ohne dass z.B. Windows AD Rechte verloren gehen oder man erst etwas konfigurieren muss. Auch gehen ZFS Snaps als Windows Vorherige Version damit sofort und absolut problemlos.
- Das Besondere an Windows ACL z.B. im Vergleich zu klassischen Unix Permissions sind Vererbungen der Rechte. Diese sind bei Solarish im Dateisystem verankert und müssen nicht konfiguriert werden. Es genügt als z.B. auf dem freigegebenen Dateisystem root=full und familie=readx_set mit Vererbung (inheritance) auf Dateien und Ordner zu setzen. Alle neuen Dateien erben diese Rechte (sofern die ZFS Eigenschaft aclinherit auf pass-through steht. Das ist bei napp-it aber default).
-Das rekusrsive Setzen der Rechte braucht man nur wenn tieferliegenden Dateien andere Rechte zugewiesen wurden und man das beseitigen möchte.
- ACL auf Shares ermöglicht das zusätzliche globale Einschränken der Rechte ohne die Dateirechte ändern zu müssen. Wenn man Dateien mit Rechten sichern möchte eignet sich das nicht. Ich nehme das meist nur um kurzfristige den Zugriff einzuschränken.
Einfach mit zpool replace pool alt neu
http://docs.oracle.com/cd/E19253-01/820-2313/gbcet/index.html
Wenn die ZFS Eigenschaft autoexpand aktiviert ist, steht die größere Kapazität
anschließend zur Verfügung - wenn nicht dann pool export + pool import machen.
http://docs.oracle.com/cd/E19253-01/820-2313/gbcet/index.html
Wenn die ZFS Eigenschaft autoexpand aktiviert ist, steht die größere Kapazität
anschließend zur Verfügung - wenn nicht dann pool export + pool import machen.
Zuletzt bearbeitet:
zpool get autoexpand pool
Eigenschaften von ZFS-Speicher-Pools - Oracle Solaris ZFS-Administrationshandbuch
Eigenschaften von ZFS-Speicher-Pools - Oracle Solaris ZFS-Administrationshandbuch
