gelöst: File system error was found on volume....

[Fusion]

War das der ext4 Prüfungsversuch auf das btrfs Dateisystem? Wenn ja kannst das mal überall unter deine Postings ergänzen.

 

[mihle]

Hallo,
ich würde die Hinweise aus dem 1. Posting gerne anwenden, scheitere aber schon bei der Suche nach dem Terminal. Oder habt Ihr alle Linux Rechner verwendet?

Ich nutze ein Volume mit Fehlertoleranz 1 und habe eine Festplatte austauschen müssen. DSM 1812+ mit 7 Laufwerken.
Beim Versuch das Volume zu eweitern auch die Fehlermeldung erhalten: "Vorgang fehlgeschlagen, weil im Dateisystem Fehler aufgetreten sind."

Die SMART-Ergebnisse sind alle ok, Volume Normal, Speicherpool normal.
Eine Datenbereinigung im Speicherpool habe ich auch durchlaufen lassen.
mehrere Reboot versucht,
Festplatte rausgezogen und reingesteckt, damit er einen Repair anbietet auch gemacht.

Über jede Hilfe dankbar!!!

 

[Fusion]

Ssh oder telnet findet sich in der Systemsteuerung ganz unter bei Terminal/snmp oder ähnlich.
Clients auf Linux und Mac schon 'eingebaut', bei Windows braucht es meist putty oder einen passenden Client, eventuell mit dem subsystem for Linux inzwischen auch ohne weitere Hilfsmittel.

 

[mihle]

Vielen Dank für die Hilfen. ?
Bezüglich Windows und SSH bin ich hier
https://www.heise.de/tipps-tricks/SSH-unter-Windows-10-nutzen-4224757.html
fündig geworden.

Nach dem fsck.ext4 -pvf -C0 /dev/vg1000/lv
erhielt ich die Meldung: Inodes that were part of a corrupted orhan linked list found.
... dann also mit fsck.ext4 -yvf -C0 /dev/vg1000/lv fortgesetzt.
Und dann ging's richtig ab.

Nach den vielen Meldungen zu möglichen Fehlern, bestätigte er die Abfrage immer automatisch mit "ja".
Danach per Befehl reboot neu gestartet.
Und das Volume ohne weitere Probleme erweitert!

Fantastisch!!!
Vielen vielen Dank für diese hilfreiche Anleitung und auch die weitere Unterstützung durch Fusion!!!
(mein erstes mal SSH )

 

[mamema]

ich möchte diesen älteren Thread aufwärmen, da ich aktuell dieselben Probleme habe:
- SMART unauffällig
- Reboot hilft nicht
- fsck.ext4 (siehe oben) aber auch nicht.....(lief durch, keine Auffälligkeiten)

ein Leidensgenosse anwesend, der mir noch weitere Tips geben könnte?

Ich habe seit ein paar Wochen ISCSI auf dem Volume aktiv. Weiss nichbt ob das damit zusammenhängt....

 

[Syno-OS]

Also hier mal eine vernünftige Anleitung.

Voraussetzung prüfen:

Ist es ein Ext4 Dateisystem? Fehler im Beitrag #40
Speicher Manager zeigt was an?
Wenn das Volume nicht im Speicher Manager sichtbar oder Status 'abgestürzt/crashed' ist, dann ist die Kacke am Dampfen, Support schreiben oder bei einem Data Rescue unternehmen fragen. Backup sollte jetzt vorhanden sein und immer vor all diesen Schritten durchgeführt werden!

Weiter geht ab hier, wenn Volume 'normal' oder 'fehlerhaft' Status hat. 'fehlerhaft' Status kommt vom RAID, interessiert das Dateisystem aber nicht, Festplatte ersetzen.

Putty / telnet:
Gut geklaut ist halb gewonnen, daher der Link aus Betrag #44
https://www.heise.de/tipps-tricks/SSH-unter-Windows-10-nutzen-4224757.html

DS login: admin
Password: xxx

dann erst mal aus dem Home Ordner des 'admin' raus, der auf dem Volume liegt, dies ist bei euch der Fehler, wenn die SSH Verbindung getrennt wird, wenn Ihr syno_poweroff_task -d ausführt.
Fehler im Beitrag #19, #21, #29

admin@DS:~$ cd /
admin@DS:~$ sudo -i
Password: xxx

root@DS:~#
root@DS:~# cd /

dann erst mal aus dem Home Ordner für root raus, aber hier nicht so schlimm, da der Ordner auf der System liegt.
Da das Dateisystem ja noch intakt ist, kann man hier ja getrost den mount Befehl ausführen, da sieht man dann gleich das richtige Device, da steht dann auch das Dateisystem dabei, falls ihr zu faul wart im Speicher Manager nachzuschauen.
Fehler im #11, nicht das richtige Device gewählt

