Monit-Alert: Filesystem flags changed Service (Openmediavault)

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Ich habe mir mit meinem Raspberry PI und Openmediavault ein NAS gebaut. Für etwa 14 Tagen lief alles problemlos.

    Seit ein paar Tagen erhalte ich jedoch folgende Fehlermeldung, und habe folgedessen dann kein Zugriff auf meine Daten.

    Filesystem flags changed Service filesystem_srv_dev-disk-by-label-INTENSO
    Date: Sat, 04 Jan 2020 ...
    Action: alert
    Host: raspberrypi
    Description: filesystem flags changed to 0x1009

    Your faithful employee,
    Monit

    Nach einem Neustart funktioniert wieder alles (für 1-2 Tage).

    Hier sind ein paar Informationen:

    Raspberry Pi Model B 4GB

    openmediavault 4.1.30-1

    1 TB USB 3.0

    Im Voraus vielen Dank für Eure Hilfe.

  • Monit-Alert: Filesystem flags changed Service (Openmediavault)? Schau mal ob du hier fündig wirst!

  • Möglicherweise hast Du beim Bauen des NAS auf ein fsck der NAS Partition vergessen.

    Hallo. Danke für die Antwort.

    Um den Check durchzuführen, habe ich das mit Benutzer root eingegeben. Da die Partition gemountet ist, kommt folgender Fehler:

    root@raspberrypi:~# fsck

    fsck from util-linux 2.29.2

    e2fsck 1.43.4 (31-Jan-2017)

    /dev/mmcblk0p2 is mounted.

    e2fsck: Cannot continue, aborting.

    Wird das funktionieren, wenn ich das so eingebe (sorry, Linux ist ziemlich neu für mich):

    unmount /dev/mmcblk0p2

    fsck /dev/mmcblk0p2

    mount /dev/mmcblk0p2

  • fsck funktioniert nicht am rw gemounteten Device

    fsck ist nur ein frontend und greift auf das eigentliche Checkprogramm des Filesystems zurück

    e2fsck ist das Checkprogramm für EXT2, EXT3, EXT4 Filesysteme

    e2fsck -p wird von fsck verwendet und repariert nur Fehler, die sicher, ohne manuellen Eingriff, gefixt werden können.

    < man e2fsck > zeigt weitere Details.

    umount /dev/mmcblk0p2 hängt das root-Filesystem aus

    Damit kann auch keine Datei/Programm vom root-Filesystem mehr gelesen werden und fsck versagt.

    /dev/mmcblk0p2 wird aber sowieso bei jedem Bootprouess gecheckt.

    Dein Problem ist das INTENSO Laufwerk.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Moin Gand58,

    erstmal: Herzlich Willkommen im Forum!

    Wenn du dich in OMV anmeldest und auf der linken Seite "Systeminformationen" auswählst und "Report" anklickst, dann erscheint eine Liste.

    Dort mal nach Monit status suchen. Vielleicht steht da ja mehr zu der Meldung drin.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Moin Gand58,

    erstmal: Herzlich Willkommen im Forum!

    Wenn du dich in OMV anmeldest und auf der linken Seite "Systeminformationen" auswählst und "Report" anklickst, dann erscheint eine Liste.

    Dort mal nach Monit status suchen. Vielleicht steht da ja mehr zu der Meldung drin.

    73 de Bernd

    Danke für die Willkommensgrüße :)

    Da habe ich nachgeschaut. Nachdem das System heute vormittag erst neu hochgefahren wurde, stehen da sonst keine weiteren Details.

    Ich denke spätestens morgen kommt wieder dieser Fehler, dann werde ich da nochmal nachschauen. Vielen Dank für den Tip.


    umount /dev/mmcblk0p2 hängt das root-Filesystem aus

    Damit kann auch keine Datei/Programm vom root-Filesystem mehr gelesen werden und fsck versagt.

    Dein Problem ist das INTENSO Laufwerk.

    Danke für den Hinweis - ich weiß gar nicht mehr wie ich auf diese Bezeichnung gekommen bin ... dann wäre es richtig:

    unmount /dev/sda1

    e2fsck -p /dev/sda1

    mount /dev/sda1

    Soll ich das mal so ausführen?


    Das Intenso-Laufwerk (Seagate ST1000LM024) ist ca. 7 Jahre alt, hat aber bisher keine Probleme gemacht.

    Wird das Laufwerk defekt?

  • Wenn es ein EXT4 Filesystem ist, ja.

    Du kannst auch weitere Optionen, wie verbose, force checking, badblocks usw. laut < man e2fsck > verwenden,

    Und nicht unmount, sondern umount. Und alles als User root.

    Ja, die Festplatte hat das Format ext4.

    Habe den Befehl nun so ausgeführt:

    root@raspberrypi:~# umount /dev/sda1

    root@raspberrypi:~# e2fsck -p /dev/sda1

    /dev/sda1 is mounted.

    e2fsck: Cannot continue, aborting.

    Fehlt beim umount evtl. noch ein Parameter? Was mache ich falsch?


    Es gibt auch im OMV die Option "Aushängen" unter Datenspeicher\Dateisysteme. Beim Auswählen der /dev/sda1 bleibt der Button auch grau ...

  • Was passiert (ist die Ausgabe) mit

    Code
    sudo umount -v /dev/sda1

    oder

    Code
    sudo umount -v /Pfad/zum/Mountpiont

    ?

    Soweit kommt ich jetzt nicht mehr, es kommt folgende Meldung (auch bei umount /dev/sda1)

    umount: /srv/dev-disk-by-label-INTENSO: target is busy

    (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)

  • Da greift vermutlich ein privilegierter Prozess noch auf die /dev/sda1 Partition zu.

    Du kannst umount mit allen erlaubten Parametern [laut umount -h, oder man umount] aufrufen, einschliesslich verbose und force.

    Ein mount kann aber auch daran scheitern, dass /etc/mtab schon fehlerbedingt gelockt wurde. Dann existiert neben /etc/mtab ein weiteres File wie /etc/mtab.lock, oder so ähnlich.

    Am einfachsten setzt Du das sechste Feld des /etc/fstab Eintrages von 0 auf 2, wie es in < man fstab > beschrieben ist. Dann kannst Du in den Logfiles nachsehen, ob e2fsck -p beim Booten erfolgreich war.

    Servus !


    Aha, jetzt kommt ein ungewöhnlicher Mountbefehl ins Spiel. Zeig mal die Zeile aus /etc/fstab

    RTFM = Read The Factory Manual, oder so

    2 Mal editiert, zuletzt von RTFM (6. Januar 2020 um 01:35)

  • Wahrscheinlich blockiert samba :)

    Diese Programme können gekillt werden.

    Man kann die Programm so finden

    sudo lsof|grep "Einhängepunkt"

    Bei mir ist z.B /dev/sda2 auf /mnt eingehängt

    sudo lsof|grep /mnt

    ergibt ein liste mit truecrypt

    truecrypt 1648 root 4u REG 8,3 11811160064 12 /mnt/.CONTAINER

    hier müsst ich jetzt das eingeben: sudo kill -9 1648

    Das so oft wiederholen bis umount von nichts mehr blockiert wird :)

    Ahso: sudo e2fsck -y -f -C 0 /dev/sda2

    so wird auf Fehler geprüft und repariert, das -C 0 ist wie in gpartet für die Fortschrittanzeige. e2fsck ist für extX filesystem. Wenn es NTFS sein sollte, müsste man es fast schon mit Windows überprüfen, es gibt auch für Linux ein Befehl.

    2 Mal editiert, zuletzt von det_lev_da (4. Januar 2020 um 21:39)

  • Am einfachsten setzt Du das sechste Feld des /etc/fstab Eintrages von 0 auf 2, wie es in < man fstab > beschrieben ist. Dann kannst Du in den Logfiles nachsehen, ob e2fsck -p beim Booten erfolgreich war.

    Hier die Systemtabelle (pass ist bereits auf 2):

    Das heisst ich muss neu booten und wo muss ich was dann genau prüfen?

    det_lev_da Das werde ich morgen mal probieren. Danke für die erweiterten Aufruf von e2fsck()


    ... und was heisst jetzt eigentlich die Meldung "filesystem flags changed to 0x1009"?

  • Wenn e2fsck -p beim Booten schon ausgeführt wird (pass=2), dann kann der dedektierte Fehler automatisch nicht sicher repariert werden. Dann sollte aber auch in den Logfiles ein (Warn-)Hinweis eingetragen sein.

    Ein Filesystem hat viele Flags. Die bekanntesten sind r-w-x, aber auch alle anderen attributes und extended attributes. Im EXT4 Filesystem Superblock (Header) findest Du einen Teil davon.<tune2fs -l /dev/sda1>

    Was 0x1009 bedeutet, weiss ich nicht. Da müsstest Du in den Soucen von Openmediafault nachsehen, Es ist auch möglich, dass die Platte voll wird, oder auch nur alle I-Nodes, oder alle Sektoren verbraucht sind. Das siehst Du im ausgegebenen Superblock.

    Sonst bin ich mehr auf Raspbian/Debian und Linux allgemein aktiv. Wieweit man in Openmediafault herumkonfigurieren kann, weiss ich nicht.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Moin Gand58,

    konntest du, im Fehlerfall, schon nach den Einträgen schauen?

    Wenn du dich in OMV anmeldest und auf der linken Seite "Systeminformationen" auswählst und "Report" anklickst, dann erscheint eine Liste.

    Dort mal nach Monit status suchen. Vielleicht steht da ja mehr zu der Meldung drin.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Hallo. Heute vormittag hatte ich nun wieder die Fehlermeldung filesystem flags changed to 0x1009.

    Nach vielem hin- und herprobieren konnte ich nun endlich e2fsck() ausführen: 

    • Plex-Server im OMV beendet
    • sudo umount -v /dev/sda1
    • sudo e2fsck -y -f -C 0 /dev/disk/by-label/INTENSO

                   

    • Per OMV wieder eingebunden

    Sieht so aus als ob einiges repariert wurde ... mal schauen, wie lange es jetzt wieder geht.

    Im Syslog von OMV konnte ich zur dem Zeitpunkt wo der Fehler mir per Mail zugesendet wurde folgende Zeilen entdecken:


    @ALLE Danke für die nützlichen Tips

  • Heute, Donnerstag ist der Fehler wieder gekommen.

    Hat noch jemand eine Idee?

    Ist schlicht und einfach die Festplatte defekt?

    Nach Klick auf Einbinden im OMV ist der Datenträger jedoch wieder erreichbar ...

  • Habe heute über Stunden den "S.M.A.R.T. extended self-test" des Tools HDDSCAN ausgeführt -> completed wihtout error

    ich habe jetzt mal einen 4GB USB-Stick angesteckt, mal schauen was passiert. So ein Drecksding.

  • Das Drecksding

    meldet einen Fehler beim Inode 21757956

    versucht eine check/repair über das Journal

    kann aber nicht, weil das Journal vorher abgebrochen/beendet ist

    deshalb wurde das Filesystem auf nur lesen gemountet

    Das ist meine Interpretation des Logs.


    Servus !

    RTFM = Read The Factory Manual, oder so

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!