QuTS hero h6.0.1.3550 Build 20260709 veröffentlicht

Das erste Update

QuTS hero h6.0.1.3550 Build 20260709 2026-07-14

Anwendbare Modelle
TS-h2490FU/TS-h1090FU
TS-h1290FX
TDS-h2489FU/ TDS-h2489FU R2
TS-h3088XU-RP
TVS-h1288X/TVS-h1688X
TS-h987XU-RP/TS-h1887XU-RP/TS-h2287XU-RP/TS-h3087XU-RP
TS-h1886XU-RP/TS-1886XU-RP/TS-h1886XU-RP R2
TS-h686/TS-h886
TNS-h1083X
TS-883XU/TS-883XU-RP/TS-983XU/TS-983XU-RP/TS-1283XU/TS-1283XU-RP/TS-1683XU/TS-1683XU-RP/TS-2483XU/TS-2483XU-RP/TS-h1283XU-RP/TS-h1683XU-RP/TS-h2483XU-RP
TS-h977XU-RP/TS-h1277XU-RP/TS-h1677XU-RP/TS-h2477XU-RP
TS-h1277AXU-RP/TS-h1677AXU-RP/TS-h2477AXU-RP/TS-h3077AFU
TVS-h1675U-RP/TVS-h1275U-RP/TVS-h875U-RP/TVS-h875U
TVS-675
TVS-h474/TVS-h674/TVS-h874/TVS-h874X/TVS-h674T/TVS-h874T
TBS-h574TX
TS-873AU/TS-873AU-RP/TS-1273AU-RP/TS-1673AU-RP/TS-873AeU/TS-873AeU-RP
TS-h973AX/TS-473A/TS-673A/TS-873A
TVS-672X/TVS-872X/TVS-672N/TVS-872N/TVS-472XT/TVS-672XT/TVS-872XT
TS-1655/TS-855X
TS-855eU/TS-855eU-RP/TS-h1655XeU-RP
TS-253E/TS-453E
HS-264/TBS-464/TS-364/TS-464/TS-664/TS-264/TS-464C2
TS-466C
TS-464U/TS-464U-RP/TS-1264U-RP/TS-464eU/TS-864eU/TS-864eU-RP
TS-i410X/TS-410E
TS-h765eU
TS-h1277AFX
TVS-AIh1688ATX
Qu805/Qu605/Qu405

Wichtige Hinweise
Die folgenden Erweiterungkartenmodelle werden ab QuTS hero h6.0.0 nicht mehr unterstützt: Mustang-200-C-8G-R10, Mustang-200-i5-1T-32G-R10, Mustang-200-i7-1T-32G-R10, Mustang-F100, Mustang-V100, QM2-2P10G1T, QM2-2S10G1T.
Ab QuTS hero h6.0.0 werden die folgenden Anwendungen nicht mehr unterstützt: CAYIN CMS-WS Lite und CAYIN MediaSign Player (ersetzt durch CAYIN Media Viewer), IDrive, JRE, Mustang Card Manager, Mustang Card User Driver, Python, Python3, QButton, Qmiix Agent, QVR Elite (ersetzt durch QVR Surveillance), Skype.
Zur Gewährleistung der Systemsicherheit ist ab dem h6.0.0 Release Candidate ein Firmware-Downgrade in QuTS hero nicht mehr möglich.
Für das beste Erlebnis und optimale Systemleistung wird empfohlen, nach dem Firmware-Update alle verfügbaren Anwendungen im App Center zu aktualisieren.

Sicherheitsupdates
Mehrere Sicherheitsupdates wurden angewendet, um die Systemsicherheit weiter zu erhöhen.

