[Sammelthread] ZFS Stammtisch

[martingo]

Ich habe noch immer nicht so ganz verstanden, was genau Dein Problem ist. Abgesehen von dem roten X. Kannst Du das nochmal in wenigen Sätzen schildern?

Was sagt "idmap list"? Da sollte vorerst nur das eine Mapping vom DomainAdmin auf root drin sein. Ein Mapping der normalen User ist auf keinen Fall notwendig, eher kontraproduktiv.

Versuchst Du die Berechtigungsvergabe über nappit oder über Windows?

 

[Happy Hepo]

Ausgangssituation: Ich habe einen Share, auf dem für verschiedene User Ordner liegen, die Berechtigungen der Ordner möchte ich anpassen.

Angemeldet als Domain-Administrator per Windows mit Rechtsklick > Eigenschaften > Sicherheit den User berechtigen.
Fehlermeldung: "No Mapping between account names and security IDs was done". Nur der Ordner wird ACL-technisch angefasst, alle Unterordner und Dateien dadrin nicht.

Ich kann Mapping-technisch einstellen was ich will, solange das Mapping aus meiner Sicht korrekt ist (Bsp. unten oder alternativ als 1:1-Mapping, nicht als gerichtetes Mapping, mit dem jeweiligen Domain-User auf root gemappt), bekomme ich den Fehler.

Wenn das Mapping fehlt oder der User keine Berechtigungen dafür hat, bspw. ein normaler User, bekomme ich den Fehler "Failed to enumerate objects. Access denied".

Wenn ich den Share per root mounte, funktioniert die Berechtigungsvergabe, solange ich kein 1:1 Mapping von einem Domain-User auf root habe.
Edit: auf einem Teil der Ordner funktioniert es per root jetzt, auf einem anderen aber Teil nicht. Das ist auch der Fall nachdem ich ein ACL-Reset rekursiv gemacht habe.

idmap:
winuser:Administrator@domain.fqdn => unixuser:root

Alle Berechtigungsvergaben passieren per Windows.

 

[gea]

Ganz nachvollziehen kann ich das Problem nicht.

Ich habe hier ein gutes Dutzend OmniOS Filer unterschiedlicher Versionen und eine AD die kürzlich auf 2019 upgedated wurde. ID mapping habe ich hier nur name => root für die Admins (nur Name ohne Domäne).

 

[CommanderBond]

EDIT: Sorry, Du schreibst ja, iPadOS, ich kam gerade von gea's illumos-Link oben, da geht es ja um Timemachine... Also welche iPad-App nutzt Du, um auf einen OmniOS-Filer per smb zuzugreifen? Mit der Dateien-App von Apple klappt das nicht, aber mit der App "File Explorer" klappte das bisher zumindest, wenn man in den Einstellungen dort "SMBv2" ausgeschaltet hat.

Ja meine die Dateien-App von Apple. Mit File Explorer klappt es auch bei mir, doch es würde ja Sinn machen jetzt direkt die "native" SMB Implementierung in iPadOS zu nutzen die es Seit Version 13 gibt. Ist halt doof wenn es bei dem Kollegen der Synology nutzt klappt, mit OmniOS aber nicht

P.S.: Mit dem neuesten OmniOS klappt es mit der File Explorer App offenbar auch mit aktiviertem SMBv2, man muss die Einstellung also nicht mehr deaktivieren.

 

[gea]

Synology=Linux+SAMBA.

Man könnte jetzt auch SAMBA auf OmniOS installieren. Vermutlich würde dann dieses Problem gelöst sein. Man würde dagegen die Vorteile verlieren wegen denen viele gerade den kernelbasierten, multithreaded SMB Server unter Solarish wollen (Performance, Zero-Config/tut einfach, ntfs ACL, SMB Gruppen, Unterstützung von Windows SID, Snaps als vorherige Version, AD Unterstützung ohne Probleme - um ein paar zu nennen).