root@DS:~# mount | grep volume

Jetzt haben wir die nötigen Informationen und nun geht es los:

syno_poweroff_task -d

Schadet nie, daher kann man getrost immer ausführen:
vgchange -ay

Hier bevorzuge ich immer die 'y' Option, 'p' repariert nicht alles, DSM führt im übrigen 'p' aus... (kein Datenverlust, bei 'y' kann es vorkommen, daher beim DSM geht Sicherheit vor. NOCHMAL ab hier wird es kritisch: Backup nicht vergessen!!!!!)

fsck.ext4 -yvf <device>

Beispiel:
SHR RAID
nohup fsck.ext4 -yvf /dev/vg1000/volume1 &
normales RAID
nohup fsck.ext4 -yvf /dev/md2 &
normales RAID oder SHR RAID mit mehreren Volume Option
nohup fsck.ext4 -yvf /dev/vg1/volume_1 &

Ein wenig Bash Spielerrei mit nohup (screen ist nicht installiert), falls die Verbindung abbricht läuft die Aufgabe weiter. Und die Kontrolle ob der Prozess fertig ist, Ausgabe anschauen
tail -f nohup.out
oder Prozess anschauen, ob er noch läuft
ps aux

reboot

 

[mamema]

Danke für Deinen Hilfeversuch. Ich dachte, ich wär schon deutlich geworden, also nochmal, evtl. ist es dann klarer:

- SMART ist gut
- Nach Boot kommt Filesystem error
- Volume Manager meldet dasselbe und schickt mich nach klicken auf den "Fehlerbereinigungslink" zu der "Boot doch mal" Meldung
- Ist RAID5 kein SHR, Raid läuft ohne Fehler. Volume nicht abgestürzt.
- Den SSH / Telnet Task habe ich durchgeführt, nur das ich : fsck.ext4 -pvf /dev/vg1/volume_2 am Ende ausgeführt habe. Ohne Fehlerrückmeldung durchgelaufen
- Danach gebootet. Wenige Zeit später. Wieder: Filesystemerror... booten bitte

D.h. Deine SSH Befehle habe ich erfolglos durch.....

bzw. ich les grad nochmal, ich hab die etwas weniger invasive fsck.ext4 Variante benutzt. Soll ich Deine nehmen? Kann es das sein?

 

[mamema]

Auch fsck.ext4 -yvf brachte keine Fehler zurück:

 

[Syno-OS]

Welches Dateisystem hat Fehler?
Es gibt da mehr Möglichkeiten... in '/var/log/message' nach Dateisystemfehler geschaut?
Im Zweifel mal alle mit der Option 'n' testen.

fsck.ext4 -nvf <device>

Wenn es das System Dateisystem '/dev/md0' ist -> Reset und neu installieren.

 

[mamema]

Ist ext4 und volume2. Seines Zeichen das Backup Volume Nichts schlimmes drauf
Im /var/log/messages (Danke, auf das naheliegendste kommt man oft selbst nicht) ist zu finden:

2020-09-24T12:27:27+02:00 mediaserver kernel: [20054.325577] EXT4-fs error (device isda): ext4_mb_generate
_buddy:758: group 19680, block bitmap and bg descriptor inconsistent: 27838 vs 27841 free clusters
2020-09-24T12:27:27+02:00 mediaserver kernel: [20054.364479] EXT4-fs error (device isda): ext4_mb_generate
_buddy:758: group 19696, block bitmap and bg descriptor inconsistent: 27836 vs 27839 free clusters

Das sagt mir mehr!
- Das ist das ISCSI Target auf der anderen Synology, welches via isciadm auf dieser (welche den Fehler zeigt) Synology in ein leeres Verzeichnis gemountet wird.

D.h. das ISCSI Volume ist defekt o.ä.
Auf dem Device, wo das ISCSI volume liegt habe ich:


2020-09-17T15:42:07+02:00 NASBackup kernel: [ 181.515632] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (240)
2020-09-17T17:44:03+02:00 NASBackup kernel: [ 171.877442] ata1: link reset sucessfully clear error flags
2020-09-17T17:44:03+02:00 NASBackup kernel: [ 181.533326] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (240)

passt aber zeitlich nicht zu den Fehlern der anderen Synology. Bin grad etwas verwirrt.....

Scheinen andere vor Jahren schon gehabt zu haben: https://lists.openwall.net/linux-ext4/2014/11/28/21

 

[Syno-OS]

