Volume schreibgeschützt, HDDs aber normal - Datenrettung wie?

[ctrlaltdelete]

@Benares @maxblank Ja, klar, meine Fehler BTRFS.

 

[Benares]

Mmh, nicht mein Spezialgebiet. Bei mir ist /dev/mapper/cachedev_1 als /volume1 gemountet.
Unter /dev/vg1 gibt's

root@DS1522:~# ll /dev/vg1
total 0
drwxr-xr-x  2 root root    80 Feb  4 12:36 .
drwxr-xr-x 12 root root 14160 Feb  4 12:38 ..
lrwxrwxrwx  1 root root    37 Feb  4 12:36 syno_vg_reserved_area -> /dev/mapper/vg1-syno_vg_reserved_area
lrwxrwxrwx  1 root root    24 Feb  4 12:36 volume_1 -> /dev/mapper/vg1-volume_1

Momentan wüsste ich wirklich nicht welches Device man da genau checken müsste.

 

[maxblank]

Falls SSH geht, folgendes in die Console eingeben.

cat /proc/mounts | grep volume

Falls das Volume als read-only (ro) gemountet ist, kannst du es mit folgendem Befehl manuell neu mounten.

sudo mount -o remount,rw /volume1

Volume bitte unbedingt auf deine zutreffende Zahl anpassen.

Ich übernehme keinerlei Garantien, falls Daten verloren gehen - alles auf eigene Verantwortung.

Bitte das versuchen. Wenn das fehlschlägt, suche ich die passenden Synology Befehle für btrfs raus.

Synology immer mit ihrem oftmals selbst "komponiertem" Sondergelöte.
So praktisch wie es im alltäglichem Einsatz sein kann, so nervig ist es beim Troubleshooting.

 

[knilch]

Mmmmh... Hilft das hier?


Mit dem anderen Befehl hab ich nur die mounts bekommen, die bei mir nach einem boot per Script mounted werden:

 

[maxblank]

Den Befehl ausgeführt?
sudo mount -o remount,rw /volume2

 

[knilch]

 

[knilch]

2ter Versuch, jedoch Anweisungen von Beanares zuvor ausgeführt (OHNE fsck.ext4):

 

[maxblank]

Bitte nicht die Befehle wild mischen. Das bringt nichts.
Teste es mal noch mit /volume1

Ich habe jetzt noch einen Termin. Ich schreibe heute abend die Befehle raus für Synology mit btrfs. Falls ich es vorher teste, kann es auch morgen werden.

 

[knilch]

Hey, lieben Dank Euch!

OK, dann ich warte lieber die finalen Befehle ab.
"/volume2" sollte jedoch richtig sein, siehe auch Screennshot DSM auf Seite 1.

 

[maxblank]

Alle u.a. Befehle müssen als Root ausgeführt werden. Daher mit sudo -i zum Root machen.

Scrubbing ausführen:

btrfs scrub start /volume2

Fortschritt kannst du mit folgendem Befehl beobachten:

btrfs scrub status /volume2

Scrubbing findet nur Fehler, die durch die Prüfsummen erkannt werden. Es kann keine strukturellen Dateisystemfehler reparieren.

---

Prüfen, an welcher Stelle das Volume gemountet ist und notieren (z.B. dev/vg1/lv). Das muss entsprechend bei den u.a. Befehlen immer angepasst werden.

mount | grep btrfs

Dienste stoppen, die auf das Volume zugreifen:

synospace --stop-all-spaces

Dienste wieder starten:

synospace --start-all-spaces

---

Sei dir bitte bewusst, dass diese Befehle zum Teil tief ins System eingreifen und dies ggfls. zu Datenverlust führen kann.

Eventuell überlegst du dir, ob du den Synology Support einschaltest.

---

Edit am 19.03.2025: Ich habe die nicht zutreffenden Befehle bzw. die Befehle, die in dem Fall nicht weitergeholfen haben, hier gelöscht.
Die Lösung um ein Volume, wie in diesem Fall, wieder lesbar zu machen, ist hier im Thema unter folgendem Link zusammengefasst.
https://www.synology-forum.de/threa...r-normal-datenrettung-wie.138005/post-1234295
Wenn dann die technische Ursache behoben wurde, sollte es auch gemountet bleiben.

 

[Benares]

Bin da nicht so bewandert, aber müsste syno_poweroff_task -d ab DSM7 nicht durch synospace --stop-all-spaces oder synostgvolume --unmount -p /volume2 ersetzt werden? Hatte ich mir mal so notiert.

Edit: Außerdem gibt es /dev/vg1/lv z.B. bei mir nicht (s. #22)

 

[plang.pl]

synospace --stop-all-spaces

Hatte ich auch so notiert.

 

[maxblank]

@Benares / @plang.pl: Ihr habt Recht, dass der o.a. Befehl ab DSM 7 nicht mehr funktioniert. Allerdings wurde scheinbar „synospace --stop-all-spaces“ mit DSM 7 ebenfalls eingestampft. Ich habe es oben mal durch „synosystemctl stop“ oder „synoservice --stop-all“ ersetzt. Was meint ihr dazu?

Edit: Außerdem gibt es /dev/vg1/lv z.B. bei mir nicht (s. #22)

Das soll vorher daher mit dem Befehl kontrolliert werden:

mount | grep btrfs

Falls @knilch etwas Zeit und Geduld hat, prüfe ich die o.a. Befehle morgen gerne alle auf meiner Test-DS gegen. Ich habe es nach bestem Wissen und Gewissen recherchiert und zusammengefasst.

 

[Benares]

Also laut synospace --help gibt es synospace --stop-all-spaces noch. Ich würde es erstmal damit probieren.
Wäre super, wenn wir für diesen wirklich leidigen Fehler endlich mal eine Lösung finden könnten, allerdings kenne ich mich damit, wie gesagt, auch nicht wirklich aus.

 

[plang.pl]

synoservice gibts bei meiner 720+ mit DSM 7 nicht.
synosystemctl sagt ja folgendes:


synospace sagt das bei mir

Ich meine, dass synospace unter DSM7 noch funktioniert. Kann es aber nicht testen grad

 

[maxblank]

Ich habe „synospace --stop-all-spaces“ oben eingetragen.

 

[Benares]

Bin mal gespannt, wie weit er damit kommt. Vielen Dank für deine Hilfe/Recherche

Edit: Was denkst du zu dem /dev/vg1/lv-Problem, was es bei mir nicht gibt? Sollte da nicht besser /dev/mapper/cachedev_1 rein, bzw. das, was "mount | grep volume2" dabei ausgibt?

 

[maxblank]

Ich danke euch für eure Inputs, Infos und euer Schwarmwissen. Nur gemeinsam sind wir stark.
Morgen werde ich das verifizieren und gegentesten. Dann sehen wir weiter.

 

[Benares]

Und wir danken Dir.

 

[maxblank]

Edit: Was denkst du zu dem /dev/vg1/lv-Problem, was es bei mir nicht gibt? Sollte da nicht besser /dev/mapper/cachedev_1 rein, bzw. das, was "mount | grep volume2" dabei ausgibt?

Durchaus möglich. Ich denke, dass wir uns da Stück für Stück annähern müssen.