Es tut sich aber bei Illumos gerade sehr viel, auch was Apple angeht. Eventuell hilft es ja, das Problem in der Illumos-dev oder -discuss Mailliste zu platzieren. Gordon Ross (der die neuesten SMB Entwicklungen in Illumos imtergriert hat) antworted eventuell oder berücksichtigt das zumindest.

 

[CommanderBond]

Ja da hast du recht. Ich denke mal bin nicht der Einzige der das nutzen will jetzt wo SMB in iOS/iPadOS integriert ist.
Dachte eigentlich aber immer SMB ist gleich SMB, das Protokoll ist doch identisch wieso kommt es denn dann dennoch zu Imkompatibilitäten.

 

[gea]

Dachte eigentlich aber immer SMB ist gleich SMB,.

SMB ist das Netzwerkprotokoll von Microsoft.
Klar das Apple da Erweiterungen braucht, um sich davon positiv abzusetzen.

 

[CommanderBond]

Habe bei mir folgende Probleme entdeckt:
wenn ich eine Datei lese von ssdtemp2 und das Filesystem ssdtemp3 in den Status "locked" versetzen will unterbricht dies den Filetransfer und er bricht mit einer Fehlermeldung ab.

Habe ich einen aktiven Filetransfer zwischen meinem PC und ssdtemp2 und will ssdtemp3 in "unlocked" versetzen so scheitert dies ebenfalls, der Filetranfer läuft direkt bis 100% und beendet sich dann, die Datei wurde aber ebenfalls nicht erfolgreich übertragen.

please wait... Enter passphrase for 'ssdpool/ssdtemp3':

12345678 cannot mount 'ssdpool/ssdtemp3': encryption key not loaded svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances. commands will be executed using /bin/sh job 1573319337.a at Sat Nov 9 18:08:57 2019 svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances. commands will be executed using /bin/sh job 1573319347.a at Sat Nov 9 18:09:07 2019

Sprich unlocked klappt bei mir nur wenn grad keine Dateiübertragungen laufen auf dem Server. Und locked funktioniert unterbricht aber aktuelle Datentransfer zwischen Clients mit anderen Filesystemen.
Getestet mit SMB.

ssdtemp2 und ssdtemp3 befinden sich jeweils beide auf dem pool ssdpool

Kann es sein dass die Netzwerkverbindung dabei jeweils immer kurzzeitig unterbrochen wird?
Habe es grad nochmal mit einem Videostream von einem anderen Pool ausprobiert. Hier wird er in beiden Fällen unterbrochen sowohl bei lock und unlock

 

[Ceiber3]

Schon gesehen, Qnap haut jetzt bald QTS Hero raus. Dann haben viele Qnap ZFS, wenn das so stimmt wer das ganz nice.
Weiß aber noch nicht genau was da dran ist.

QTS hero Edition: Ein ZFS-basiertes NAS-Betriebssystem—QTS hero—bietet Daten-Inline-Deduplizierung und Komprimierung, End-to-End Datenintegrität und leistungsstarke Speicherverwaltungslösungen und erweitert das Anwendungsfeld anderer NAS der gleichen Klasse. Durch die Integration der Boxafe und HBS 3 Sicherungslösung wird die Verbindung des lokalen NAS mit dem Cloud-Backup beschleunigt. Das NAS unterstützt Fibre Channel, das Ihre alten Netzwerkumgebungen schnell in eine digitale Transformation verwandeln kann.

 

[martingo]

Mit locked/unlocked meinst Du, das Filesystem zu entschlüsseln?
Ich habe da noch nichts festgestellt, aber auch nicht explizit getestet.

Ist das denn wirklich relevant für Dich (im Sinne von ständig Key loaden/unloaden)?

Wenn das wirklich so ist, würde ich sagen, das sei ein Bug. Allerdings ohne jegliche Konsequenz für mich. Wenn die Kiste startet, lade ich den Key und dann bleibt das Filesystem offen bis zum Neustart.

 