Ja, es ist nicht so einfach, wie ihr es euch immer vorstellt, erst mal prüfen wo, dann wie man es behebt und nicht einfach stupide irgendwas in die Konsole hauen.
Ich nehme immer Auto Beispiele, Ihr: Reifen kaputt
Ich: Welche Reifenposition, welche Marke / Modell / Sommer-/Winter-/Matsch / Breite ...??? Auto ist nicht einfach Auto und Reifen ist nicht einfach Reifen...

EXT3-fs, altes NAS Modell ? Reset -> neu oder gibt es kein neures DSM (>DSM 4) für das System?
(md0) System Partition -> Reset, also zwei mal Reset, was werde ich wohl empfehlen ^^

 

[mamema]

äh?
Sorry, aber kann es sein, dass Dein Ton nicht passt?
Wer ist "ihr"?
Also ich hab ext4 auf einer DS1819 und einer DS216+ beide mit neustem DSM

und wenn ich den oben gemeldeten EXT3 Fehler in google prüfe, dann ist es ein "false positive" denn der EXT3 Treiber meldet sinngemäss "ist nicht mein Filesystem - ich bin raus". Dann übernimmt der EXT4 Treiber

Das haben "wir" ganz alleine ohne Dich rausgefunden.
Zu der Reset Bemerkung verkneife ich mir weitere Bemerkungen.

...andere hilfreichere Tips?

 

[mihle]

@mamema: Ich weiß zwar nicht, ob es weiterhilft, aber ich probier's mal, da ich ja erst vor kurzem meinem Synology helfen konnte.
Vor dem Ausführen der Anleitung habe ich sorgfältig geprüft, wie denn mein Volume heißt.
Ich habe gesehen, dass Du mit vg1 gearbeitet hast.
Ich war mir da bei mir nicht ganz klar und hab' mal den Befehl verwendet und einiges wurde mir aufgelistet, mit dem Stern am Ende wird es übersichtlicher.
Sobald das SSH verbunden ist (wie gesagt über Windows jetzt mit Bordmittel möglich), geht's los.
Wichtig ist, dass man alle externen Laufwerke vorher abhängt, das steht auch in der Anleitung.
Dass das Synology die Verbindung zu SSH zulässt (Systemeinstellung) und
ich hatte diverse Datenbereinigungen und Updates gemacht, also alles was noch möglich war.

Teil 1 - SSH über Windows Eingabeaufforderung
ssh name-deines-admin-users@name-deines-synology	er frägt jetzt nach dem PW (muss ich, glaube ich, nicht erwähnen)
sudo -i	richtet den Admin-Zugang ein, PW muss nochmal eingegeben werden
Ls -d /dev/vg*	Jetzt den richtigen Namen des Volumes ermitteln, der Stern grenzt auf Werte, beginnend mit vg ein.

Teil 2 - Reparatur
syno_poweroff_task –d &	& sorgt für die Ausführung im Hintergrund, bricht lt. den Einträgen hier nicht so leicht ab
vgchange -ay	ich zitiere: this will enable the volume
fsck.ext4 -pvf -C0 /dev/vg1000/lv	hier bitte aufpassen, dass der Name stimmt - bei mir hat das nix gebracht, also weiter mit der nächsten Option
fsck.ext4 -yvf -C0 /dev/vg1000/lv	das hat bei mir einige Fehlermeldungen und Abfragen bewirkt, werden aber automatisch bejaht und es geht weiter

Teil 3 - Neustart und raus
sudo shutdown -r	startet den Neustart gleich
exit	beendet die SSH-Sitzung
exit	und die Eingabeaufforderung wird beendet.

Erfahrungsgemäß kommt es auf die strikte Einhaltung der Reihenfolge an.
Allerdings habe ich bei mir auch keine groben Umbau gehabt (nur Speichererweiterung), also kann Dein Problem auch ganz woanders liegen.

 

[Syno-OS]

äh?
Sorry, aber kann es sein, dass Dein Ton nicht passt?
Wer ist "ihr"?
Also ich hab ext4 auf einer DS1819 und einer DS216+ beide mit neustem DSM

und wenn ich den oben gemeldeten EXT3 Fehler in google prüfe, dann ist es ein "false positive" denn der EXT3 Treiber meldet sinngemäss "ist nicht mein Filesystem - ich bin raus". Dann übernimmt der EXT4 Treiber

Das haben "wir" ganz alleine ohne Dich rausgefunden.
Zu der Reset Bemerkung verkneife ich mir weitere Bemerkungen.

...andere hilfreichere Tips?