Behobene Probleme
Behoben: Eine Konsolenmeldung deutete bei der Einrichtung über HDMI fälschlicherweise auf das Standard-Admin-Passwort hin. (Das Standardpasswort sollte der Cloud Key statt der MAC-Adresse sein.)
Behoben: Im Bereich “Speicher & Snapshots” wurde die Firmware-Version des TL-R6020Sep-RP SAS JBOD-Erweiterungsgehäuses fälschlicherweise als 0.0.0 angezeigt.
Behoben: Im Bereich “Speicher & Snapshots” wurde das Fehlerstatus-Symbol für das TL-R6020Sep-RP SAS JBOD-Erweiterungsgehäuse angezeigt, obwohl das Gerät normal funktionierte.
Behoben: Nach einem Update von QuTS hero Version h5.1.14 auf h6.0.0.3500 gingen große Speicherpools offline.
Behoben: Die Schaltfläche “Freigabeordner erweitern” wurde ausgegraut und konnte nicht mehr angeklickt werden, nachdem die Kapazität eines Ordners auf 5 PB (oberes Limit) erweitert wurde.
Behoben: Das Anwenden einzelner ACL-Berechtigungsänderungen blieb gelegentlich bei 0 %, wenn die Ordnerstruktur tief und komplex war.
Behoben: Im Speicher-Manager wurde RAID 60 beim Hinzufügen einer neuen RAID-Gruppe als RAID 6 angezeigt.
Behoben: Der Assistent “Speicherpool erweitern” erlaubte es, beim Erstellen einer RAID 60-Gruppe das Limit von 16 Festplatten zu überschreiten.
Behoben: Snapshots, die auf dem temporären Übernahmeknoten erstellt wurden, erschienen nach einem automatischen Failback zum ursprünglichen aktiven Knoten nicht in den SMB-Vorherigen Versionen.
Behoben: Verkabelte 802.1X-Authentifizierung schlug nach einem Firmware-Update von QuTS hero h5.x.x auf h6.0.0 fehl.
Behoben: Verschlüsselte Freigabeordner erlaubten weiterhin nicht unterstützte Zeichen in Passwörtern, was nach dem Firmware-Update auf QuTS hero h6.0.0 zu Entsperrfehlern führte.
Behoben: DNS-Auflösung schlug fehl, wenn die IP-Adresse des DNS-Servers nicht in der Liste der vom Benutzer definierten erlaubten Verbindungen war.
Behoben: Fehlerhafte API-Verarbeitung führte zu abnormen Logeinträgen und Ramdisk-Fehlern.

QuTS hero h6.0.1.3550 build 20260709 | Release Notes | QNAP

Mein NVIDIA-Treiber wird auch nach einer Neuinstallation nicht geladen. Bitte hilf mir weiter.

Geht mir genauso. Passiert anscheinend häufig bei den QuTS-Updates.

Ich glaube, ich habe es gelöst. Nvidia-GPU-Treiber deinstallieren.

Aktualisierten NVidia GPU Kernel-Treiber installieren:

https://download.qnap.com/Storage/QuTShero/DriverQPKG/QTS_h6.0.1/3550/NvKernelDriver_h6.0.1.3550_TS-X88_20260709.qpkg

Ich habe neu gestartet.

NVIDIA GPU-Treiber Version 6.2.2.1106 erneut installieren

Scheint zu funktionieren.

Ich habe das versucht, aber es funktioniert bei mir nicht.

Ich habe dasselbe Problem. Ich habe versucht, den Treiber sowie den Kernel zu deinstallieren, aber ich kann den Kernel nicht entfernen. Nachdem ich den Treiber entfernt hatte, habe ich neu gestartet, den Treiber erneut installiert, wieder neu gestartet – aber es funktioniert immer noch nicht.

Ich habe ein Ticket beim Helpdesk eingereicht.

UND WAS ZUR HÖLLE??? MAN KANN NICHT WIEDER DOWNGRADEN, WENN MAN AUF 6 GEUPDATET HAT?! QNAP – WIE ZUM TEUFEL SOLLEN DIE NUTZER IHR SYSTEM WIEDER ANS LAUFEN KRIEGEN, WENN IHR PROBLEME MIT EINEM FIRMWARE-UPDATE HABT?! Wessen geniale Idee war das bitte?!

Wünschte, ich wüsste, warum es bei mir scheinbar funktioniert hat. Ich musste nach einem der letzten Updates dasselbe machen. Selbst nach Neustarts hat es gehalten. Aber ja, ich glaube, bei jedem QuTS hero-Update gab es irgendein Problem damit, dass die Nvidia-Treiber nicht geladen wurden und manuell nachgeholfen werden musste. Schon merkwürdig.

Ich habe die NVIDIA GPU-Treiber-App deinstalliert, konnte aber den Kernel nicht installieren. Also habe ich mich per SSH eingeloggt, die Kernel-Einträge in der qpkg.conf-Datei entfernt, dann das Verzeichnis des Kernel-Pakets im .qpkg-Ordner gelöscht, neu gestartet und danach den Kernel manuell heruntergeladen und installiert. Zumindest das GPU-Passthrough für die Container Station funktioniert jetzt. Der Treiber wird in QuTS Hero allerdings immer noch nicht geladen, aber beim Systemstart erscheint zumindest keine Fehlermeldung mehr wie vorher.