[CommanderBond]

Mit locked/unlocked meinst Du, das Filesystem zu entschlüsseln?

Ja.
Naja ich teste grad noch. Obs später relevant ist weiß ich noch nicht, unschön auf jeden Fall eventuell denkt man irgendwann nicht dran und woanders läuft dann grad ein Backup was deswegen abbricht oder vielleicht speichert man Ip Cam Streams drauf und will dann das Filesystem mit Dokumenten Abends in den locked Status versetzen.

 

[gea]

Bei Solaris war es bisher so, dass ein lock/unlock SMB shares nicht beendet oder wiederhergestellt hat. Ich mache daher ein smb service refresh. Bisher ging ich davon aus, dass es zwar eine kurze Unterbrechung gibt, der Filetransfer dann aber fortgesetzt wird, insbesondere bei Illumos da das jetzt persistente SMB Handles kann. Eine Streaming Anwendung könnte das aber eventuell dennoch übelnehmen.

Ich muss mir das mal näher ansehen und eventuell manuell ein individuelles share on/off je Dateisystem anstoßen.

- - - Updated - - -

Schon gesehen, Qnap haut jetzt bald QTS Hero raus. Dann haben viele Qnap ZFS, wenn das so stimmt wer das ganz nice.
Weiß aber noch nicht genau was da dran ist.

Qnap hatte ja bereits ZFS Filer im Angebot (sehr teuer). Die basierten auf Free-BSD. Qnap hält sich mit Hero noch bedeckt, spricht nur von einem ZFS OS. Nach dem was ich gelesen habe, scheint es sich bei Hero um Linux + ZoL + SAMBA zu handeln. Im wesentlichen also die bisherige Qnap Software mit ZFS statt ext4 + LVM.

 

[Ceiber3]

Im wesentlichen also die bisherige Qnap Software mit ZFS statt ext4 + LVM.

Genau das verstehe ich auch so, mal sehen wie sie es umsetzen, der Vorteil zu QES soll ja sein das alle fertig Programmierten Apps erhalten bleiben und die Frage ist auch welche Qnap's es bekommen, es bekommen wohl auch ältere, die Frage ist halt wie alt. Aufjedenfall schon mal besser als EXT4. Mal abwarten, soll ja 2020 kommen, wenn es so ist wie beschrieben, ist es ein gegengewicht zu Synology mit BTRFS. Wird auch mal Zeit von EXT4 wegzukommen.

 

[gea]

Synology nutzt btrfs + LVM um deren bisherige Spezial-Raids abzubilden. Mit ZFS ginge das nicht. Dafür muss man halt einige Kröten schlucken. Klar ist ZFS ein Riesen-Fortschritt, ja ein Quantensprung zu ext4.

Man braucht halt deutlich mehr CPU Leistung und RAM um mit der besseren Sicherheit gleiche Performance zu haben. Da mehr RAM auch mehr Ram.Fehler bedeutet, sollte man zudem ECC RAM einsetzen. Das verbietet ZFS für ein kleines NAS dessen CPU und RAM gerade einfaches Smartphone Niveau hat.

 

[Ceiber3]

Das verbietet ZFS für ein kleines NAS dessen CPU und RAM gerade einfaches Smartphone Niveau hat.

Genau, für diese sei es wohl auch nicht geplant, nur die stärkeren Nas mit Intel und AMD CPU's. Ja jetzt fehlt noch ECC, dann wer es Perfekt mit ZFS, aber lieber ZFS ohne ECC als garkein modernes File System, meiner Meinung nach hätten sie damit schon eher anfangen können.

QNAP QTS Hero for ZFS on your NAS - NAS Compares

Meins ist aufjedenfall unten mit in der Liste, das von mein Kumpel auch, mal schauen ob noch mehr dazu kommen.

 

[martingo]