Schade, fast hätte ein Reset getrollt, naja vielleicht das nächste mal
Also was lernen wir daraus: nicht alles im Forum glauben und Gegenprüfen, das Internet hält viele Informationen vor
Ein wenig Information über die eingesetzte Umgebung/Software wäre nicht schlecht, Schreenshot, Logs etc... Wenn Ihr schon Schreibfaul seit, dann macht zumindest Screenshots....

 

[mamema]

@Syno-DS welcome to my ignore list!

 

[mamema]

@mihle Danke für die ausführliche Erklärungen.
Bei mir ist es ja etwas anders, da Synology A ein ISCSI LUN von Synology B mountet. Nun meldet Synology A Fehler und ich brauchte ein bisschen, auch Eure Hilfe, um zu merken, dass es sich nicht um ein volume der Synology A handelt.
Nachdem ich nun weiss, dass es sich um Fehler des ISCSI LUN handelt, bin ich noch nicht weitergekommen wie man ISCSI LUNS repariert. Ich hab mal Synology mit Ticket befragt. Antwort ausstehend

 

[Syno-OS]

@mihle Danke für die ausführliche Erklärungen.
Bei mir ist es ja etwas anders, da Synology A ein ISCSI LUN von Synology B mountet. Nun meldet Synology A Fehler und ich brauchte ein bisschen, auch Eure Hilfe, um zu merken, dass es sich nicht um ein volume der Synology A handelt.
Nachdem ich nun weiss, dass es sich um Fehler des ISCSI LUN handelt, bin ich noch nicht weitergekommen wie man ISCSI LUNS repariert. Ich hab mal Synology mit Ticket befragt. Antwort ausstehend

'/dev/isda' ist das Geräte 'Device', vermutlich noch eine Partition '/dev/isda3', dann hängt da eine Nummer, aber mit meinen Schritte findet man es auch heraus, wenn ihr die nicht so macht, dann kann man euch nicht helfen.
@mihle Die Anleitung hilft nur bei einem LVM Gerät/Device. was nicht immer der Fall ist, hilft mamema halt nicht, da iSCSI device andere Namen haben, so auch SAS/SATA/NVMe/iSCSI/LVM/DM/....Alles Linux Block devices. Ein Dateisystem kann auf einem Blockdevice erzeugt werden, Abstraktion ist was schönes


mount | grep volume

Rot: device Name
Grün: Mount punkt

 

[knd2000]

Danke, hat bei mir funktioniert !

 

[docfrantic]

Gutes Neues wünsche ich! Entschuldigung wenn ich den Fred wieder heraus krame. In DSM7 gibts ja kein "syno_poweroff_task" mehr (command not found)!?

Was muss ich über synospace --stop-all-spaces (soll ja der Ersatz für "syno_poweroff_task -d" sein was man so liest oder?) Wissen?

Die Konstellation ist folgende:

Raid6 (mit Datenschutz)
ext4
1x volume1 mit 4x8TB Platten ("/dev/md2").
Zuordnungsstatus: 4x Normal
Zustand: 4x In Ordnung

Die 4x8TB wurden nach und nach gegen die vormals 4x4TB für eine Vergrößerung getauscht. Beim Erweitern sagt mir DSM7:

"Fehler im Dateisystem, bitte versuchen Sie es später erneut. Sollte der Vorgang weiterhin fehlschlagen kontaktieren sie den Synology-Support.".

Ich würde nun gerne via ssh eine Dateisystemprüfung mittels "nohup fsck.ext4 -yvf /dev/md2 &" machen wollen. Die angebotene Dateisystemüberprüfung aus der DSM7 heraus bringt leider keine Abhilfe und eine Erweiterung schlägt mit der selben Fehlermeldung fehl. Daher der Versuch über die Konsole mit vorgenanntem fsck.ext4.

Funktioniert folgendes Vorgehen?:

SSH-Login und sudo -i
cd /
mount |grep volume

/dev/md2 on /volume1 type ext4 (rw,nodev,relatime,journal_checksum,synoacl,stripe=32,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
/dev/sdq1 on /volumeUSB1/usbshare type ext4 (rw,relatime,nodelalloc,journal_checksum,synoacl,data=ordered)

synospace --stop-all-spaces
vgchange -ay
nohup fsck.ext4 -yvf /dev/md2 &
shutdown -r now

Kann mir da jemand bitte helfen?

 

[Syno-OS]

Also damit kann ich nicht arbeiten...
was steht im '/nohup.out'?
Was steht wenn du nach ext4/raid sachen suchst?
'cat /var/log/messages | grep ext'
'cat /var/log/messages | grep md2'

in dem 7 sollte das device nur noch '/dev/mapper/cachedev' sein, wenn das NAS cache support hat, ist bei der RS816 nicht der Fall, daher hier nicht interessant. 'cat /var/log/messages | grep cachedev'