Beiträge von eyetap

    Update:


    Feedback, welches ich auf die Nachfrage, was denn eigentlich gemacht wurde erhalten habe:


    Ich hoffe, dass die Linux Profis damit etwas anfangen können.

    Ich kann am WE noch nachsehen, ob ich etwas in der CLI History finde, vorher komme ich aber wahrscheinlich nicht dazu....

    dass der letzte Snapshot überschrieben wird


    Das war bei mir nicht der Fall… am NAS waren die ja da, sichtbar und verwendbar, nur im Windows war Ebbe.


    Ich werde morgen oder übermorgen mal nachschauen ob in der CLI wirklich was in der History zu finden ist…


    Nachtrag:

    Als admin sehe ich erwartungsgemäß in der CLI History nichts, vom Qnap support user kenn ich das Passwort nicht.

    Solange das Ticket bei Qnap nicht geschlossen ist, möchte ich das auch noch nicht ändern...

    Update: Es scheint als hätte der Support das Problem beheben können - zumindest scheinen wieder Vorgängerversionen in Windows auf.


    Was die Herrschaften gemacht haben kann ich, zumindest derzeit, nicht sagen - ob mir diese Frage beantwortet wird, genauso wie die Frage nach geänderten Einstellungen, wird sich weisen.


    Ich muss aber gestehen dass ich nicht allzu optimistisch bin…


    Wenn ich noch relevante Informationen bekommen sollte werde ich das hier natürlich noch anfügen, ansonsten ist es aber sicher sinnvoll ebenso ein Ticket aufzumachen…

    Das NAS ist bei mir ein doofes Dateisharingdevice - und Änderungen wurden keine vorgenommen- abgesehen von den regelmäßigen FW Updates. Interessanterweise funktionieren die selben Settings auf meinem TS-664 problemlos, auf dem TVS-672x aber nicht.


    Ich hab ein Ticket bei QNAP dazu offen und hatte gestern eine Remotesession mit den Herrschaften- outcome war, dass bei neu angelegten Shares die von QNAP vorgeschlagenen Einstellungen greifen, und dann auch Vorgängerversionen aufscheinen, auf bestehenden aber nicht. Auf dem TS-664 funktioniert das einfach so problemlos….

    Hat die Herrschaften massiv verwirrt, und sie haben gemeint sie müssten das an den T3 Support weiterleiten bzw melden und ich höre von ihnen… ich fürchte ja, dass sie mir dann erklären was ich machen muss, damit es auch auf dem TS-664 nur noch mit den Settings läuft, die vorgeschlagen wurden… ;)


    Naja will see… ich muss aber gestehen mich erinnert die Geschichte an eine ähnliche Situation vor ein paar Jahren , in der mir dann gesagt wurde ich möge das NAS doch einfach neu installieren…

    Das würde ich dann zwar auch noch machen- aber wahrscheinlich nur noch als RSync Ziel für ein Konkurrenzprodukt….

    Hallo Leute,


    Ich stehe momentan an und weiß nicht so recht wie ich weiter machen soll:


    Ich habe gerade festgestellt, dass ich im Windows unter den vorherigen Versionen eines Ordners bzw einer Datei keine Einträge mehr habe.

    Ich habe die Einstellungen wie im QTS 5.0.x User Manual beschrieben geprüft, das sieht gut aus, Snapshots sind vorhanden, eine Wiederherstellung über den Snapshot-Manager ist auch kein Thema - nur im Windows Explorer steht "Es sind keine vorherigen Versionen vorhanden"... :(


    Ich hatte schon versucht sämtliche Snapshots zu löschen, den Zeitplan zu deaktivieren und einen Snapshot manuell neu anzulegen - aber leider ohne Erfolg.

    Nachdem ich hier und hier gelesen habe, dass die gleichzeitige Verwendung von "Erweiterten Ordnerberechtigungen" und "Windows-ACL-Unterstützung" zu Problemen führen habe ich die "Erweiterten Ordnerberechtigungen" deaktiviert und nochmals einen Snapshot angelegt - hat aber auch keine Änderung gebracht... :(


    FW ist die 5.1.7.2770


    Habt Ihr da bitte Tipps?


    Vielen lieben Dank!

    Ich habe ja die 2 HDD's die im KMSG mit einem Disk Failure in Verbindung gebracht wurden ausgetauscht - die werde ich wohl extern testen,

    den Badblock-Test der restlichen HDD's habe ich jetzt mal begonnen.. mal sehen wie lange das dauert...


    Weder der Oberflächen-/Badblocktest der im NAS aktiven HDD's, noch der intensive Test des WD Dashboardtools der ausgetauschten HDD's hat auch nur irgendeinen Hinweis auf ein tatsächliches Problem geliefert.

    Ich kann mir das Verhalten nur noch mit einem Firmwarethema im Zusammenhang mit dieser "Vorhersehbaren Migration" erklären...


    Drive_6_SDB_3.JPGDrive_5_SDB_3.JPGDrive_5_SDB.JPGDrive_6_SDB.JPG

    Ist doch kostenpflichtig.


    Mag sein, dass ich mich nicht korrekt ausgedrückt habe - das hier war eingeschalten:


    pasted-from-clipboard.png


    Was ja Stunde. später dann auch wirklich bei dir passiert ist, hier half ja nur noch abwürgen.

    Was mir trotz allem noch durch den Kopf geht ist, dass ja auch nach dem Abwürgen, Neustart und zu erwartendem Raid Resync im Anschluss noch ein Raid Rebuild stattgefunden hat, welches scheinbar die existierende Hot-Spare HDD in Anspruch genommen hat - aber nachher noch immer alle Platten auf Status OK waren - UND noch immer eine, wenn auch andere, Hot-Spare vorhanden war...


    Wenn ein Rebuild stattfindet, und keine HDD entfernt wurde, hätte ich mir doch erwartet, dass eine HDD als defekt aufscheint...


    Sehe ich das falsch?

    Das können durch den CPU Lock auch Meldungen sein die von einem Software Bug ausgelöst wurden.

    Die HD am PC mal auf SMART Werte prüfen und mit dem WD Tool, sollte hier Klarheit schaffen ob die wirklich ein Problem hat.

    Danke für den Hinweis, das werde ich gerne machen...


    Da hier nur wenige diesen Drive Analyser mit KI Basis verwenden, kann er sogar ursächlich sein. Jetzt hast du aber die Firmware Version geändert und ihn abgeschaltet, damit 2 Parameter geändert.


    Ich hätte diesen Drive Analyzer selbst wahrscheinlich gar nicht aktiviert, ich vermute, dass das einfach mit der Verfügbarkeit automatisch geschehen ist.

    Prinzipiell bin ich kein besonderer Fan davon, wenn so Dinger glauben intelligent sein zu müssen - da bin ich doch eher skeptisch.. und gerade bei einem Raid6 + Hotspare sollte genug Redundanz vorhanden sein um den wirklichen Ausfall einer HDD mal für ein wenig zu überstehen.


    Wegen der 2 Parameter - ja, zum Fehler identifizieren war das sicher nicht die schlaueste Vorgangsweise - allerdings muss ich gestehen, dass wenn das Thema jetzt erledigt ist, liegt mir das fast mehr am Herzen... besonders erpicht bin ich auf einen neuen Absturz nicht wirklich... :/

    Hallo Leute,


    Ich hatte offenbar in der Nacht auf Montag (26.02.2024) auch einen Absturz auf Raten bei meinem TVS-672X (FW 5.1.5.2645 build 20240116 vom 2024-01-25).


    Auf Raten darum, weil


    - nach Mitternacht nichts mehr im Log protokolliert wurde

    - das Backup um 02:30 nicht durchgeführt wurde

    - Snapshots nicht mehr durchgeführt wurden

    - irgendwann ab 05:00 auch keine SNMP Abfragen mehr beantwortet wurden

    - als ich um ~19:00 mich verbinden wollte das nicht mehr möglich war und dann auch keine Pings mehr beantwortet wurden (das dürfe bis dahin der Fall gewesen sein)


    Als ich mir das Gerät dann angesehen habe, hat selbst das LCD Display nichts mehr angezeigt.

    Lange auf den Ein-/Ausschaltknopf zu drücken hat das Teil dann abgewürgt (~19:25), ein Neustart hat dann zu einem Raid-Resync (WD Red pro's, ~3 Jahre alt, Raid 6, 1 Hot Spare) geführt, der kurz vor Mitternacht fertig war.

    Eigentlich hatte ich für die Zeit danach einen Filesystemcheck eingetaktet und für die Zeit nach dem Backup ein Raid-Scrubbing um sicherzustellen, dass wieder ein sauberer Zustand vorherrscht.

    Diese Plattenausfallsvorhersage habe ich dann deaktiviert.

    Interessanterweise hat das Teil aber nach dem Raid-Resync einen Raid Rebuild durchgeführt - wodurch der Filesystemcheck nicht ausgeführt wurde.

    Das Backup und neue Snapshots wurden aber erfolgreich angelegt, das Raid-Scrubbing lief um 3.30 ebenso.


    Ich habe dann am Dienstag, als ich dieses Vorgänge festgestellt habe, den Filesystemcheck ohne Probleme nachgezogen, allerdings hat sich das Hot-spare von Slot 6 auf Slot 5 verändert - also irgendetwas ist da schon geschehen.


    Um potentielle FW-Zusammenhänge auszuschließen, habe ich dann auch auf die neue FW (5.1.5.2679 build 20240219 vom 2024-02-26) aktualisiert - Probleme waren keine zu erkennen.

    Alle Disks wurden als OK angezeigt.


    Nachdem mir das Verhalten aber keine Ruhe gelassen hat, in dem Standard-Eventlog aber nichts zu sehen war, habe ich mir einen Export der Logs, den die Helpdesk-App erzeugt angesehen und bin im kmsg bzw dem offenbar vorherigen gezippten kmsg auf etliche interessante Einträge gestoßen:



    Was ich als relevant erachtet habe, waren die Disk failure Einträge. Nachdem in den Exports auch folgende Info steht:


    Code
    /sbin/qcli_storage -d 
    Enclosure  Port  Sys_Name          Type      Size      Alias             Signature   Partitions  Model  
    NAS_HOST   1     /dev/sde          HDD:data  1.82 TB   3.5" SATA HDD 1   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   2     /dev/sdd          HDD:data  1.82 TB   3.5" SATA HDD 2   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   3     /dev/sdc          HDD:data  1.82 TB   3.5" SATA HDD 3   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   4     /dev/sdf          HDD:data  1.82 TB   3.5" SATA HDD 4   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   5     /dev/sdb          HDD:spare 1.82 TB   3.5" SATA HDD 5   -- FLEX     5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   6     /dev/sda          HDD:data  1.82 TB   3.5" SATA HDD 6   QNAP        5           WDC WD2002FFSX-68PF8N0
    NAS_HOST   7     /dev/nvme0n1      SSD:cache 476.94 GB M.2 PCIe SSD 1    QNAP FLEX   5           Samsung SSD 970 PRO 512GB
    NAS_HOST   8     /dev/nvme1n1      SSD:cache 476.94 GB M.2 PCIe SSD 2    QNAP FLEX   5           Samsung SSD 970 PRO 512GB


    Habe ich Dienstag Abends zuerst das Laufwerk im Slot 5 ersetzt (sdb, also neues Hot-Spare) und im Anschluss das im Slot 6 (sda).

    Raid Rebuild lief gut durch, auch sonst konnte ich bisher keine Fehler feststellen.


    Was mich aber massiv irritiert ist, dass bei einem Ausfall einer Platte doch bitte


    - eine entsprechende Meldung im Eventlog zu finden sein sollte

    - ein Raid 6 mit Hot-Spare zwar temporär degraded sein wird, aber sonst wohl eher unbeeindruckt sein sollte

    - im Anschluss an die ganze Übung bitte doch nicht alle Platten als OK klassifiziert sein sollten

    - folgender Eintrag im kmsg doch schräg aussieht (kam im übrigen mehrfach vor):


    Code
    2024-02-26 02:01:38 +01:00 <0> [2480337.338751] watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [md1_raid6:6585]


    oder sehe ich das falsch?


    Ach ja - die Platte SDB habe ich im Anschluss am PC (USB) mit diskpart :arrow: clean all gelöscht - ohne irgendwelche Probleme.


    Wie seht Ihr das?


    Vielen lieben Dank für eure Meinung!

    Habe jetzt auch meine NASen (TS-653A, TS-664, TVS-672X) auch von 5.1.3.2578(20231110) auf 5.1.4.2578(20231128) aktualisiert.


    Bis dato keine Unanständigkeiten bemerkt, ich denke, dass alles in Ordnung ist.


    Auch der Zugriff über den QManager von iOS (17.2) auf das TVS-672X hat (im Gegensatz zu 5.1.3.2578(20231110) / iOS (16.x)) zu keiner Warnung "Login Fail" mehr geführt (HTTP).

    Habe jetzt auch meine Sammlung (TS-653A, TS-664, TVS-672X) von 5.0.1.2514(20230906) auf 5.1.3.2578(20231110) aktualisiert.

    Bis dato konnte ich keine wesentlichen Probleme feststellen (sind aber alles lediglich reine Datenablagen)

    Auch das Backup mit der HBS 3 Hybrid Backup Sync V23.1.1116 auf ein lokales USB Laufwerk sowie ein über RTR angebundenes TS-669 Pro lief ohne Fehler duch.


    Die einzig obskure Beobachtung die ich gemacht habe war, dass beim Zugriff über den QManager von iOS (16.x) auf das TVS-672X zu einem Warning "Login Fail" geführt hat (HTTP).

    Das Passwort habe ich aber auf der App in der letzten Zeit nicht geändert - lustigerweise hat der Zugriff auch funktioniert.

    Reproduzierbar war dieses Verhalten bis dato auch nicht - möge das so bleiben...

    Hallo Leute,


    Ich würde mir gerne durch NC eine Mail senden lassen, wenn im Zugriffsprotokoll Warnings oder Errors geloggt werden.

    Während das für das Ereignisprotokoll recht simpel geht und funktioniert, habe ich keine Ahnung wie ich das für das Zugriffsprotokoll hinbekomme.

    Der Alert Notification, die sonst bei Warnungen und Fehlern (kein Filter) tadellos macht, ist das Zugriffsprotokoll herzlich egal...


    Habt ihr da einen Tipp?


    Danke!

    Habe meine Devices (TVS-672X, TS-664) jetzt auch von 5.0.1.2277 auf 5.0.1.2346 aktualisiert, die Beobachtung von Becker2020 bzgl der Systemlüfter kann ich bestätigen, das gleiche habe ich auf sämtlichen Geräten gesehen.


    Auf meinem TS-664 fällt mir seither auf, dass der Prozess drawPic laufend so bei 16% CPU Last liegt. (keine Virtualisierung am laufen, kein HDMI Gerät angeschlossen, nur Standard-Apps installiert)


    pasted-from-clipboard.png


    Das nervt etwas - falls jemand eine Idee hat wie das zu fixen geht würde ich mich freuen...