Nachdem zumindest auf einem meiner NAS die FW 20180504 floppte (ständig reboots, siehe hier), gibt es jetzt auch eine
Version 20180531.
Mit dem Update warte ich aber etwas... 
.
Die Taktzahl der FW Updates ist schon irritierend, vor allem wenn so aussagekräftige release Angaben vorhanden sind:
Zitat[Fixed Issues]
- Fixed some minor issues.
Gruss
Ich habe meine nicht mehr unterstützten NAS'en sogar noch extra downgegradet und nicht mal die offiziell letzte Version verwendet.
Was soll ich sagen, ich sitze völlig entspannt da, freue mich, dass die NAS schneller als zuvor läuft und bin über jedes Update froh, das ich nicht mache 
Also sprach Zarathustra:
Auch diese FW ist Mist! Ich habe sie heute doch auf beiden NASen installiert (eines nach dem anderen) und sofort nach dem Update verweigerten alle RTRR Jobs ihren Dienst,
"[RTRR Job] (Sync) Job myfolder-->Remote:myfolder failed: Bad port number or the service is not available!. Begin the 1st retry." ist dazu im Log vermerkt.
Downgrade per QFinder parallel wieder auf build 20171208 durchgeführt und schon funktioniert alles wieder!
Was macht QNAP da? Testet man nicht mal mehr die einfachsten Sachen!??
Und noch etwas ist mir aufgefallen: nach einem sporadischen Reboot geht der Filesystem-check nicht mehr, er endet immer mit "cannot unmount Volume - Examination failed"!
Lösen kann man in dem man per CLI alle Dienste beendet und die übrig gebliebenen Jobs per kill ins Nirwana schiesst, dann kann man per GUI den Check ausführen, ob das so im Sinne des Erfinders ist?
Ich habe den Eindruck das ein/e Dienst/App nicht korrekt terminiert werden kann und deshalb der umount fehlschlägt, nur welche/r?
Und das finde ich auch spannend: der Check auf CLI Ebene geht auch nicht:
[~] # e2fsck -f -v -C 0 /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
/dev/md0 has unsupported feature(s): 64bit
e2fsck: Get a newer version of e2fsck!
[~] # Diese Version ist uralt, warum ist da nichts aktuelleres dabei? Im Netz findet man diese Meldung seit Jahren(!) und QNAP bringt es nicht fertig das aktuell zu halten?
Gut, das als Nebenkriegsschauplatz, aber die Sache mit den RTRR Jobs ist einfach nur zum 
...
Kommt denn überhaupt keine vernünftige FW mehr...?
Danke, peinlich 
, die wildcard (*) bei der Suche nicht benutzt...
Mit * findet man auch ..._64
Gruss
Ich kann das nur bestätigen, sowohl bei den 32- als auch bei den 64-Bit Systemen. Sobald mir ein NAS verreckt, werde ich mal auf ein Konkurenzprodukt wechseln, um zu sehen, ob das dort mit der immer schlechter werdenden Qualität der Firmware auch so ist.
Ich empfehle Selbstbau und freie Software. Da hat man so Probleme nicht.
Das war es dann wohl...
Ein QNAP war vorgestern nicht mehr administrativ zu erreichen, Web GUI liess sich nicht mehr aufrufen, aber die CLI ging noch. Es lief alles noch, Jobs, Shares, Datenzugriff war in Ordnung, nur von einem Moment auf den anderen kein Zugriff mehr, das habe ich dann per CLI neu gestartet, danach ging auch wieder die Web GUI. Verusche über die CLI die Dienste neu zu starten (erst nur den Apache, dann alle, waren nicht erfolgreich, die GUI blieb nicht zugreifbar.
Das zweite fängt aber seit Freitag dem 13 (!??) wieder an zu spinnen.
Das lief vorher 3 Wochen ohne Zicken zu machen (am 24./25.06. habe ich es neu aufgesetzt).
Am Freitag war ich noch im Urlaub, auch am Samstagmorgen war ich nicht vor Ort. Es hat sich in dieser Zeit nichts geändert, kein neuer Job, zu dieser Zeit lief auch keiner, keine Ahnung warum jetzt die Reboots wieder los gehen. Am Samstag gab es sogar innerhalb einer Stunde zwei Reboots!
Nur: der Frust Faktor steigt wieder stark an. Was macht QNAP da? Angefangen hat das alles mit der FW vom 04. Mai, davor hatten alle QNAPs eine Uptime von ca. 120 Tagen, also keine Probleme.
Nur: wenn ich auf die alte FW zurückgehe besserte sich das Verhalten dadurch nicht mehr. Und die Logs sind auch nicht aussagekräftig, das das System nicht regulär heruntergefahren wurde ist selbsterklärend, aber wodurch?
So langsam denke ich tatsächlich über Alternativen nach...
Gruss
die Logs sind auch nicht aussagekräftig, das das System nicht regulär heruntergefahren wurde ist selbsterklärend, aber wodurch?
Diese Logeinträge werden erst nach dem Neustart geschrieben, da weiß das NAS natürlich nicht mehr, warum es "aus" ging.
Solche Einträge kenne ich von meinen NAS'en auch (keine aktuelle FW ). Bei mir kommen sie allerdings nur wenn ich die NAS'en stromlos setze, quasi force-shutdown, oder banaler gesagt, Stromausfall …
Das kannst du bei dir ausschließen?
Meist reichen schon minimale "Zucker" von einigen ms, dass einige Geräte abstürzen, andere flimmern nicht mal ...
Treten diese Reboots vielleicht bei großer Last z.B. Sicherung von Dateien auf ein anderes NAS od. ähnlichem auf ?
Alle NASen hängen an einer USV, oder genauer: An jeder USV hängen 2 NASen, wobei die beiden TS859 nicht an der selben hängen. Und bisher sind es immer nur die beiden 859 die Zicken machen.
Am Celvin oder am TS459 ist das noch nie aufgetreten, z.B. das Celvin:
Und die Uptime ist auch nur 156 Tage weil ich die USV Batterien tauschen musste. Die beiden 859 waren bis zu diesem Zeitpunkt mit der Uptime fast identisch.
Erst mit dem Update im Mai ging es dann los, und seitdem werde ich es offenbar nicht mehr los (die Reboots).
Gruss
Hmm, die 859'er, da hast du die 4.2.6'er FW drauf?
Meine mich erinnern zu können, dass ich mit der 4.2.6 nie glücklich wurde und die letzte "vernünftige" die 4.2.5 war … probier mal eine ältere, vielleicht die 4.2.3.
Wobei ich aus performancegründen sogar wieder ganz zur alten 4.1.4 zurück bin … so entspannt und sorglos liefen sie nicht mal, als sie neu waren
Hmm, die 859'er, da hast du die 4.2.6'er FW drauf?
Hab ich auf der 459 auch drauf. pasted-from-clipboard.png