Hallo,
ich habe tatsächlich dasselbe Problem mit dem Nvidia-Treiber. Eine Neuinstallation im Blindflug löst das Problem nicht.

Ich bin mir nicht sicher, ob es eine gute Idee ist, die Installation des nvkerneldriver zu erzwingen.

Wir konnten dieses Problem bei uns nicht nachstellen. Falls andere Nutzer ein ähnliches Problem haben, könnt ihr gerne ein Support-Ticket erstellen – unser Support-Team hilft euch dann gerne weiter. Vielen Dank!

Hallo,

vielen Dank für deinen Kommentar, er hat mir weitergeholfen. Ich hatte zwar ein Ticket beim Support eröffnet, bin dann aber deinem Rat gefolgt und habe den neuen „nvkerneldriver“ installiert. Davor hatte ich die NVidia-Treiber deinstalliert (mit anschließendem Neustart) und sie dann zusammen mit dem „nvkerneldriver“ wieder installiert.

Seitdem läuft alles besser :slight_smile:

Kein Downgrade von 6.0.1.3500 auf 6.0.0.3500 möglich

Ist das dein Ernst? Man kann nicht mal innerhalb von QuTS 6.x downgraden? Ich denke schon länger darüber nach, von QTS auf QuTS auf meinem TVS-872XT umzusteigen, um ZFS zu nutzen, aber ich warte und beobachte, bis v6 halbwegs stabil wird, damit ich direkt dort statt bei v5 anfangen kann. Das macht mich jetzt doch etwas nervös, falls das stimmt. Über die Jahre musste ich QTS schon ein paar Mal downgraden, weil ein Treiber kaputt gegangen ist oder sendmail nicht mehr funktioniert hat.

Ich habe versucht, von 6.0.1.3500 auf 6.0.0.3500 downzugraden, und es wurde mir nicht erlaubt.

Hier ist der Text aus den Release Notes von 6.0.1.3500. Das ist kein Major Release, das normalerweise Downgrades auf die vorherige Firmware verhindert.

Meiner Meinung nach ist das eine schlechte Entscheidung, angesichts der vielen Nutzer, die nach einem Firmware-Upgrade Probleme haben. Die einzige Support-Option ist deren Helpdesk-App und E-Mails hin und her. Viele dieser Nutzer sind kleine Unternehmen, die QNAP für Videoschnitt oder Datenspeicherung verwenden. Ein Problem kann sie jetzt tagelang lahmlegen, weil sie die Firmware nicht zurücksetzen können.

Ich verstehe, dass dies aus Sicherheitsgründen geschieht, aber sie müssten wirklich ihre Qualitätskontrolle und das Testing erheblich verbessern, damit das nicht zu Unzufriedenheit führt. Außerdem ist ihre eigene Bilanz in Sachen Sicherheit nicht gerade die beste.

Ich verstehe… Ich dachte, das bezieht sich auf Hauptversionen, also von v6 zurück zu v5.x – was sowieso eine schlechte Idee wäre. Aber nicht innerhalb der v6-Minus-Releases.

Es erscheint mir vollkommen übertrieben, dass man nicht einmal zu einer Minor-Version zurückkehren kann, die nur ein paar Tage früher veröffentlicht wurde. QNAP ist ja berüchtigt dafür, dass man auf eine frühere Version zurückgehen muss, wenn deren Firmware nicht funktioniert oder instabil ist… :o

