Volumen-Entschlüsselung nach DSM 7.2.1 69057 Update 5 nicht mehr möglich

[bmac]

Tag die Leute;

ich hab eine DS1522+ mit 1x Raid 5 und 2x je einen Speicherpool mit je 1x Einzelvolumen.
Bei den Einzelvolumen hatte ich bei der Speicherpoolerstellung die "Volumenverschlüsselung" eingerichtet; Keys und Schlüsseltresor-Pw gesichert; funktionierte bis quasi eben auch super.
Beide verschlüsselten Volumen waren / sind als Netzlaufwerke eingebunden.

Heute fiel mir auf, dass die Entschlüsselung dieser Volumen nicht mehr funktioniert.
Bei einem Volumen habe ich den Key neu generiert (NAS Neustart durchgeführt). Das funktionierte auch, der Zugriff ist allerdings trotzdem nicht vorhanden.

Vor kurzem hatte ich das Update 5 aufgespielt; diese Maßnahme ist (bis auf gestern das Update der Synology Drive App) die einzige Veränderung am ganzen System.


Die Volumenverschlüsselung soll sich doch eigentlich beim Starten der NAS eigenständig entschlüsseln und somit bspw. den Netzlaufwerkzugriff ermöglichen?
Wo denke ich falsch?

Thanx für Input ^.

 

[metalworker]

1. Frage Backup der Daten hast du ?


Du hast geschrieben du hast nen neuen Key Generiert , das sollte meines Wissen gar nicht gehen wenn der Volume noch verschlüsselt ist.

 

[bmac]

meine wichtigen Daten habe ich im Hyper-Backup; log`n ^.

über den Speicher-Manager / globale Einstellungen habe ich den Schlüsseltresor erneuert (Pw gleich gelassen).
In der Synology-Beschreibung steht, dass sich hierbei auch die Keys der Volumenverschlüsselung erneuern.
Diese müssten sich doch beim zurücksetzen des Schlüsseltresors zum download anbieten?

Ebenso schreibt Synology, dass man - sofern die automatische Entschlüsselung beim NAS starten nicht funzt - diese im Speicher-Manager unter den Volumen / "3 Punkten" / Einstellungen manuell mit dem Keyfile entsperren kann.

> https://kb.synology.com/de-de/DSM/help/DSM/StorageManager/volume_create_volume?version=7#unlock

Knackpunkt:
Diese Entsperrung bietet sich aber gar nicht an; obwohl die Volumen im Speicher-Manager als verschlüsselt deklariert sind.

Bei einem Volumen habe ich dann im Speicher-Manager den Key über Einstellungen / Wiederherstellungsschlüssel erneuern - erneuert. Hier bot sich der Key dann zum Download und abspeichern an.

Letztendlich muss aber das Volumen irgendwie (trotz das ich per sonst funktionierender Netzwerkfreigabe nicht auf den angelegten Ordner zugreifen kann) doch entschlüsselt sein;
denn unter Systemsteuerung / Freigegebene Ordner kann ich lustigerweise auf den als verschlüsselt gekennzeichneten Volumen neue Ordner erstellen, die dann auch ordnungsgemäß über Netzlaufwerkverbindungen erscheinen und auf diese zugegriffen werden kann.


Ich habe hierzu auch Synology angeschrieben und ein Protokollfile zugesendet; mal schauen was die sagen.

 

[bmac]

Feedback

Sooo, hab eine Lösung gefunden - ich will das mal kurz beschreiben; vielleicht hat jemand auch irgendwann mal dieses Problem:

Synology konnte aus der von mir zugesendeten 20MB Protokolldatei nichts zutragen;
außer das sie gerne SSH Zugang haben würden. Gewährte ich nicht.

Was mir gestern jedoch im Hyperbackupmenu selbst auffiel ist, dass die im FileManager nicht mehr sichtbaren und zugreifbaren Ordner/Volumen wie

backupTM (Speicherpool 1, unverschlüsselt)
docker (?!, WTF) Speicherpool 1, unverschlüssel)
fiel mir erst später auf das diese im Filemanager auch nicht mehr sichtbar sind

Volumen 2 (volumenverschlüsselt)
Volumen 3 (volumenverschlüsselt)

im Hyperbackupmenu selbst schon dargestellt werden - und die verschlüsselten Volumen dort tatsächlich auch als unverschlüsselt (offenes Schloss) dargestellt werden (auch wenn kein vorher funktionierter Netzwerkzugriff möglich ist).

Fehlerquelle könnte ggf. der FileManager im Zusammenhang mit einem Update vom 17.04.2024 der DriveServerApp sein.
Das wäre neben dem einspielen des Updates DSM 7,2,1 / 5 die einzige Änderung aus den Tagen. Der Fehler lies sich aber nicht reproduzieren.


In meinem Hyperbackup waren die beiden verschlüsselten Volumen 2 und 3 vorher nicht für ein Backup aktiviert, weil die Backupplatte z Zt zu klein für ein ganzes Systembackup ist; Vol 2/3 war jetzt auch nicht oberwichtig und hatten nicht wirklich Priorität - aber der Nichtzugriff ärgerlich und vor allem nicht nachvollziehbar.

Da ich die Hyperbackupaufgabe nicht löschen wollte (bei einer testweisen Neuanlage waren die "vermissten" Ordner nicht aufgeführt, also kein Zugriff) habe ich bis auf einen kleinen Teil alle vorher zum Backup aufgeführten Ordner abgewählt, die Versionierung auf 1 heruntergestellt (bin ich erst spät drauf gekommen ^), und nun nur Volumen 3 ausgewählt.
Dafür war nun nach dem abwählen der vorherigen (und aktuell auch zugreifbaren) Ordner genug Platz für Volumen 3.
Die einzelnen Backup-Dateien auf der Backupplatte löschte ich alle manuell über die HyperbackupApp.

Das neue Hyperbackup lief sauber durch. Das Backup ist auch auf Linux einsehbar (ext4).

Da ich aber nochmal nebenher ein Synologyvideo zu Hyperbackup geschaut hatte wurde ich darauf aufmerksam, dass ich auch aus dem Hyperback heraus auf der Synology mit angeschlossener USB-Backupfestplatte direkt in einen neu angelegten Ordner auf das unverschlüsselte Speichervolumen 1 (Raid 5) rüberschieben kann. Das geht wohl fixxer.

Für das 2. nicht zugreifbare Volumen verfahre ich identisch, logisch.

Volumen 2 und 3 lösche ich im Speichermanager und binde es neu ein, das backupTM vom Mac war nur ein Zweitbackup, das mach ich einmal komplett neu. Docker lief nur ein Rustdeskserver (war aber trotzdem funktionsfähig trotz nicht mehr Sichtbar), keine große Sache.

Letztendlich bin ich also Dank vor dem Problem eingerichteter - und somit die Möglichkeit Ordner / Volumen an - oder abzuwählen, Hyperbackupaufgabe wieder an die verloren gedachten Daten wieder herangekommen.

Next Week gibts erstmal eine grössere Backup-HDD ... meio^.

#wohlsein.