Servus, ich musste auf Grund von Fehlern meine Disk4 entfernen (diese war von Unraid deaktiviert worden) und wurde nur noch emuliert ZFS mti LUKS encrypted, die Daten waren noch lesbar. Anschliesend die alte Platte wieder rein (weil ich eher von einem Defekten Stromkabel als einer def Platte ausgehe) Rebuild gestartet und immer noch Fehler auf zwei Laufwerken (Parity (SATA hard link resets wie auf Disk4 aber noch valid) und Disk4) Dann Vorgang wieder abgebrochen - hat zu lange gedauert - hard reset. Das ganze so drei mal bestimmt. Jetzt habe ich das Problem: Ich gebe wie gewohnt meine Passphrase ein (diese ist korrekt da die anderen Laufwerke im Array als auch in den Pools korrekt entschlüsselt werden) und Disk 4 behauptet das die Passphrase falsch ist und wird auch nicht gemounted. Weder die Emulierte Disk 4 noch die physischen. Jetzt die Spannende Frage, wie komme ich am meine Daten ?

luksOpen result: Error: Passphrase or Key File not found.

luksDump

root@Tower:~# cryptsetup luksDump /dev/md4p1

LUKS header information

Version: 2

Epoch: 3

Metadata area: 16384 [bytes]

Keyslots area: 16744448 [bytes]

UUID: 7ba8cfcb-d208-4577-8fdd-940b7e7cf894

Label: (no label)

Subsystem: (no subsystem)

Flags: (no flags)

Data segments:

0: crypt

offset: 16777216 [bytes]

length: (whole device)

cipher: aes-xts-plain64

sector: 512 [bytes]

Keyslots:

0: luks2

Key: 512 bits

Priority: normal

Cipher: aes-xts-plain64

Cipher key: 512 bits

PBKDF: argon2id

Time cost: 4

Memory: 994314

Threads: 4

Salt: dc 03 7a 2a 34 ef 64 e9 31 a9 e4 5b cc e9 75 3a

4f 5d fd c0 80 f6 af d0 c0 5a c1 2c e0 a9 6c 3f

AF stripes: 4000

AF hash: sha256

Area offset:32768 [bytes]

Area length:258048 [bytes]

Digest ID: 0

Tokens:

Digests:

0: pbkdf2

Hash: sha256

Iterations: 257003

Salt: 74 36 46 d5 5d d0 6a ec 8e 14 62 4d b6 54 ef 8c

7e d3 aa b5 7b 38 7e 02 d2 36 b1 a8 85 67 b0 7f

Digest: ae b7 52 68 b5 1d f1 f5 a0 80 3a 02 22 26 41 61

82 d9 20 d1 50 37 0c 8c 34 4b 63 ad 78 4a 6f 14

Unraid 7.3.0

Edited July 24Jul 24 by Gee1

1 hour ago, Gee1 said:

Rebuild gestartet und immer noch Fehler auf zwei Laufwerken (Parity (SATA hard link resets wie auf Disk4 aber noch valid) und Disk4) Dann Vorgang wieder abgebrochen - hat zu lange gedauert - hard reset. Das ganze so drei mal bestimmt.

ich glaube nicht dass das eine gute Idee war, vor allem wenn auch die Parity Fehler auswirft, dann einen Abbruch zu erzwingen ...

Rebuild from Parity ist ja Block based, wenn da angefangen wird und dann abgebrochen wird, hmm.

gefühlt würde ich sagen die disk ist jetzt teilweise überschrieben, aber nicht sauber.

Versuch, die disk aus dem array entnehmen und per unassigned devices mounten und da versuchen zu retten was zu retten ist.

1 hour ago, Gee1 said:

Jetzt die Spannende Frage, wie komme ich am meine Daten ?

normal würde ich sagen aus deinem Backup wieder einspielen, anhand der Fragestellung befürchte ich jedoch ist keines vorhanden ...

ich bin jetzt weder zfs User noch LUKS, aber ich schätze das wird nicht einfach.

@JorgeB may an idea, zfs and luks encrypted disk errored out from array, user tried to rebuild anyway, again errored while rebuilding, hard resetted several times, any ideas what to try to may resolve the data again, i suggested to try in UAD and try to mount and encrypt there, but i personally guess ...

Please post the diagnostics, and ping me again after that, or I may miss the post since it's not in the English section.

@JorgeB

tower-diagnostics-20260725-0034.zip