Das ist ein hervorragender Kommentar. QNAP weiß ganz genau – wie jeder andere Hersteller auch –, dass sie bei Firmware-Releases oft Fehler machen. Dabei ist es egal, ob es Apple, Adobe, Ubiquiti oder QNAP ist. Deshalb ist es extrem wichtig, die Möglichkeit zu haben, das Firmware-Update wieder auf eine frühere Version zurückzusetzen („back rev").

Bob Zelin

Für diejenigen von euch, die QuTS 5.x nutzen: Ich gehe davon aus, dass ihr in der Lage wart, kleinere Revisionen zurückzusetzen? Ist das also etwas Neues in QuTS 6.x?

Es wäre schön, wenn es von QNAP ein offizielles Statement dazu gäbe, warum sie das auch nur ansatzweise für eine gute Idee halten. Ich könnte dazu ein Ticket erstellen, aber ich möchte zuerst sicherstellen, dass wir die Fakten kennen oder ob jemand vielleicht schon einen Kommentar dazu von ihnen gesehen hat – ich will nichts doppelt machen.

Davon abgesehen muss es auf der Support-Seite von QNAP eine Möglichkeit geben, bei kritischen Problemen ein Downgrade durchzuführen. Vielleicht haben wir nur noch nicht herausgefunden, wie das geht. Ich hoffe, es gibt irgendwo ein file_flag, das man setzen kann und dann ist das Zurücksetzen möglich.

-Qmann

Dasselbe beim TS-h1277AFX – meine RTX-5060 Ti funktioniert nicht mehr!
Meine Docker-Container geben folgendes zurück: Fehlerantwort vom Daemon: Fehler beim Sammeln von Geräteinformationen beim Hinzufügen des benutzerdefinierten Geräts “/dev/nvidia0”: Datei oder Verzeichnis nicht gefunden

Mit der vorherigen QuTS hero h6.0.1 hat alles korrekt funktioniert.

Wie kann man auf die vorherige QuTS hero h6.0.1 downgraden?
==> Software-Releases können potenziell Probleme verursachen, die durch einen Downgrade schnell behoben werden sollten!

Downgraden ist keine Option, das ist eine Sicherheitsfunktion.

Ja.

Bei QuTShero 5.x gibt es nur eine Warnung, danach kann man downgraden.

Das Bild habe ich nur auf Deutsch

Hallo zusammen,

vielen Dank für das ehrliche Feedback – es ist verständlich, dass der Wegfall eines unkomplizierten Rollbacks Ärger hervorruft, besonders wenn ein Update tatsächlich zu Rückschritten führt, wie beim RTX-/Nvidia-Treiberproblem, das einige von euch getroffen hat. Ich möchte klarstellen, was sich wirklich geändert hat und vor allem, welche Optionen ihr habt.

Zuerst zum Praktischen, denn hier gibt es einen Irrtum, den man ausräumen sollte: Ein Downgrade auf h6 ist nicht unmöglich. Die Änderung besteht darin, dass diese Aktion nicht mehr als Selbstbedienungsfunktion im GUI verfügbar ist. Wenn ein Build bei euch Probleme verursacht, kann unser Support-Team euer System weiterhin auf ein früheres h6-Build zurücksetzen – das läuft jetzt über den Support, nicht mehr per Button in der Oberfläche. Daher stimmt „Downgrade ist keine Option“ nicht ganz: Es ist kein Ein-Klick-Vorgang mehr, aber es ist weiterhin offiziell möglich. Wenn ihr nach einem Update feststeckt, öffnet ein Ticket und bittet explizit um ein Downgrade.

Zum Hintergrund, da sich das gegenüber 5.x wirklich verändert hat: Bei 5.x und früher warnte euch das GUI zwar, ließ aber trotzdem ein Downgrade zu. Ab QTS 6.0 und QuTS hero h6.0 wird das Downgrade – auch zwischen kleineren Builds – nicht mehr im GUI angeboten, und das ist bewusst so geregelt. Das Zurücksetzen eines Geräts auf eine ältere Firmware entfernt auch wieder alle Sicherheits-Patches, und das zu verhindern (Anti-Rollback) ist jetzt Teil der Sicherheitsanforderungen, die wir durch die neue EU-Sicherheitsverordnung – den Cyber Resilience Act – erfüllen müssen. Downgrades werden daher nur noch über den begleiteten Support-Prozess ermöglicht, und nicht mehr per Ein-Klick-GUI, um diese Vorgaben einzuhalten und euch trotzdem helfen zu können, wenn ein Build tatsächlich Probleme macht.

Das macht die Unannehmlichkeiten leider nicht weniger real. Der Punkt, den einige von euch angesprochen haben – dass Produktionsumgebungen einen verlässlichen Weg zurück brauchen – ist absolut legitim und wird von uns als Produkt-Feedback weitergegeben. Es tut uns leid, dass ihr auf 6.x Schwierigkeiten gehabt habt – meldet euch bitte beim Support-Team, wir werden alles geben, euch bestmöglich zu helfen.