(2017) The file system is not clean. It is suggested that you go to [Storage Manager] to run "Check File System".

    Hallo QNAPCLUB,


    im November 2015 gab es bereits einmal ein Thema dieser Art. The file system is not clean. It is suggested that you go to [Storage Manager] to run "Check File System".


    Unter anderem wurde insbesondere von zwei Fixes berichtet. Dann endet das Forum und die Probleme scheinen gelöst. Ich habe jedoch nun in 2017 exakt das gleiche Problem: ich lasse mein NAS TS-431 jede Nacht herunterfahren und morgens wieder starten - und bekomme jeden Tag die identische Fehlermeldung bzgl. "File System is not clean...". Ein anschließender Check (schnell als auch umfassend) liefert jedoch keinen Hinweis auf einen Fehler der (ein Jahr alten) Festplatten. Diese sind zwei HGST HDN724040ALE640 (SATA). Sonst läuft alles einwandfrei. In meiner aktuellen Firmware-Version 4.3.3.0238 Build 20170703 müssten die angesprochenen Fixes doch auch längst enthalten sein.


    Hat jemand eine Idee? Oder kann ich diesen Fehler einfach ignorieren? Kann es schaden, diese Meldung einfach zu ignorieren? ?(


    Wäre über jede Hilfe dankbar.


    Viele grüße,
    Michael

    Bei meinem TS-251 ist es genau das gleiche Problem ?( Ich kann das Gerät NICHT mehr in den Ruhemodus S3 (Sleep) versetzen (egal ob manuell oder übern Zeitplan). Sobald ich auf "Ruhemodus" drücke, lädt das NAS und startet einfach neu!


    Nach dem Hochfahren erscheint jedes Mal folgende Meldung:
    S3_restart_error.JPG


    Firmware-Version: 4.3.3.0238 Build 20170703

    Wo finde ich diese Logs? In den Systemprotokollen unter Systemereignisprotokollen finde ich jedenfalls nichts dergleichen...
    Falls das etwas mit Linux zu tun hat, hier bin ich bisher völlig außen vor...

    Zitat von Hubert00

    Bei meinem TS-251 ist es genau das gleiche Problem Ich kann das Gerät NICHT mehr in den Ruhemodus S3 (Sleep) versetzen (egal ob manuell oder übern Zeitplan). Sobald ich auf "Ruhemodus" drücke, lädt das NAS und startet einfach neu!

    Mit der 4.3.3.0262 build 20170727 fährt das NAS nun zwar in den Ruhemodus, wacht aber SOFORT wieder auf. Sendet Qsync oder andere Dienste MagicPakete ??? (Wenn ich WOL deaktiviere schläft es weiter)
    Hatte es sonst immer länger im Ruhemodus, nur da nutzte ich noch kein Qsync, deswegen vermute ich das als Ursache.


    EDIT:
    Es sieht tatsächlich danach aus, dass Qsync das NAS mit MagicPaketen befeuert ohne Ende. Nach dem Deaktivieren von Qsync schläft das NAS im Ruhemodus normal weiter...

    Ich muss jetzt dieses veraltete Thema nochmal aufgreifen.


    Immer wieder - mal häufiger, mal seltener, manchmal lange Zeit gar nicht - fordert mich mein NAS nach einem Reboot zum Prüfen des Dateisystems auf. Das ist lästig, kommt aber meist zu recht unpassenden Gelegenheiten, mal richtig danach zu recherchieren. Jetzt bin ich aber doch mal etwas intensiver der Sache nachgegangen und fand den Hinweis auf die .force_kill_in_shutdown.log

    Und tatsächlich werden dort nahe des Endes zwei Skripte aufgeführt, die ich zwar selber mal gestartet (vor vielen Jahren), seither aber komplett aus den Augen verloren habe - sie laufen eben so vor sich hin. Konkret schreiben sie daten aus dem SmartHome in eine Datenbank - sollte aber nicht wichtig sein. Ich vermute, dass es diese beiden Skripte sind, die den sauberen Reboot oder Shutdown stören.


    Nun die Frage: Gibt es ein Gegenstück zur Autostart, die sozusagen beim Shutdown/Reboot vor dem eigentlichen Herunterfahren zuallererst durchgeführt wird, wo ich dann diese beiden Skripte gezielt erst beenden könnte? Oder ist das vollkommender Quatsch?

    Es gab zumindest mal ein Script, in dem man auch Einträge für einen Shutdown machen konnte, so daß die dort eingetragenen Dienste gestoppt wurden.

    Ich habe dieses Script aber nur mit Starteinträgen benutzt, musst Du also selbst testen.


    Gruss

    Einmal editiert, zuletzt von FSC830 ()

    Gefällt mir 1

    Alles klar, besten Dank.

    Bei diesen Skripten hatte ich nur die Befürchtung, dass sie nach einem Update wieder zurückgesetzt werden. Aber Du hast recht: muss ich selber testen.

    Nein, meine autorun.sh hat bisher jedes Update überstanden.

    Das Testen bezog sich auf die Shutdown Einträge, die habe ich bisher noch nie benutzt.


    Gruss

    Einmal editiert, zuletzt von FSC830 ()

    Gefällt mir 1

    ? Irgendwie reden wir glaube ich aneinander vorbei.

    In dem verlinkten Script kannst Du doch Befehle eingeben, die bei einem Shutdown ausgeführt werden sollen!?

    Was suchst Du nun noch?


    Gruss

    Nichts. Aber ich weiß eben nicht, ob Einträge in einer Datei in /etc/... nach Reboot oder ehr nach Update erhalten bleiben.

    Zitat von kasimodo

    Da man keine Dateien oder Symlinks bootfest unter /etc anlegen kann muss dieser Symlink in /etc/rcK.d bei jedem booten vom NAS neu angelegt werden damit der beim Runterfahren vorhanden ist! Dies kann man mit "autorun.sh" beim Booten realisieren!

    Steht doch im verlinkten Thread drin.


    Gruss

    Kannst Du doch auch testen: Scripte anhalten, Shutdown und Restart durchführen und schauen, ob die Meldung wieder erscheint.


    Gruss

    Klingt schon logisch - solange man die Randbedingungen nicht kennt. Ein erfolgloser Test kann bei aber schon auch ein Resync des RAID bewirken, der sich dann Tage hinzieht. Daher verzichte ich gerne mal auf das einfach mal probieren ...

    Vielleicht erst der Grund, warum ich zweifle:

    Die Datei .force_kill_in_shutdown.log hat das Datum 28.08.2021. Damals gab es auch tatsächlich einen unerwarteten Neustart, derartiges ist also nicht verwunderlich. Aktuell hatte ich aber am vergangenen Sonntag, also am 05.09.2021 das System korrekt über den Browser komplett heruntergefahren. Und auch danach musste auf den Volumes teilweise das Filesystem geprüft werden, auch ein RAID-Resync läuft jetzt deswegen.


    Sowas gab's früher bei früheren FW-Versionen schon ab und an, dann war aber lange Schluss. Erst jetzt, seit der 4.5.xx tritt es wieder häufiger auf. Wahrscheinlich komme ich nicht drum herum, über ein komplettes Neuaufsetzen ernsthaft nachzudenken. Das kann ich mir aber leider aktuell zeitlich nicht leisten.


    Ich habe mir aber (ich weiß, gewagt als Dummie) die EVENT_LOG angesehen, und dort finde ich vom Sonntag Mittag, also während des kompletten Herunterfahrens folgenden Eintrag, der mir nicht wirklich nach vollständigen, korrektem Herunterfahren klingt.

    Code
    2021-09-05 12:31:07 +02:00 <4> [408561.818809] shutdown hung & force shutdown
2021-09-05 12:31:07 +02:00 <6> [408562.152707] sysrq: SysRq : Emergency Sync
2021-09-05 12:31:10 +02:00 <6> [408565.158258] sysrq: SysRq : Emergency Remount R/O
2021-09-05 12:45:40 +02:00 <6> imklog 4.4.2, log source = /proc/kmsg started.

    Einmal editiert, zuletzt von duke-f ()

    Zitat von duke-f

    Aktuell hatte ich aber am vergangenen Sonntag, also am 05.09.2021 das System korrekt über den Browser komplett heruntergefahren. Und auch danach musste auf den Volumes teilweise das Filesystem geprüft werden, auch ein RAID-Resync läuft jetzt deswegen.

    Wenn nach dem 28.08. kein check durchgeführt wurde, dann ist das nicht verwunderlich. Der check wird solnage angemahnt, bis er einmal durchgeführt wurde.


    Gruss

    Zitat von duke-f

    Ich habe mir aber (ich weiß, gewagt als Dummie) die EVENT_LOG angesehen, und dort finde ich vom Sonntag Mittag, also während des kompletten Herunterfahrens folgenden Eintrag, der mir nicht wirklich nach vollständigen, korrektem Herunterfahren klingt.

    Ich würde sagen, diese Einträge dürften dann doch ein Fall für den Support sein.