WORM Ordner aus versehen auf der falsche Festplatte erstellt und befüllt, bis der Speicher voll ist

[profile7]

Hallo zusammen,

ich bin hier im Forum neu und starte gleich mit einem Problem, das mich diese Woche beschäftigt hatte. Bei mir hatte Murphys Gesetzt voll zugeschlagen .
Leider muss ich etwas ausholen, damit ihr euch hineinversetzten könnt. Ich versuche das wesentliche zusammenzufassen.

Verwendete Hardware Konfiguration ist eine DS220+ mit 2 Festplatten ohne Raid, da sie unterschiedliche Größen haben. (Vielleicht lag hier schon der Designfehler)

HDD1: Seagate Desktop SSHD 2TB (Basic) - Alle wichtigen Daten
HDD2: WD Red Plus 4TB (WD40EFRX - als SHR) - HyperBackups anderer NAS und Snapshots von HDD1

Letzten Samstag ist der Status der HDD2 auf kritisch gewechselt. Es war nur noch Lesezugriff möglich. Das meiste von den Hyperbackups der anderen entfernten NAS habe ich runterkopieren können und die Platte erneut mit DSM formatiert. An die Snapshots hatte ich zu dem Zeitpunkt nicht mehr gedacht. Jedenfalls hatte DSM das Formatieren der Platte abgebrochen, da es Sektorenfehler gab.

Jedenfalls habe ich kurz darauf eine neue WD Red Plus 4TB (WD40EFPX) bestellt und in die DS220+ eingebaut. Dabei wollte ich das neue DSM 7.2 Sicherheitsfeauture WORM (Write Once Read Many) ausprobieren und die neue Freigabe auch so eingerichtet. Dieses habe ich im Complience Modus erstellt, also das nicht einmal der Admin diesen Ordner löschen kann, also maximale Sicherheit. Hinter dem Freigabenamen steht als Ergänzung "WriteOnce".

