Fast problemlos von der QTS 5.0.1.2277 upgedatet. Kurz nach dem Start war der Systemlüfter fehlerhaft. Hatte ich noch nie.
2 Minuten später war wieder alles grün.
Das erste Mal seit QTS 5.0.1.2194, dass das automatische Update wieder funktioniert hat.
QTS und Qfinder Pro haben das Update angezeigt
Kurz nach dem Start war der Systemlüfter fehlerhaft.
Hatte ich auch schon mal beobachtet, wenn ich mich "zu früh" eingeloggt habe. Auch mit der 2277. Ging dann zeitnah weg
Und dann hätten die Hacker bis zur Schließung der Lücke Zeit diese auszunutzen.
Und Admins die Chance, etwas dagegen zu unternehmen, sofern möglich (und das ist es immer, egal wie hart die Maßnahme ist).
Lücken erst bekannt zugeben - an den Endbenutzer, wenn es den Fix dazu schon gibt.
Die CVEs gibt es aber teils schon länger und die bösen Buben könnten damit (überall) ihr Glück versuchen, denn die haben da ein Auge drauf... ich nicht.
Nach der Veröffentlichung des Fixes kann man ja nicht mehr anders
Das verstehe ich nicht... mache aber anders weiter:
... und dann sind diejenigen, die ihr System nicht stets bzgl. Updates im Blick haben gefährdet (der Theorie her nun so richtig gefährdet). Klar: Schuld dem, der seine Systeme nicht im Blick hat; das hat QNAP berücksichtigt und auto-Updates eingeführt... von denen wir hier vehement abraten... den Schuh müssen wir uns dann anziehen 
Aber ich will auch ehrlich sein:
Ich bin kein IT-pro, erst recht nicht, was Sicherheit angeht. Ich kann in den meisten Fällen entsprechend ohnehin nicht viel mit den Informationen zu einer Lücke anfangen, aber dazu wird ja vom betroffenen Entwickler zu Maßnahmen geraten (jedenfalls in meiner Vorstellung). Eine genannte Maßnahme, die erst mit dem soeben erschienen Update möglich ist, empfinde ich daher als nicht korrekt. Auf (manche) QNAP User wirkt das (vor allem in dem Fall mit 4 oder 5 solcher Warnungen) wie ein Zwang zum Update... und wie das ausgehen kann wissen viele von uns bestens und raten daher abzuwarten. Mehr Konflikt geht bei User doch nicht... aber schon wieder unser Schuh 
das hat QNAP berücksichtigt und auto-Updates eingeführt... von denen wir hier vehement abraten... den Schuh müssen wir uns dann anziehen
Wir raten aber noch vehementer davon ab, das NAS offen ins Internet zu stellen. Würde dies auch berücksichtigt werden, wäre alles kein Problem. Die Wahrscheinlichkeit, dass dem NAS etwas passiert, ohne dass die aktuellste Firmware installiert ist, ist bei einem nicht offenen NAS doch eher gering, Die Wahrscheinlichkeit mit aktueller Firmware bei offen NAS etwas einzufangen dürfte um ein Vielfaches höher sein, als bei nicht geöffnetem NAS mit uralt Firmware.
Deshalb steht bei mir kein NAS offen im Internet und meine privaten Backup NAS sind in einem physisch getrennten Netzwerk ohne Internet.
Das verstehe ich nicht... mache aber anders weiter:
Eigentlich will man ja gar keine Informationen über Sicherheitslücken ins Internet stellen. Jede Information darüber bietet auch dem Angreifern zusätzliche Informationen.
Unterm Strich finde ich es gut so wie es QNAP macht, eben so oder so ähnlich, wie es andere Hersteller auch machen, weil es eigentlich nicht groß viel andere Möglichkeiten gibt. Natürlich sind die CVE Security Meldungen oft schon viel früher draußen, aber da weiß ja noch niemand, ob die für das jeweilige System anfällig sind oder nicht. Dies herauszufinden kostet Zeit. Zeit die der Hersteller zum Fixen braucht. Nicht jede Linux CVE ist automatisch eine Anfälligkeit für QTS.
Weil ich gerade darüber gestolpert bin:
Informationen zu Apple-Sicherheitsupdates
Zum Schutz unserer Kunden werden Sicherheitsprobleme von Apple erst dann bekannt gegeben, besprochen und bestätigt, wenn eine vollständige Untersuchung stattgefunden hat und alle erforderlichen Patches oder Programmversionen verfügbar sind.
Na gut überzeugt. Das Vorgehen ist üblich und durchaus zu legitimieren. Wirklich gut finde ich es trotzdem nicht und sehe uU durchaus mehr Gefahrenpotential dadurch entstehen als vermieden wird (sofern temporäre Ersatzmaßnahnen getroffen werden können).
Jedenfalls bin ich besänftigt und ärgere mich nicht mehr darüber bzw. bin nicht mehr verwundert / verunsichert.
Manchmal muss man die Welt halt so nehmen, wie sie ist 
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)
Das nervt etwas - falls jemand eine Idee hat wie das zu fixen geht würde ich mich freuen...
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)
Das gibts schion in einem separaten Topic hier: "drawPic Prozess verbraucht konstant CPU Power". Am besten auch ein Ticket bei Qnap aufmachen wie der Rest der betroffenen. Umso größer ist die Chance, dass es schnell gefixt wird.
bzgl der Systemlüfter kann ich bestätigen, das gleiche habe ich auf sämtlichen Geräten gesehen.
der Wert 4.2xxx... Millarden ist 0xffff ffff im Doppelwort (32Bit) unsigned. Da würde ich von ausgehen, dass die Lüfterdrehzehl nach Neustart noch nicht synchronisiert wurde.
eyetap :Wird da nicht nach einiger Zeit der korrekte Wert angezeigt? Oder ist das permanent so? Dann wärs ein Bug
Wird da nicht nach einiger Zeit der korrekte Wert angezeigt?
Ja. Ist nur ein kosmetisches "Problem"...
Nun ja, das NAS hat ja nach Neustart ein paar Sachen zu erledigen. Bei mir dauerts z.B.auch einige Zeit, bis am USB die USV erkannt wird. Die Hochlaufphase dauert ja auch einige Zeit. Ich warte immer mind.20 Minuten, bis ich drauf zugreife, bzw.lass ich das Ding um 7:00 mit Energiesparplan hochfahren, und frühstücke erst mal gemütlich 
Um 9:00 ist dann alles bereit 
Ich warte immer mind.20 Minuten ... lass ich das Ding um 7:00 mit Energiesparplan hochfahren ... Um 9:00 ist dann alles bereit
Als ich das letzte Mal nachgezählt habe, waren es von 7:00 bis 9:00 noch 120 Minuten. 
Na ein bisschen Reserve wird doch wohl drin sein. Bin nimmer so schnell vom Frühstück bis ins Büro
Habe soeben QTS 5.0.1.2346 Build 20230322 nach vorherigem Neustart manuell (aus zuvor heruntergeladener ZIP-Datei) auf meinem TVS-672XT installiert.
Es gab bei der Installation keinerlei Probleme und danach (bisher noch) keine Auffälligkeiten.
Hallo zusammen, könnte mit bitte jemand den downloadlink für die vorherige Version
QTS 5.0.1.2277 build 20230112
posten, leider verbindet sich unser Veeam Backup nicht mehr, normaler smb Zugriff ist aber OK, am 2. NAS ohne neue Firmware keine Probleme.
Danke und gruß
Sorry, hab das Modell vergessen TS-431P,
QTS 5.0.1.2277 build 20230112 gibt es leider nicht auf der Support Seite.
Ich weiss, das ist die Version mit den Sicherheitsproblemen, aber mit dieser Version hat der Zugriff funktioniert.
Danke und Gruß
Ist doch genau da wie gesagt wurde : https://eu1.qnap.com/Storage/T…K_20230112-5.0.1.2277.zip
Vielen Dank, glaub ich bin blind
Habe meine 431P gestern von der 2277 auf dei 2346 geupdatet. Bisher keine Probleme. Backup auf externe USB-Platte lief problemlos nach dem anstecker der Platte an. Dienste laufen.
Meine Erfahrungen:
Eine TS-653B mit 6x1TB Samsung 860EVO lässt sich seit Firmware Update nicht mehr über die Oberfläche herunterfahren, es bleibt beim "Prozesse werden beendet"-Fenster hängen.
Eine TS-664 mit 6x4TB WD Red Plus ist wesentlich problematischer:
Auch bei mir der Bug mit dem Systemlüfter, jedoch stürzt das NAS nach ca. 10mins ab und ist weder über SMB, AFP, noch über QTS/Web erreichbar. Nach zig Neustarts fand das NAS die Lüfter dann doch und blieb am Leben.
Benutzeroberfläche ist generell sehr zäh, einfachste administrative Änderungen erzeugen minutenlang Spinner oder Spinner bleibt und der Prozess wird selbst in Stunden nicht beendet.
Durch so einen Prozess hat sich die Zugriffsrechtesteuerung eines Freigabeordners mit ca. 900GB komplett abgeschossen, der Ordner war nur mehr über QTS erreichbar.
Seltsamerweise ist der Zugriff aller Clients (SMB und AFP) der Reihe nach innerhalb von ca. 3h mit der Fehlermeldung ausgefallen, dass nicht ausreichende Berechtigung vorhanden wäre, um auf die Ressource zuzugreifen. Wenn man sich mit den Clients direkt über QTS anmeldete, waren alle Berechtigungen im FS aufrecht.
Von Extern ging garnichts mehr, alle anderen Freigabeordner / Daten normal erreichbar, lediglich in dieser einen Ordner im Nirvana.
Komplettes Neusetzen der Rechte ohne Wirkung, workaround mit Kopieren des Ordners und Neubenennung sowie neuer Rechtezuteilung.
Sämtliche Spiegelungen dieses Ordners (auf anderes NAS und in die Cloud) korrumpiert, Daten unbrauchbar. Backup über USB ebenso. Ziemlich spooky...
Wieder einmal kann ich nur über Qnap den Kopf schütteln und habe gedowngradet.
Tante Edith meint: Achja, beide Firmware Updates von lokal, nach Neustart.
