Luks Encrypt externe HDD, luksOpen schlägt fehl

[SFFox]

[SOLVED] - Es war das externe Gehäuse, nicht 8TB tauglich

Heyho,

ich betreibe schon länger einen Mini Homeserver auf Ubuntu Server Basis mit NAS Funktionalität auf einem Raid1 Array, einer Backup Platte im selbigen Server und einer zusätzlichen externen Backup Platte, die alle paar Monate mal auf aktuellen Stand gebracht wird per rsync.

Die externe Platte ist nicht an meinem Wohnort gelagert und da sich jemand Zugriff verschaffen könnte fand ich es sinnvoll diese per Luks zu encrypten. Es handelte sich bisher um eine 3TB Toshiba HDD in einem externen Intenso USB 3.0 Gehäuse (im Originalzustand stammt die Platte sogar aus diesem Gehäuse).

Der Datenbestand ist gewachsen mit den Jahren und mit den neuen internen HDDs meiner Servers sollte jetzt auch extern eine 8TB Platte her.
Ich habe die 8TB Platte ins USB-Gehäuse gepflanzt und alles so eingerichtet, wie ich es mit der 3TB Platte auch gemacht habe:

• luks encrypt das komplette drive (also /dev/sde/ in dem Fall) mit passphrase
• luks drive geöffnet und gemapped
• File System erzeugt: "mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/myusb"
• gemounted, permissions gesetzt
• per rsync alles drauf gesynced (~4,1TB an Daten)
• unmounted
• unmapped (luksClose)

Soweit so gut. Sobald ich das Drive aber wieder öffnen will per LuksOpen sagt cryptsetup mir das Drive wäre kein gültiges Luks Format und könne nicht geöffnet werden. Ich hab' das jetzt 2 mal probiert. Die offizielle FAQ empfiehlt ebenfalls bei einem externen Drive das komplette Drive zu crypten und so hat es ja auch problemlos mit der 3TB Platte funktioniert.

Technische Infos:

• VL701 USB3 zu SATA Controller im Intenso Gehäuse
  • Unterstützt kein UASP, sondern nur "normales" USB Storage
  • Controller vllt. zu "alt" für 8TB? Also klar ist das eigentlich nur eine Protokoll-Übersetzung und sollte bzgl. Kapazität keinen Unterschied machen aber who knows, wer vllt. damals die Firmware verhunzt hat 🤷‍♂️
  • Controller hat vllt. Probleme mit SMR?
• Seagate Barracuda Compute 8TB (ein SMR Drive, nicht die beste Platte aber für ein Backup sollte es ja wohl reichen)
  • hat kompletten SMART Selbsttest bestanden, der mehrere Stunden läuft und gilt als Gesund
• Alternativ eine Icy Box SATA Docking Station vorhanden, darin läuft gerade Versuch Nr. 3
• eine Spare Barracuda 8TB ist vorhanden... wenn der Icy Box Test nicht klappt versuche ich mal die andere Platte

Jetzt die Frage an euch: Übersehe ich was?

 

[JumpingCat]

Das sieht vom vorgehen alles korrekt aus.

Welche Meldung steht in dmesg / journalctl bei luksOpen?

 

[SFFox]

Dazu finde ich keinen spezifischen Eintrag. Es tritt ja auch kein echter Fehler auf, der geloggt werden müsste. Die Rückmeldung von cryptsetup ist einfach "not a valid luks device".

 

[Simpson474]

Was sagt denn ein "sudo fdisk -l /dev/sdX" bezüglich "Sector size (logical/physical)". Die alten USB Controller für große Festplatten waren darauf ausgelegt, mit Windows XP kompatibel zu sein. Windows XP (32-Bit) kann kein GPT und daher waren Festplatten auf 2 TB beschränkt. Um 3 TB Festplatten verkaufen zu können, haben die Controller eigentlich 4 KB Sektoren emuliert, falls die Festplatte größer 2 TB ist: das sollte man mit der Toshiba Festplatte im externen Gehäuse so auch in der Ausgabe sehen.

Möglicherweise erkennt der alte Controller die 8 TB aber nicht korrekt und aktiviert die 4 KB Emulation nicht - in diesem Fall müsste das Gehäuse mehr als 32-Bit bei der Adressierung unterstützen, ansonsten gibt es nach 2 TB einen Überlauf, der den LUKS Header (und vieles mehr) zerstört.

 

[JumpingCat]

Was passiert wenn du /dev/sde direkt mountest?

Was ist die Ausgabe von folgendem?
head -n10 /dev/sde | strings

 

[foofoobar]

Zeig man den output von:

cat /dev/foo |  od -A x -t x1z -v | head -n32

 

[SFFox]

Was sagt denn ein "sudo fdisk -l /dev/sdX" bezüglich "Sector size (logical/physical)". Die alten USB Controller für große Festplatten waren darauf ausgelegt, mit Windows XP kompatibel zu sein. Windows XP (32-Bit) kann kein GPT und daher waren Festplatten auf 2 TB beschränkt. Um 3 TB Festplatten verkaufen zu können, haben die Controller eigentlich 4 KB Sektoren emuliert, falls die Festplatte größer 2 TB ist: das sollte man mit der Toshiba Festplatte im externen Gehäuse so auch in der Ausgabe sehen.

Da ist ne ganz normale Toshiba DT01ACA300 drin gewesen. Alle Partitionen sind aber schon mit einem dd /dev/zero überschrieben. Falls "sudo fdisk -l /dev/sdX" dennoch sinnvoll ist werde ich das nachher gerne antesten.