Was ich aber leider zu spät bemerkt habe, ist dass es nicht auf der neuen HDD2, sondern auf der kleineren HDD1 erstellt worden ist. Bemerkt habe ich es als die Meldung per Email kam, dass auf HDD1 kein Speicher mehr frei ist. Das Löschen war natürlich auch nicht möglich, da es ja im Complience Modus erstellt worden ist. Synology selbst schreibt in ihrer Knowledge Base, dass es nicht möglich ist und nur durch externes Formatieren der Festplatte gelöscht werden kann. (https://kb.synology.com/en-au/DSM/tutorial/how_to_delete_compliance_mode_writeonce_shared_folder).

Also hatte ich von der HDD1 einen Klon mit dc3dd erstellt, bevor irgendwelche Manipulationen vorgenommen werden. Nach dem Klonen der HDD1 hatte ich mit beiden Platten der HDD1 und der HDD1-Klon das DSM gestartet. Jedoch war es ein sehr eingeschränktes DSM, wo viele Apps mit einem Ausrufezeichen versehen waren. Ein Reparieren über das Paketzentrum konnte auch nicht durchgeführt werden. Selbst die Einstellungen wurde nicht richtig angezeigt. Bei den Ordner Freigaben wurde nichts angezeigt. Der Dateimanager war nicht verfügbar. Kurz gesagt, nichts ging mehr. Das gleiche Bild auch bei der HDD1-Klon.

Leider konnte ich die HDD1 auch nicht mit Linux Mint 22 (auf Basis Ubuntu 24.04) mounten. Da soll der Kernel zu neu sein, der die flags von Synology nicht ignorieren wollte. Hier der Artikel dazu: (https://www.nas-central.de/synology-nas-defekt-datenrettung/)

Also musste ich von ganz vorne anfangen mit der Hoffnung, dass ich meine HDD1 noch retten kann. Die neue HDD2 auf dem PC formatiert und dann alleine ohne HDD1 in die DS220+ eingesetzt und automatisch einrichten lassen. Alte Hyperbackups oder Konfigurationen ließen sich mangels Zugriff nicht aufspielen.
Nachdem DSM neugestartet ist, hatte ich auch die HDD1 eingesetzt und die verschollen Freigabe wurden wieder angezeigt . Als erstes habe ich 100 GB auf eine ext USB-Platte verschoben. Aber der Freie Speicher ist immer noch auf 0 Byte. Aktuell läuft eine Datenbereinigung auf HDD1. Ich hoffe, dass danach genug freier Speicher vorhanden ist, dass man zumindest von HDD1 wieder starten kann.

Wie geht es nun weiter?
Meiner Meinung nach gibt es min. 3 Optionen:

1. Platz freischaufeln und mit den 400GB WriteOnce Freigabe 3 Jahre lang leben. Das waren die "default Werte" bevor man es wieder löschen kann. (geringster Aufwand)
2. Umziehen auf eine neue Installation, zB auf die neue HDD2 und alle neu Einrichten, ggf. alte Konfigurationen verwenden (höherer Aufwand)
3. WORM (WriteOnce) Freigabe mit Linux löschen (wahrscheinlich auch hoher Aufwand, aber mit etwas "Glück" wenig Aufwand)

So, vielen Dank für alle, die bisher gelesen haben. Ich würde mich über eure Anregungen und Ideen freuen, wie man am Besten aus dieser Misere rauskommt.

LG Joe

 

[ctrlaltdelete]

Kopiere alles von der HDD1 auf eine andere HDD und formatiere HDD1 extern.

 

[Benie]

Was das auslesen der HDD am PC betrifft, im Prinzip ist das mit einem Ubuntu 18.04 ISO Download und einem mit Rufus und der ISO versehenen USB Stick mit 3-4 Eingaben im Terminal erledigt.

Habe mich die letzten Tagen damit beschäftigt und bin gerade dabei hierfür eine Anleitung für nicht so versierte Anwender zu erstellen.

Boote das ISO vom Stick und melde Dich als Sudo -i auf der Kommandozeile an.

Folge Punkt 10. der Synology Anleitung bis zum Punkt 11. Danach hast Du bereits zugriff auf die HDD und kannst sie auslesen, sprich Deine Daten kopieren.

Edit den Rest der Synology Anleitung mußt Du Dir nicht antun.


https://kb.synology.com/de-de/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

 

[profile7]

Boote das ISO vom Stick und melde Dich als Sudo -i auf der Kommandozeile an.

Folge Punkt 10. der Synology Anleitung bis zum Punkt 11. Danach hast Du bereits zugriff auf die HDD und kannst sie auslesen, sprich Deine Daten kopieren.

https://kb.synology.com/de-de/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

Moin Benie,
ja die Anleitung von Synology kannte ich bereits, aber hatte bis dahin nicht die Info, dass man eine ältere Linux Distro braucht um auf die Daten zugreifen zu können.

Ich habe jetzt einen Lesezugriff mit Linux Mint 19.2 auf die Daten erhalten. Aktuell kopiere ich alle Daten logischen auf eine externe HDD rüber.

Bis hierhin bin ich schon mal beruhigt, dass die Daten nicht verloren sind und ich in Ruhe mit der Migrierung weitermachen kann.

Nach dem Kopiervorgang kann ich ja probieren die Partition mit Schreibrechten einzubinden und dann den Inhalt aus dem WORM Ordner zu löschen.

 

[synfor]

In der Anleitung steht doch drin, welche Distro man braucht.

 

[profile7]

In der Anleitung steht doch drin, welche Distro man braucht.
Anhang anzeigen 98462

Ja, du hast recht. Das steht tatsächlich dort. Keine Ahnung, warum ich das übersehen habe oder dieser Info nicht so viel beachtung geschenkt hatte. Evtl. hatte ich auch erwartet, dass ein neueres Linux ebenfalls funktionieren sollte.
Leider steht aber auch nichts darüber, es nur diese Linux Version sein muss, damit es funktioniert.

 

[Benie]

Leider steht aber auch nichts darüber, es nur diese Linux Version sein muss, damit es funktioniert.

Reicht aber doch, sonst würde am Ende dastehen diese und neuer

 

[profile7]

Hallo zusammen,

ich möchte hier noch mal für die Nachwelt berichten, wie ich das Problem mit dem WriteOnce (WORM) Ordner gelöst habe.

Bevor das hier jemand als Anleitung bei sich umsetzt, sei gewarnt. Habe immer ein Backup von deinen Daten, auch wenn es doppelt so viel Zeit kostet. Denn "Kein Backup, kein Mitleid".

Also wie bereits in den verlinkten Artikeln, wird eine Ubuntu 18.04 benötigt. Ich hatte auf Basis von Ubuntu ein Linux Mint 19.2 verwendet. Mint 19.3 müsste auch funktionieren. Die LIVE CD Version reicht völlig aus.
Benötig wird auch ein Anschluss der Platte über SATA oder eSATA und nicht über USB-Adapter (siehe weiter unten die Erklärung).

Auszug aus (https://www.nas-central.de/synology-nas-defekt-datenrettung/):

NAS Festplatten im PC einbinden​

Vereinfacht gesagt werden die md Raids neu zusammengestellt und anschließend die logischen Volumen aktiviert. Daraufhin werden die entsprechenden Geräte gemountet und die Daten sind zugreifbar. Der oben verlinkte Beitrag beschreibt das Verfahren im Detail.
mdadm -AsfR vgchange -ay mount ${device_path} ${mount_point}

Zur Erinnerung es war nur eine Basic Platte, also kein RAID Verbund.

sudo su apt install mdadm mdadm -AsfR vgchange -ay

Bei mir war es /dev/md2 und ich hatte es an /mnt als read only gemountet.
mount /dev/md2 /mnt/ -o ro

Erst danach konnte man es auch schreibend einbinden:
mount /dev/md2 /mnt/ -o remount,rw

Ich bin in den ReadOnce Ordner mit gewechselt und dort den Inhalt, also alle Dateien und Unterordner gelöscht mit
rm -rv * -r für rekursiv und -v für verbose

Danach cd / und unmount /mnt

Damit ist der Vorgang erledigt. Die Festplatte kann wieder in den alten NAS Steckplatz eingesetzt werden. Wie zur erwarten, war die WriteOnce Freigabe noch da, aber auf der Festplatte waren danach 400GB mehr Speicherplatz verfügbar.

Alles funktionierte wieder wie vorher.

Mögliche Probleme beim Löschen in Verbindung mit Docking Stations
Also, ich hatte die Platte über eine ext Docking Station über USB angeschlossen. Alles hatte wie oben beschrieben funktioniert, bis zu dem Zeitpunkt wo das Löschen der Dateien begann. Sehr schnell waren im dmesg -w auf dem 2. Terminal Fehlermeldungen aufgetaucht. Diese waren bei allen ausprobierten Linux Versionen. Das waren Linux Mint, Mint Debian 4 und Lubuntu 18.04.

Die Meldung sah bei allen ähnlich aus:

Spoiler: dmesg auf Linux Mint

[40523.028568] sd 11:0:0:0: [sdg] tag#13 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK
[40523.028569] sd 11:0:0:0: [sdg] tag#13 CDB: Write(16) 8a 00 00 00 00 00 01 6d b6 00 00 00 00 20 00 00
[40523.028570] print_req_error: I/O error, dev sdg, sector 23967232 flags 801
[40523.050746] btrfs_dev_stat_print_on_error: 20 callbacks suppressed
[40523.050753] BTRFS error (device md2): bdev /dev/md2 errs: wr 3065, rd 1, flush 0, corrupt 0, gen 0
[40523.050768] BTRFS error (device md2): bdev /dev/md2 errs: wr 3066, rd 1, flush 0, corrupt 0, gen 0
[40523.050770] BTRFS error (device md2): bdev /dev/md2 errs: wr 3067, rd 1, flush 0, corrupt 0, gen 0

Spoiler: dmesg auf Mint Debian

[ 6239.300731] BTRFS error (device md2): bdev /dev/md2 errs: wr 233, rd 1, flush 0, corrupt 0, gen 0
[ 6239.300732] sd 11:0:0:0: [sdg] tag#2 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK
[ 6239.300734] sd 11:0:0:0: [sdg] tag#2 CDB: Write(10) 2a 00 00 95 4d 60 00 00 20 00
[ 6239.300736] print_req_error: I/O error, dev sdg, sector 9784672

Spoiler: dmesg auf Lubuntu 18.04

116.179271] BTRFS: device label 2019.03.18-23:03:19 v23824 devid 1 transid 7341494 /dev/md2
[ 137.029981] BTRFS info (device md2): using free space tree
[ 137.029985] BTRFS info (device md2): has skinny extents
[ 137.029987] BTRFS error (device md2): cannot mount read-write because of unsupported optional features (800000000000000)
[ 137.048186] BTRFS error (device md2): open_ctree failed
[ 142.269756] BTRFS info (device md2): using free space tree
[ 142.269759] BTRFS info (device md2): has skinny extents
[ 142.297078] BTRFS critical (device md2): corrupt leaf: root=1 block=102793216 slot=0, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 142.297082] BTRFS error (device md2): block=102793216 read time tree block corruption detected
[ 142.297585] BTRFS critical (device md2): corrupt leaf: root=1 block=102793216 slot=0, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 142.297587] BTRFS error (device md2): block=102793216 read time tree block corruption detected
[ 142.348184] BTRFS error (device md2): open_ctree failed
[ 179.928375] BTRFS info (device md2): using free space tree
[ 179.928377] BTRFS info (device md2): has skinny extents
[ 179.932333] BTRFS critical (device md2): corrupt leaf: root=1 block=102793216 slot=0, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 179.932338] BTRFS error (device md2): block=102793216 read time tree block corruption detected
[ 179.932588] BTRFS critical (device md2): corrupt leaf: root=1 block=102793216 slot=0, invalid root flags, have 0x400000000 expect mask 0x1000000000001
[ 179.932591] BTRFS error (device md2): block=102793216 read time tree block corruption detected
[ 179.972651] BTRFS error (device md2): open_ctree failed
[ 240.943206] usb 6-1.4: USB disconnect, device number 4
[ 240.960129] Buffer I/O error on dev md2, logical block 487173120, async page read
[ 240.969222] Buffer I/O error on dev md2, logical block 487173120, async page read
[ 241.159828] md2: detected capacity change from 1995461165056 to 0
[ 241.159890] md: md2 stopped.

An dieser Stelle war alles sehr träge. Ich konnte die Platte auch nicht mehr ordnungsgemäß aushängen. Selbst nach einigen Minuten warten. Der Zugriff auf die Platte hatte das ganze System gelähmt.

Nach einer kurzer Recherche, hatte ich herausgefunden, dass es am USB Treiber und der Docking Station über USB zusammenhängt. Als ich die Platte an einer anderen Docking Station über den eSATA-Anschluss verbunden hatte, gab es diese Meldungen nicht. Wie oben bereits erwähnt habe ich dann das Löschen mit Linux Mint erfolgreich durchgeführt. Ob es bei den anderen Distributionen geklappt hätte, kann ich natürlich nicht sagen.