Manuelle Einbindung verschlüsselter ZFS-Freigaben

Guten Abend,

kennt sich hier jemand mit den Details der ZFS-Verschlüsselung in QuTS hero aus?

Das NAS ist ein TS-873A, mit 2x1 TB SATA SSD als "Systemplatten" und mit 4x18 TB HDDs als "Datenplatten".

Der Storagepool 2 ist über die 4 HDDs verteilt und enthält fünf Freigabeordner (datasets).

Vier der fünf datasets sind verschlüsselt, eines nicht.

Ich habe am Sonntagabend die Firmware von h5.0.1.2376 auf h5.1.0.2466 (build 20230721) geupdatet.

Nach dem Neustart ist es so, dass er bei Storagepool 2 versucht ein Bereinigung (scrubbing) zu starten.

Diese wird in der Weboberfläche aber dauerhaft mit 0,0 % angezeigt.

Per ssh-Konsole und zpool status erfährt man dann:

    scan: scrub in progress since Thu Jan  1 01:00:00 1970

0 scanned at 0/s, 0 issued at 0/s, 7.30T total
0 repaired, 0.00% done, no estimated completion time

Mittels dmesg und ps kommt dann heraus, dass sich scheinbar dsl_scan_prefet "aufhängt" bzw. dauerhaft in den Status "Uninterruptible sleep (usually IO)" übergeht.

Befehle wie

zpool scrub -p zpool2

oder

zpool scrub -s zpool2

kommen daher nicht mehr im Kernel an bzw. können von diesem nicht mehr verarbeitet werden.

Das Scrubbing lässt sich also auch nicht stoppen oder abbrechen.

Soweit so unschön. Auf die unverschlüsselte Freigabe hat man Zugriff und kann die Daten lesen.

Wenn man etwas schreiben will, funktioniert das bei kleinen Dateien bis ca. 50 MB.

Bei größeren hängt sich dann der Kernel vermutlich auf, dann ist die Freigabe nicht mehr zu erreichen.

Vor dem Firmwareupdate war es egal ob die Freigaben entschlüsselt sind oder nicht.

Momentan weiß ich nicht ob es eine Rolle spielt.

Über die Weboberfläche klappt das Entschlüsseln nicht.

Man sieht ca. 10 Minuten den Wartekreisel und dann heißt es "Ausführung fehlgeschlagen".

Ich habe es dann per SSH entsprechend dieser Anleitung probiert:

Von QNAP bereitgestellte Anleitung zum manuellen Einbinden von ZFS-Freigaben in QuTS hero per SSH-Konsole

Bei Punkt 3 muss es vermutlich so aussehen, also dass man nach dem Echo-Befehl sein Passwort einträgt, das dann per md5sum gehashed wird und in die Datei geschrieben wird.

echo -n <Passwort> | md5sum | awk '{print $1}' > /tmp/temp.Y1WjNV

Der nachfolgende Validate-Befehl gibt aber statt verification succeeded nur "key is not validated!" zurück.

/sbin/zfs validate zpool2/zfs18 /tmp/temp.Y1WjNV

Es ist eigentlich egal, was man in die Datei einträgt, man bekommt immer diese Rückmeldung.

Nun weiß ich nicht, ob es an dem Kernelzustand liegt oder ob irgendetwas mit Passworthash nicht stimmt.

Außer md5sum habe ich noch sha1sum, sha256sum und das direkte eintragen des Klartextpassworts in die temp.Y1WjNV Datei ausprobiert.

Immer kam die Rückmeldung "key is not validated!"

Supportanfrage bei QNAP ist gestellt, aber die haben sich bislang nicht geäußert, also wollte ich mal fragen, ob hier schon mal jemand nach der QNAP-Anleitung eine ZFS-Freigabe entschlüsselt hat und dazu etwas sagen kann.

Hat es geklappt oder ist die Anleitung fehlerhaft?

Muss man einen anderen Hash verwenden?

Falls man das falsche Passwort (bei ansonsten richtiger Vorgehensweise) vorgibt, welche Fehlermeldung bekommt man dann?

Wenn ich die Firmware wieder auf die alte Version zurücksetze, wird der Speicherpool nicht mehr erkannt.

Der Weg zurück scheint also versperrt.

Hallo Rune,

na ja, es war nicht einfach mit dem Support, aber ich bin optimistisch, dass man das System wieder zum Laufen bringen kann.

Vielleicht ein paar Hintergrunddetails zu meinem Pool. Es war ein Raid 10 aber kein RaidZ1 oder RaidZ2.

Wir haben das NAS heruntergefahren (nur auf die harte Tour möglich, da der Kernel die Prozesse nicht herunterfahren kann) und ich habe einfach eine der vier HDDs eingesetzt.

Nach dem Neustart befand sich das RAID natürlich im Status "fehlgeschlagen", aber deshalb versuchte es nicht, den Scrubbing-Prozess zu starten. Das erste Ziel ist also, diese 1.1.1970-Situation zu vermeiden. Ich weiß nicht, ob es möglich ist, wenn man z.B. ein RAIDZ1 oder RAIDZ2 hat und auch nur eine beliebige Platte einlegen will. Aber ich würde erwarten, dass es funktioniert.

Als nächstes fügten wir die drei verbleibenden HDDs "hot-plugged" hinzu.

Dann haben die QNAP-Leute das RAID wieder manuell aufgebaut.

Leider habe ich die Befehle nur sehr bruchstückhaft aufgeschrieben.

Das sind also vielleicht 33% von dem, was sie gemacht haben.

sysctl -w vfs.zfs.no_scan_IO=1

cp /etc/config/qzfs.conf

/mnt/HDA_ROOT.qzfs

storage_util --volume_scan do_scan_raid=0, force=1

Dann wurde das Scrubbing gestartet und es funktionierte normal und alles war in Ordnung.

Alle Daten waren verfügbar und das System funktionierte einwandfrei.

Der Qnap-Support ist so aufgebaut, dass ich zunächst mit einer Frau in Deutschland Kontakt hatte. Sie war hilfsbereit, aber technisch hatte sie keine Ahnung. Das Verfahren, das ich oben grob beschrieben habe, wurde von zwei Experten in Indien über Teamviewer durchgeführt. Man konnte mit ihnen nicht per Audio sprechen, sondern nur per Chat. Aber die Frau aus Deutschland hat die Teamviewer-Sitzung aufgezeichnet (fast 2 Stunden).

Mein Support-Ticket hatte die Nummer Q-202308-41287. Wenn meine grobe Beschreibung also nicht ausreicht, können Sie sich vielleicht an den QNAP-Support wenden und sich auf meinen Fall beziehen. Lassen Sie sich nicht von Diskussionen über Firmware-Versionen der HDDs oder SDDs abschrecken. Die Jungs in Indien kennen den Workaround und wissen wahrscheinlich auch, welcher Fehler in der QuTS hero-Firmware steckt, da es sich offensichtlich nicht um einen Einzelfall handelt.

Es tut mir leid, dass ich es nicht genauer beschreiben kann, aber ich hatte zu diesem Zeitpunkt bereits entschieden, dass ich das QNAP NAS in den Ruhestand schicken würde. Ich wollte also nur an die Daten kommen.

Mit freundlichen Grüßen,

Dominik

Übersetzt mit http://www.DeepL.com/Translator (kostenlose Version)