@CB: ach so, das war über die GUI. In Verbindung mit dem, was Günther sagt, wird es dann verständlich, wenngleich unerwartet. Hätte refresh auch eher wie einen graceful restart verstanden.

 

[CommanderBond]

Bei Solaris war es bisher so, dass ein lock/unlock SMB shares nicht beendet oder wiederhergestellt hat. Ich mache daher ein smb service refresh. Bisher ging ich davon aus, dass es zwar eine kurze Unterbrechung gibt, der Filetransfer dann aber fortgesetzt wird, insbesondere bei Illumos da das jetzt persistente SMB Handles kann. Eine Streaming Anwendung könnte das aber eventuell dennoch übelnehmen.

Ich muss mir das mal näher ansehen und eventuell manuell ein individuelles share on/off je Dateisystem anstoßen.

Bei lock einfach share=off und dann lock
Und bei unlock erst unlock und dann share=on wäre doch naheliegend.

wobei man aber berücksichtigen müsste dass wenn man lock macht das Dateisystem aber schon share=off (weil es der Admin so gesetzt hat) war unlock es nicht automatisch auf share=on stellt.

Vielleicht nennt man es dann "auto-on" und "off" und auto-on richtet sich nach lock/unlock.

 

[gea]

Damit ist das Problem schön erläutert.

Das Ziel sollte sein, dass bei einem Windows Client der Verbindung zum Server hat, ein locked Dateisystem nicht mehr als Share angezeigt wird. Setzt man smbshare=off vor dem lock auf off wird es beim nächsten unlock nicht mehr freigegeben. Jedes Share beim unlock aktivieren ist auch falsch. Bliebe nur eine Speicherung über aktivierte Shares außerhalb von ZFS Eigenschaften. Das ist auch nicht wünschenswert.

Ideal wäre, wenn ein Lock selber das Sharing beenden würde ohne die ZFS Eigenschaft zu ändern. Zumindest Solaris macht das nicht. Bei Illumos habe ich das noch nicht getestet. Ich vermute stark, dass es sich verhält wie Solaris.

Ein smb service refresh macht das gewünschte, unterbricht halt den Dienst kurz. Für die meisten ist das ok. Evenuell wäre das ein Fall für ein feature request bei Illumos.

 

[CommanderBond]

Könnte man wenn smbshare=on ist nach einem lock/unlock nicht einfach jedesmal smbshare off und dann wieder on schalten statt smb service refresh? Durch 2maliges hin und herschalten hätte man ja nichts verändert am ursprünglichen Zustand.

Alternativ macht man das Verhalten konfigurierbar sprich smb service refresh als Standard und smbshare=off vor einem lock und smbshare=on nach einem unlock als alternative dazu.

 

[martingo]

Innerhalb des Encrypted Filesystems kann es aber auch mehrere hundert Kind-Filesystems geben. Für all diese müsste man das dann auch machen.

 

[gea]

Ich vermute mal, dass ein smb refresh das beste Default-Verhalten ist (solange ein lock das nicht selbst handhabt). Dazu eine Option, um im Lockmenu das Refresh abzuschalten. So werde ich das mal in die nächste dev Version übernehmen.

 

[Count_Zero]

Ich wollte mich an das OmniOS/Mac/SMB Thema dranhängen...
Ich teste gerade OmniOS r151032 mit napp-it 19.10 homeuse. Dabei fällt mir auf, das der SMB Durchsatz bei einem NVMe Basic Pool sehr unterschiedlich ist - bei einem aktuellen Windows 10 Client erreiche ich ca. 800 MB/s, bei einem Mac Pro mit Mojave nur 270 MB/s - in einem 10 GB Netz. Der Mac Client kann aber fast den 10 GB Link sättigen, wenn direkt auf den Windows Client kopiert wird. Somit fehlen bei der SMB Implementation von OmniOS noch Features, wodurch der Mac ausgebremst wird.
Ich suche aber ein perfomantes Storage OS für eine heterogenes Mac/Windows Netzwerk. Da ich ZFS will werde ich auch Freenas und Xigmanas in den aktuellen Versionen testen. Für Tipps bin ich dankbar.

 