wie oft der rebuild abgebrochen wird spielt keine Rolle, da die virtuelle Disk4 davon unangetastet bleibt. Beim ersten rebuild hat die besagt disk 4 immer die bekannten SATA Link resets und speed reduzierungen von 6 auf 1,5GBs in den Logs geworfen.. darauf hin habe ich abgebrochen und (weil ich das Problem schon mal hatte) die SATA Stromkabel und Datenkabel auf korrekten sitz Überprüft. Beim Zweiten versuch hat dann auch die Parity besagte Fehler geworfen. Darauf hin wieder abgebrochen bzw hat er den shutdown Befehl ignoriert also hard off. kabel getauscht und gedreht und geschaut ob der Fehler mitwandert etc... jeden Falls das Ende vom lied das sowol die Virtuelel Disk 4 als auch die Physische Disk 4 warscheinlich einen Defekten LUKS Header haben, anders kann ich mir nicht erklären warum er die Passphrase nicht mehr will. Allerding kann der Status vom LUKS header noch einwandfrei gelesen werden. Der LUKS Header an sich ist ja mit 16MB ganz schön gross.. ich habe die Heade aller anderen Platte direkt ge-backupt damit mir das nicht nochmal passieren kann.

Was halt seh komisch ist das die LUKS header von beiden der Physischen und virtuellen Disk 4 korrupt sein sollen. Denn Disk 4 ist schon seit über einer Woche auf Grund von Fehlern deaktiviert und nur die virtuelle Disk 4 in Betrieb und hat einwandfrei funktioniert.

legt UNRAID irgendwo LUKS Header kopien auf das Flash Drive ? Ich denke das ist meine einzige Chance wieder an dei Daten zu kommen

Edited July 25Jul 25 by Gee1

4 hours ago, Gee1 said:

Was halt seh komisch ist das die LUKS header von beiden der Physischen und virtuellen Disk 4 korrupt sein sollen. Denn Disk 4 ist schon seit über einer Woche auf Grund von Fehlern deaktiviert und nur die virtuelle Disk 4 in Betrieb und hat einwandfrei funktioniert

soweit klar, nur wenn du einen rebuild startest dann schreibt ja einiges neu, sei es drum.

Auszug syslog, disk4

hier war die noch da (mit Fehler falscher Key)

Jul 24 02:19:02 Tower kernel: mdcmd (6): import 4 sdk 64 3907018532 0 TOSHIBA_MD04ACA400_X6RCK5T4FSAA

Jul 24 02:19:02 Tower kernel: md: import disk4: (sdk) TOSHIBA_MD04ACA400_X6RCK5T4FSAA size: 3907018532
...
Jul 24 02:21:33 Tower emhttpd: shcmd (280): /usr/sbin/cryptsetup luksOpen /dev/md4p1 md4p1

Jul 24 02:21:35 Tower emhttpd: disk4: Wrong encryption key

hier nicht mehr ... sprich, da passt schon etwas nicht (als wäre die disk abgezogen, empty ...)

Jul 24 22:59:26 Tower kernel: mdcmd (6): import 4

Jul 24 22:59:26 Tower kernel: md: import_slot: 4 empty

...

mal egal wie das hier aus geht, in Zukunft sicher die Daten in so einem Fall zumindest lokal weg solange du im emulierten Zustand bist, wenn eine disk emuliert wird, von der disk die Daten weg auf ne andere disk im array (oder unassigneed, oder am Besten extern, oder ...)

BEVOR man anfängt hier versucht zu reparieren ! (hier alles von disk4 auf eine funktionierende disk3 in einem vorhandenen Backup Verzeichnis)

dann wären die Daten zumindest erhalten geblieben als Kopie, sollte nicht genug Platz sein, halt verteilen, danach dann die Reparatur starten.

cp -a /mnt/disk4/* /mnt/disk3/Backup/

Key being wrong suggests some LUKS header corruption, assuming for sure it's the same one.

I'm also seeing a zfs pool detecting data corruption:

Jul 24 23:01:46 Tower emhttpd: errors: 4 data errors, use '-v' for a list

That may or may not be related; data corruption is typically a RAM issue, but you appear to be using EEC RAM, but whatever caused that could also have corrupted the LUKS header.

You can try manually decrypting the rebuilt disk just to confirm the key, but I would expect the same result, this would need to be done with the arry stopped.

cryptsetup luksOpen /dev/sdX sdX

For the future, make sure you have LUKS backups, and I only recommend using encryption if absolutely necessary; if not, it just adds one more layer that can go wrong when a problem occurs.

"cryptsetup luksOpen /dev/sdX sdX" already tryed this and many more

"hier nicht mehr ... sprich, da passt schon etwas nicht (als wäre die disk abgezogen, empty ...)"

warscheinlich hatte ich disk4 zu dem Zeitpunkt schon in meinem anderen Rechner. Disk 4 hat übrigens hunderte Reallocated sectors. Sicher wurde der header zerschossen

Edited July 25Jul 25 by Gee1