Am Montag, dem 16.09.2024 um 16:19 +0200 schrieb ronny@seffner.de:
Hallo Gruppe,
Hallo Ronny
ich schreibe gerade am Notfallhandbuch
OK, sollte man ja haben. Nutzt Du da eine bestimmte Vorlage und passt Sie an oder erstellt nach Bedarf?
und versuche eine ext4 crypted Verzeichnisstruktur an einem beliebigen anderen Rechner zu lesen.
Ich gehe mal davon aus es verhält sich ähnlich wie f2fscrypt. Hierbei hab ich immer das -S Argument benötigt um es auf anderen Geräten nutzen zu können.
Hängt die Backupplatte am zu sichernden Rechner, verwende ich 'e4crypt add_key -k @u /backup/crypted' und erhalte "Added key with descriptor [***719]"
Was ist da dein Salt-Argument (-S)? Wird das auf den anderen Rechnern gleich initialisiert? Vermute mal "man e4crypt" hast du gelesen.
Hänge ich die Platte an einen anderen Rechner (auch debian 12 amd64, gleicher kernel) und verwende den gleichen Befehl, erhalte ich: "Added key with descriptor [***870]" "Error [File exists] setting policy" "The key descriptor [***870] man not match the existing encryption context for directory [/backup/crypted]"
Die Verzeichnisstruktur ist dann für mich unlesbar (Buchstabensalat) und in die Dateien darf ich nicht reinschauen (cat $FILE ... Der notwendige Schlüssel ist nicht verfügbar)
Ich bin sicher, dass ich beide Male das gleiche Kennwort eingebe. Ich bin sicher, dass beide Keyboard-Layouts identisch sind. Ich habe schon einen 3. Rechner probiert - gleiches Phänomen.
Was sagt dein process keyring keyctl show
'e4crypt add_key -k @u' auf der Backupmaschiene, gefüttert mit "bernd" liefert: Enter passphrase (echo disabled): Added key with descriptor [b975e6332e33edb7] Added key with descriptor [f33468f048ce7354]
Das gleiche auf den anderen "restore"-Testmaschinen leifert hingegen: Enter passphrase (echo disabled): Added key with descriptor [f33468f048ce7354]
Warum hat das Backupsystem ZWEI descriptoren?
Würde vermuten unterschiedliche Initialisierung.
VG Gerd
Ich bin ratlos, hat wer eine Idee?
Mit freundlichen Grüßen / Kind regards Ronny Seffner