Möglicherweise erkennt der alte Controller die 8 TB aber nicht korrekt und aktiviert die 4 KB Emulation nicht - in diesem Fall müsste das Gehäuse mehr als 32-Bit bei der Adressierung unterstützen, ansonsten gibt es nach 2 TB einen Überlauf, der den LUKS Header (und vieles mehr) zerstört.

Das scheint in der Hinsicht wahrscheinlich, da es zu den mount Problemen bisher immer erst gekommen ist, nachdem der rsync abgeschlossen und die Platte einmal getrennt war (4,1TB Füllstand).
Mit einem Testwrite einer kleinen txt konnte ich den Fehler jedenfalls nicht provozieren und jetzt in der modernen Docking Station mit UASP Unterstützung klappte es nach einem ~100GB Teiltransfer auch schon.

Das war jedenfalls eine plausible Schwarmwissen-Erklärung, die ich mir hier erhofft habe, besten dank dafür 🙏

Was passiert wenn du /dev/sde direkt mountest?

Werde ich testen, sobald der nächste rsync durch ist und der Fehler in der neuen Docking Station auch auftaucht.

Was ist die Ausgabe von folgendem?
head -n10 /dev/sde | strings

Werde ich ebenfalls nachliefern. Einen Test für eine head extraction mit "cryptsetup repair" auf einem exportierten head hatte ich versucht, die ist fehl geschlagen und hat's auch nicht mountbar gemacht. Hatte in einem Forum eine Anleitung dazu gefunden.

Zeig man den output von:

cat /dev/foo |  od -A x -t x1z -v | head -n32

Werde ich ebenfalls nachreichen, falls es mit der aktuelleren Docking Station fehl schlägt.

Besten Dank bis hier hin schon mal für euren Input. 250GB rsynced, ~3900GB more to go. Ergebnisse gibt's also erst morgen.

Ergänzung (1. Juni 2024)

@Simpson474
Da bin ich hier bei CB doch auch direkt fündig geworden:
https://www.computerbase.de/forum/threads/festplatten-dockstation.1298917/page-2#post-15078560

1. Intenso Memory Box, 3 TB, USB 3.0, 3.5 Zoll (intern: Toshiba DT01ACA300, 7200 UpM, 512 Byte pro Sektor, Chipsatz: VIA VL701): extern 4096 Byte pro Sektor

Großer Fehlerquellenkandidat 👍 Wurde mit max 4TB im Bundle verkauft.


Mit der spare-8TB oder der 3TB im alten Intenso Gehäuse kommt mit "fsutil fsinfo sectorInfo" unter Windows folgendes raus:

Logische Bytes pro Sektor:                                4096
Physische Bytes pro Sektor für Unteilbarkeit:             4096
Physische Bytes pro Sektor für Leistung:                  4096
Effekt. phys. Bytes/Sektor für Unteilbark. in Dateisystem:4096
Geräteausrichtung:                                        Ausgerichtet (0x000)
Partitionsausrichtung auf Gerät:                          Ausgerichtet (0x000)
Führt normale Suchvorgänge aus
Kürzen wird nicht unterstützt
Nicht DAX-fähig
Nicht mit schlanker Speicherzuweisung bereitgestellt

 

[Simpson474]

Das ist aber erstaunlich, das Gehäuse macht wohl auch bei der 8 TB Festplatte die 4 KB Emulation - trotzdem geht es schief. Kann ich mir so tatsächlich auch nicht erklären, es sei denn, die haben nicht die vollen 48-Bit in dem USB-Controller implementiert, die laut Standard eigentlich nötig wären.

 

[SFFox]

Testen hilft...
Ursprungsfehler: HDD1 + Intenso USB 3.0 Gehäuse, befüllt per rsync => Luks kann nicht mehr geöffnet werden

Weitere Tests:
HDD2 + Intenso USB 3.0, befüllt per rsync => Luks kann nicht mehr geöffnet werden ❌
HDD1 + IcyBox Dock, befüllt per rsync => Luks kann wieder geöffnet werden ✅

Der Füllstand beider Platten nach dem selben rsync (vor dem ersten luksClose) unterscheidet sich in der Größenordnung ~70GB.

@klapproth @foofoobar
Die Header sehen auch sehr unterschiedlich aus, im einen kann man was von Luks lesen und der andere ist nur Byte Müll. Damit ist das alte Intenso Memory Center USB 3.0 Gehäuse mit VL701 Controller wohl als Übeltäter identifiziert.

Der Fehler tritt auch erst ab einem gewissen Füllstand auf, denn eine Text Datei anlegen oder auch ein 150GB pile of data lies sich korrekt closen und wieder öffnen/mounten. Dann hole ich mir wohl mal ein neues externes Gehäuse zur Lagerung, da ist die Platte geschützter als sie roh rum liegen zu lassen.

Besten Dank für eure Unterstützung.

 

[JumpingCat]

Intenso ist von der Qualität her auch eher absolut zu vermeiden.

 

[SFFox]

Würde ich nicht so pauschalisieren... Ist ein Gehäuse von 2013 das mit max 4TB verkauft wurde (die ersten 5TB Platten kamen erst ~2014), der genutzte VIA Chip VL701 ist einfach alt... ist jetzt kein Grund gegen Intenso zu schießen.

 

[kieleich]

mal ein großes X darauf und ab zum elektro schrott

 

[SFFox]

Mit bis zu 4 TB funzt es ja, dafür wurde der gemacht. Nimmt man halt ne kleinere Platte und im Familien-/Freundeskreis kann das sicher noch jemand nutzen. Wegwerfgesellschaft ey... 🙄
Einen Hinweis ins Gehäuse werde ich aber kleben, sonst vergesse ich das selbst 😅