[gea]

Bei Illumos wird gerade massiv am kernelbasierten SMB Server gearbeitet. Wenn es Vergleichswerte mit SAMBA gibt und der kernelbasierte deutlich schlechter ist, wäre eine Mail an illumos-dev mit den Details eventuell hilfreich.

Ansonst sind noch nicht alle SMB Features von Windows 10 (SMB 3.1) umgesetzt. Solaris ist zwar auf SMB 3.1, Illumos dagegen auf 3.02. Apple packt da gern noch einige Spezialitäten drauf.

Dass ich mit einem aktuellen OSX nicht die Performance wie Windows habe, habe ich aber auch schon bemerkt. Bis OSX 10.11 konnte ich 10G problemos mit SMB 2.1 gegen OmniOS auslasten. Nötig waren lediglich aktuelle Treiber für die Thunderbolt>10G Karte und Jumboframes. Aktuell ist es viel langsamer (trotz Deaktivieren von signing), https://dpron.com/os-x-10-11-5-slow-smb/

 

[martingo]

Falls sich die Machine id geändert hat:
Den Key online tauschen auf napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Extensions

alter Key z.B.
complete 1566122830_h:m0c291f3ddm90 - 18.6.2021::mVqnVqsmVOTTVuqmlqsmsViThhVD

In der ersten 19.06 konnte es passieren, dass der Key fälschlicherweise deaktiviert wurde (Machine ID hat sich nicht geändert).
Dann den alten Key (findet sich in Extension > Register > oldkey) erneut registrieren und auf aktuelle 19.06f updaten.

Hi,
mir ist das heute auch aufgefallen. Die MachineID hat sich ohne erkennbaren Grund geändert. Re-Registrierung ist natürlich kein Problem. Installiert ist laut GUI aktuell diese Version (war auch von Anfang an diese Version): 19.Dev 18.oct.2019

 

[gea]

Im aktuellen napp-it wird die ID aus der ersten Netzwerkkarte generiert. Solange diese Netzwerkkarte im Rechner bleibt, geht der Key auch nach Neuinstallation. "Alte" Keys bleiben auch gültig. Warum die ID sich nach vielen Tagen plötzlich ändert ist mir noch nicht ganz klar. In der aktuellen dev vom November habe ich eine Änderung, die das Problem aber beheben sollte.

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris Changelog

 

[27k1]

Meine Meinung: macOS => aktuelles Samba. Stichwort z.B. vfs_fruit.
Illumos & Co solltest du derzeit als Macuser eher nicht nutzen.
Im kommenden FreeNAS 11.3 und OMV5 sind AFAIK die Apple-Besonderheiten OOTB auch berücksichtigt.

 

[lutzlustig]

Folgendes Szenario:
(Home)Server mit 1x raidz (3x6TB) und 1x raidz2 (4x2TB). System (Ubuntu 18.04) auf einer SSD, alles läuft stabil und fehlerfrei.
Ich kann 4x optane mit je 16GB für 30 euro bekommen und habe noch so eine Hyper M2 x16 Card von Asus, wo alle 4 Optanes drauf passen würden.

Lohnt das, kann ich damit irgendwas schneller oder zuverlässiger machen? Ist ja nur wegen meinem Spieltrieb.

 

[Luckysh0t]

Kann denn dass Board vom zielserver pcie bifurcation ?

 

[lutzlustig]

Kann denn dass Board vom zielserver pcie bifurcation ?

Ja, Supermicro X9DR3-F

 

[gea]

Für OmniOS 151032 stable gibt es ein Update das eine Reihe von seltenen aber kritischen Open-ZFS Fehler behebt omnios-build/ReleaseNotes.md at r151032 · omniosorg/omnios-build · GitHub

Installation per "pkg update"
Neustart ist nötig