QTS 4.5.4.1892 build 20211223 released

  • 2021-12-24

    Important Notes

    • For the status of QTS updates and maintenance for your NAS model, visit https://www.qnap.com/en/product/eol.php
    • To learn more about NAS models that support the TL-D800C, TL-R1200C-RP, TL-D400S, TL-D800S, TL-D1600S, TL-R400S, TL-R1200S-RP, see the Compatibility List at https://www.qnap.com/en/compatibility-expansion
    • We have fixed the vulnerabilities in the following apps to ensure your data security: Qsync Central and IFTTT Agent. To continue using these apps, go to the App Center and update them to the latest version.
    • For more information on the kernel versions for NAS models that QTS 4.5.4 supports, see https://www.qnap.com/en/release-note/kernel
    • Removed the following applications from App Center due to PHP 7 updates in QTS 4.4.1: phpEasyProject, Dolphin, CMS Made Simple, Vtiger CRM, iStat, and ownCloud.
    • Due to compatibility issues, the following applications have been removed from the App Center in QTS 4.4.1: FileFlex, MantisBT, SugarCRM, Xeams, DokuWiki, and Azure Storage.
    • Once you update QTS to 4.4.1 (or later) on the TS-1635AX, you will not be able to downgrade QTS to versions earlier than 4.4.1.
    • Removed support for Plex Home Theater from HybridDesk Station.
    • After reaching their end of support in July 2020, Notes Station and Qnotes have been removed from QTS App Center, Google Play, and Apple App Store. We recommend using Notes Station 3 and Qnotes 3 to benefit from the next-generation note-taking features. For details on how to transfer your notes from Notes Station 2 to Notes Station 3, see the following tutorial: https://www.qnap.com/en/how-to…tion-2-to-notes-station-3
    • Removed HappyGet from the App Center due to changes in Google extension policies.
    • Starting from 4.5.1, QTS is no longer compatible with the following applications: DJ2 Console, CodexPack.
    • QTS 4.5.4 does not support earlier versions of QVR Client. After updating QTS to 4.5.4 (or later), Surveillance Station users can download and install the latest version of QVR Client from the QNAP website: https://www.qnap.com/en/utilities/surveillance

    Security Updates

    • Fixed a security issue.

    Fixed Issues

    • Thunderbolt connection between the NAS and Mac would be interrupted after Mac woke from sleep mode.
    • Users could not create a port trunking group on the TS-251D.
    • Users could not create a VJBOD disk from a remote NAS running QTS 4.5.4.
    • QTS would block WebDAV client IP addresses if users tried to access home folders via WebDAV.
    • Users occasionally could not transfer files to WORM (Write Once, Read Many) shared folders.
    • QTS would occasionally stop responding when users updated the firmware.
    • File Station could not sort certain folder names in ascending order.
    • Users could not use the same port number for both the source and the destination when configuring reverse proxy rules.
    • Users could not find the "@Recently-Snapshot" folder when accessing shared folders via Samba.
    • Users could not create Snapshot Replica jobs if SSH was not enabled on the source NAS.
    • Users could not use the TCP port 443 for web service if the UDP port 443 was reserved for another service. (Normally, users should be able to use the same port number for both TCP and UDP without conflicts.)
    • Connected external devices would automatically disconnect from the NAS after a long idle time.
    • Users sometimes could not finish updating the virus definitions from ClamAV (Clam Antivirus).
    • Antivirus reports could not correctly display file names or job names if antivirus job names in QTS contained Japanese characters.
    • QTS could not remember the custom destination for antivirus archive files if the specified folder path contained a whitespace.
    • Users could not connect to a proxy server if the proxy password contained the following special characters: % & + ;
    • Users could not save a large Autodesk Revit project file in a mounted shared folder even though the NAS still had sufficient storage space.
    • When users mounted NAS iSCSI LUNs on their Mac using globalSAN and then expanded the LUN capacity on the NAS, Mac would still display the original capacity.
    • The TS-873A could not detect Disk 5 - Disk 8 on the TL-D800S expansion enclosure when the QXG-2G2T-I225 network expansion card was installed on the NAS.
    • On the TS-h1886XU, after SSD overheating, fan speeds would not slow down even after SSDs cooled down.
    • Fixed multiple security issues (CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686).
    • Users could not import large-capacity iSCSI LUNs.
    • Storage & Snapshots would still display successful test results for Snapshot Replica jobs even if 2-step verification was enabled on the destination NAS. (Note: Snapshot Replica does not support 2-step verification).
    • SNMP service would sometimes stop working when users monitored OIDs via SyncroMSP.
    • On the TS-x31P models, users could not query CPU usage or CPU temperatures via SNMP.
    • Domain users could not access NAS shared folders via WebDAV.
    • On the NAS models that support a maximum of 16 snapshots per volume or LUN, users could not apply snapshot settings when Smart Versioning was selected as the snapshot retention policy.
    • After setting up a NAS as the main domain controller and another NAS as the additional domain controller, domain users would take a long time to log in to the main domain controller when the additional controller was offline (for example, when this device was restarting).
    • If users accessed QTS via an Smart URL and created share links in File Station, other users would not be able to access these share links.
    • File Station would display an unexpected error message after users deleted a file from advanced search results.
    • Users could not download files from shared folders if they manually specified folder paths and enabled advanced folder permissions.
    • The domain machine account passwords in SMB could not be automatically updated.
    • QTS would display an incorrect warning message about connection failure after users added the default gateway to a virtual switch and then restarted the NAS.
  • Finde ich sehr interessant, dass es für 4.5.4 auch eine neue Version für Geräte gibt, die 5.0 erhalten. Unüblich. Aber QNAP empfiehlt unter bestimmten Umständen ja auch nicht auf 5.0 zu gehen.

    Ich hoffe dann mal darauf, dass morgen eine neue Version von der 4.5.3 kommt :)

  • Höchstens vom Weihnachtsmann persönlich.


    Die Liste der Fixes ist aber ziemlich lang. QTS 4.5.4 ist im Gegensatz zu QTS 5.0 schon eine Weile auf dem Markt. Das zeigt schon: Software ist wohl nie fertig.

  • Was mich aber nun mal interessieren würde...

    Einfach mal auf die 4.5.4.xxx zurück gehen oder überwiegen die Vorteile der 5.0.0.xxx?

    Sprich die Wahl des größeren Übels... ;)

  • Ich persönlich fahre weiterhin 4.5.3, weil mir selbst die 4.5.4 nichts ist. Glücklicherweise laufen 4.5.4 und 5.0 (beides ältere Builds) auf den beiden Systemen, auf dem ich sie drauf hab ohne Probleme (4.5.4 war ein Versehen und 5.0 wollte ich ja auch mal produktiv testen).

    Vorteile sehe ich bei 5.0 keine, außer Wireguard, das würde ich schon ganz gern als Client für Backups nutzen, aber OVPN tut es hier ja auch.

  • Hmm, wenn die 5.0.0 mal stabil läuft wäre ein weiterer Vorteil die bessere Performance der Volumes.

    Ich bin aber nicht sicher, ob ich in nächster Zeit meine Haupt-NAS darauf umstelle. Wahrscheinlich werde ich demnächst die 4.5.4.1892 installieren.

  • Ja das stimmt natürlich, vor allem auch die Schreibrate auf externe Datenträger. Für mich aber irrelevant.

  • Schön wäre es, wenn man die nervige admin- und 2-Faktor-Erinnerung (seit 4.5.4, und da bleibe ich vorerst) abschalten könnte. Dass man sein NAS nur intern betreiben will, kann man sich bei Qnap wohl nicht vorstellen.

  • Vor allem dürfte die Existenz einer aktuellen 4.5.4 Version neben einer ebenfalls neuen 5.0.0 klar bedeuten, dass die 5.0.0 noch nichts für kritische Anwendungsfälle ist.

  • Hallo,


    ich habe mein TVS-672XT von QTS 4.5.4 Build 1787 heute auf Build 1892 aktualisiert.


    Da das System zuvor seit Mitte September durchlief, habe ich es vor dem Update erstmal durchgestartet. Danach hat es gute 8 Stunden lang erstmal die RAID-Gruppe 2 (aus den 6 Stk. HDDs im RAID6 bestehend) synchronisiert.

    Die Platten, nach welchen ich natürlich sofort geschaut habe, meldeten sämtlich den Status gut.


    Nun das Update manuell angeschoben, lief auch recht flink durch.

    Aber nun ist eben diese Synchronisation der RAID-Gruppe 2 erneut gestartet, welche vorhin erst erfolgreich absolviert wurde.


    Muss ich mir nun Sorgen machen (vom Massensterben der x72XT-Serie mal ganz abgesehen), dass mir mein RAID oder meine Platten (die auch jetzt alle als gut gemeldet werden) um die Ohren fliegen? Denn diese Synchronisiererei hat das Ding ja vorher auch nie gemacht bei früheren Aktualisierungen.


    Danke vorab für hilfreiche Kommentare oder zumindest (glaubhafte ^^) tröstende Worte ...

    Frank

  • Ich habe eben mein TS-451+ von QTS 4.5.4 Build 1800 auf Build 1892 aktualisiert.


    Update per manueller Installation des .img-files von Festplatte, da der automatische Updatedienst und QFinder Pro mir jeweils die QTS 5.0.0 Build 1891 anboten (ja, ja, ich weiß, no risk no fun, aber ich brauche gerade nicht noch mehr fun).


    1x Reboot nach dem Update (uptime vor dem Update waren nur 5 Tage).


    Soweit und bisher sieht alles gut aus.

  • Da das System zuvor seit Mitte September durchlief, habe ich es vor dem Update erstmal durchgestartet. Danach hat es gute 8 Stunden lang erstmal die RAID-Gruppe 2 (aus den 6 Stk. HDDs im RAID6 bestehend) synchronisiert.

    Grundsätzlich schon mal richtig angefangen. Heißt aber auch das da schon vorher ein Wurm drin war.

    Ich weiß das ich jetzt Klugschei...ere. Aber ich hätte nach dem Sync erst noch ein Neustart gemacht um zu schauen ob er sich nun wieder gefangen hat, um event. weitere Probleme nicht noch mit ins Update reinzuschleppen.

    Ich würde nun den Resync mal abwarten, dann Neustart und wenn er dann immer noch ein Resync machen will, notfalls auf die 1787 zurück und dann damit nochmals eine Dateisystemüberprüfung starten.

  • Danke Microby :)


    Heißt aber auch das da schon vorher ein Wurm drin war.

    Nur wo und welcher? Bei bisherigen Aktualisierungen und auch sonst kam es noch nicht zu solchen Syncs des RAID zwischendurch. Hinweise oder Warnungen finde ich auch keine ... :-/


    Ich würde nun den Resync mal abwarten, dann Neustart und wenn er dann immer noch ein Resync machen will, notfalls auf die 1787 zurück und dann damit nochmals eine Dateisystemüberprüfung starten.

    Danke. Habe gerade einen Neustart durchführen lassen, diesmal kam es zu keinem neuen Synchroniseren. Dann war es wohl eine Laune oder Eigenart des Systems, vielleicht wollte es am Wochenende und gar Feiertag nicht derart belastet werden :)


    Eine dedizierte Dateisystemprüfung werde ich dennoch mal anwerfen, schaden kann es wohl kaum.


    Schöne neue Woche allerseits :)

    Frank

  • Habe gerade einen Neustart durchführen lassen, diesmal kam es zu keinem neuen Synchroniseren.

    Na dann entspannen und zurücklehnen...

    Hatte ich auch schon mal, deshalb meinte ich ja, einfach mal testen. Bei mir hatte sich das dann auch so beruhigt.

  • Weil die 5.0.0 1870 bei meinem 453Be ziemlich buggy war, hab ich downgegradet (4.5.4 1892) und muss sagen, derzeit läuft alles wieder rund soweit ich das beurteilen kann

  • Zumindest die Update Hinweismeldung funktioniert wieder, kurz nach dem Update meldeten beide NASen, dass es ja auch QTS 5.0.0.1891 gibt...

  • Heute erfolgreich von QTS 4.5.4.1800 build 20210923 upgedatet.


    Da die Echtzeit-Aktualisierung das Update auf die QTS 5.0.0.1891 build 20211221 durchführen wollte, (ich aber nicht) wurde erstmals die manuelle Firmwareaktualisierung über die Imagedatei TS-X53D_20211223-4.5.4.1892.img durchgeführt.


    Bisher keine Probleme.

  • Weil die 5.0.0 1870 bei meinem 453Be ziemlich buggy war, hab ich downgegradet (4.5.4 1892) und muss sagen, derzeit läuft alles wieder rund soweit ich das beurteilen kann

    Hab leider doch einen kleines Problem entdeckt:

    bzgl TimeMachine hab ich über Einstellungen>Rechte Kontingente vergeben. Nun bekomm ich bei jedem Neustart (bzw. auch aktivieren/deaktivieren von Kontingenten) folgende Fehlermeldung:

    Code
    "Setting user quota fail with user xyz"
  • Die Aktualisierung auf 4.5.4.1892 verlief unspektakulär. Allerdings hat sich am Wochenende das System derart aufgehängt, dass man nur noch einen harten Neustart (aus/ein) machen konnte. Es klappte weder das Verbinden von Netzlaufwerken noch der Zugriff per Browser.

    Das kann natürlich Zufall sein, aber der zeitliche Zusammenhang ist doch auffällig.

    Nach dem Neustart läuft aber alles wieder - hoffentlich dauerhaft.