Nachdem ich diese Firmware (Version: h6.0.0.3500 Build 20260520 Veröffentlicht: 2026-05-29) installiert habe, versucht mein NAS beim Anmelden 20 Sekunden oder länger, eine Verbindung herzustellen, offenbar zu MyQnapCloud (das ich weder aktiviert noch nutze). Auch das Öffnen des Qnap App Centers nach dem Login dauert weitere 20 Sekunden oder mehr. Wenn ihr wie ich euren Router so eingestellt habt, dass zufällige Anfragen ins Internet blockiert werden, dauert das Anmelden mindestens 20 Sekunden, weil das NAS diese Telemetrie-Sequenz durchläuft. Ich schätze, wir sind nur noch einen Schritt davon entfernt, dass Qnap nicht einmal mehr fragt, ob man Daten teilen möchte. Es scheint keine Möglichkeit zu geben, MyQnapCloud zu deinstallieren oder zu deaktivieren, obwohl ich alle zugehörigen Dienste deaktiviert habe und kein Port-Forwarding nutze. Ich werde wohl mit den Firewall-Regeln von Qnap herumprobieren müssen.
Hallo und willkommen im Forum. 
Wenn du die App Center-Anwendung öffnest, wird sie ihre QPKG-Listen vom QNAP-Repository-Server aktualisieren. Das passiert auch bei Drittanbieter-Repositories wie myqnap.org. Das ist völlig normal.
Wenn du den Zugriff auf QNAP-Server blockierst, dauert der Start des App Centers länger als nötig und deine lokalen Repository-Listen sind veraltet.
Mein Punkt war, dass das Einloggen unter der 6.0-Firmware einen deutlich längeren Telemetrie-Prozess auslöst, wenn – so wie bei mir – Firewall-Regeln vorhanden sind, die verhindern und überwachen, welche Verbindungen dein NAS aufbaut. Das war bei der 5.x-Firmware nicht der Fall. Mit der vorherigen Firmware gab es bei mir keine langen Verzögerungen und ich verstehe nicht, warum mein NAS bei jedem Login Anfragen an Qnap-Server stellen muss, wenn ich NICHT das App Center oder MyQnapCloud nutze.
Wenn dir die Wartezeit nicht gefällt, dann blockiere die Verbindungen nicht.
Wenn du verhindern willst, dass die Firmware wie vorgesehen funktioniert, darfst du dich auch nicht über die Nebenwirkungen beschweren.
Das liegt daran, dass sich Software weiterentwickelt. Jede Version ist nicht identisch zur vorherigen Version. Jede Version funktioniert nicht unbedingt wie die vorherige. Auch das ist ganz normal.
Vielleicht kann sich ja jemand von QNAP dazu äußern, was genau während des Anmeldevorgangs passiert? Für das App Center könnte ich es noch erklären, aber bei den Gründen während des Logins müsste ich raten.
Laut den Qnap-Protokollen verbindet sich das NAS mehrfach von verschiedenen Ports aus mit Amazon AWS-Servern, offenbar um beim Anmelden einige Informationen zu synchronisieren. Ich habe keine spezifische Regel, um die Verbindungen auf meinem Router zu blockieren. Ich denke, die Art der wiederholten Verbindungsversuche führt dazu, dass der Router die Anfragen ablehnt.
tcp 0 1 172.x.x.x:59822 3.171.85.4:1337 SYN_SENT
tcp 0 1 172.x.x.x:55936 3.171.85.32:1337 SYN_SENT
tcp 0 1 172.x.x.x:55906 3.171.85.32:1337 SYN_SENT
tcp 0 1 172.x.x.x:59826 3.171.85.4:1337 SYN_SENT
tcp 0 1 172.x.x.x:52634 3.171.85.110:1337 SYN_SENT
tcp 0 1 172.x.x.x:55922 3.171.85.32:1337 SYN_SENT
Erstens musst du deine 172.x.x.x LAN-Adressen nicht verstecken, da es sich dabei um einen privaten Adressbereich handelt, der von Millionen von Menschen in ihren eigenen LANs verwendet wird. Es ist kein öffentlich zugänglicher Adressraum.
Zweitens kann es dafür viele Gründe geben, die nichts damit zu tun haben, dass Daten mit QNAP „geteilt“ werden. Es ist durchaus möglich, dass das System beim Start beispielsweise nach Firmware-Updates sucht oder andere Dinge prüft. Ich weiß nicht genau, was QNAP bei Hero 6 macht, aber es ist durchaus möglich, dass sie bei Sicherheitsupdates proaktiver sind usw. Wenn das NAS hochfährt, kann es also nachsehen, ob die Firmware aktuell ist und ob ein Update erforderlich ist.
Geräte unnötig einzuschränken ist meiner Meinung nach keine gute Sicherheitsmethode. Und wenn du das doch tun möchtest, musst du eben auch mit den Konsequenzen leben.
Ich verstehe ehrlich gesagt nicht, warum hier manche so defensiv auf meine Warnung reagieren, vor allem wenn mir Dinge unterstellt werden, die ich gar nicht behauptet habe. Ich habe weder vor noch nach der Installation der 6.0-Firmware die Qnap-Server explizit blockiert. Ich habe lediglich festgestellt, dass die Anmeldung und der Zugriff auf das App Center sehr lange dauerten, während Qnap versuchte, seine AWS-Server zu erreichen – was vor dem Firmware-Update nicht der Fall war.
Und auch wenn eine private IP-Adresse allein für einen potenziellen Hacker nicht direkt nützlich ist, besteht in diesem KI-Zeitalter das Risiko, dass eine private IP in Kombination mit anderen Informationen (wie z.B. exponierten Diensten, geleakten Zugangsdaten oder Schwachstellen) ein lokales Netzwerk angreifbar machen könnte. Daher behalte ich mir definitiv das Recht vor, Informationen, die bei der Problemdiagnose nicht helfen, NICHT herauszugeben. Wie auch immer, für mich ist das Thema damit erledigt und ich schaue nach vorne…
Ähm, nein. Das Freigeben privater IPs ist absolut unbedenklich. Das Freigeben deiner öffentlichen IP birgt Risiken.
Und hier ist niemand defensiv. Es ist nur etwas seltsam, dass deine Firewall ausgehende Anfragen blockiert.
Und ja, vielleicht sind wir ein bisschen genervt wegen deines Titels „Achtung…“ – das klingt so, als würde wirklich etwas Schlimmes passieren. Das ist aber nicht der Fall.
Ich meine, es gibt durchaus legitime Fälle, in denen NAS-Einheiten in einer streng offline Umgebung installiert werden.
Cold Storage, ein Boot ohne Starlink, usw. Falls das dazu führt, dass der Login- (oder anderer) Prozess hängen bleibt, wäre es vielleicht für QNAP sinnvoll, eine Option zu prüfen.
Jeder kann ja mal das Problem haben, dass der eigene Internetanbieter für ein paar Tage ausfällt – aus welchem Grund auch immer – und ein langsames NAS deswegen kann wirklich nerven.
Soweit ich mich erinnere, hilft es in solchen Fällen, den Netzwerk-Konnektivitäts-Check-Dienst zu deaktivieren.
Hallo @Bitbytes,
vielen Dank, dass du dieses Problem gemeldet und deine detaillierten Beobachtungen mit uns geteilt hast.
Nach deiner Beschreibung tritt die Verzögerung scheinbar nach dem Update auf QuTS hero h6.0.0 auf – insbesondere wenn das NAS in einer Netzwerkinfrastruktur betrieben wird, in der bestimmte ausgehende Verbindungen vom Router oder der Firewall eingeschränkt oder überwacht werden. Wir verstehen, dass dieses Verhalten gerade für Nutzer, die ihr NAS in einer strikt offline oder nur eingeschränkt verbundenen Umgebung betreiben, unbequem sein kann.
Um uns bei der weiteren Untersuchung zu unterstützen, könntest du uns bitte mehr Details zu den angewendeten Firewall-Regeln für das NAS mitteilen?
Zum Beispiel:
- Ob ausgehende Verbindungen vom NAS standardmäßig blockiert sind
- Gibt es erlaubende/blockierende Regeln für QNAP-Dienste, AWS-IP-Adressen, DNS, HTTPS oder eigene Ports?
- Ob die Firewall diese Verbindungen blockiert, ablehnt oder stillschweigend verwirft
- Firewall-Logs zum Zeitpunkt der NAS-Anmeldung oder beim Starten des App Centers
- Ob die gleiche Verzögerung auftritt, wenn das NAS testweise in einer weniger restriktiven Netzwerkumgebung betrieben wird
Du kannst gerne sensible öffentliche IP-Adressen oder interne Netzwerkdetails vor dem Teilen unkenntlich machen.
Diese Informationen helfen uns besser zu verstehen, ob die Verzögerung durch einen bestimmten Konnektivitäts-Check, eine Service-Anfrage oder durch das Verhalten der Firewall ausgelöst wird – und ermöglichen es uns, unserem Engineering-Team gezielteres Feedback zu geben.
Vielen Dank nochmals, dass du uns auf dieses Thema aufmerksam gemacht hast.
Ich habe deine Benutzerstufe geändert, sodass du jetzt private Nachrichten senden kannst.
Er hat zwei Punkte angesprochen und du bist auf seinen zweiten Punkt eingegangen, nämlich dass, wenn man QNAP Cloud blockiert, das App Center sehr lange braucht. Ein viel besorgniserregenderes Problem ist jedoch das Einloggen. Ich würde nicht erwarten, dass es 20 Sekunden dauert, nur um sich in der UI anzumelden. Kann jemand anderes, der QuTS 6 nutzt, bestätigen, ob das wirklich so ist, wenn das Internet blockiert ist? Ich bin noch auf QuTS 5, und wenn das Internet getrennt ist, kann ich mich weiterhin sofort einloggen.
Da stimme ich zu, aber ein großer Unterschied besteht zwischen gar keinem WAN-Zugang und teilweisem WAN-Zugang. 
Ich denke, das wirft das größere „Was noch?“-Problem auf. Wenn du aus irgendeinem Grund keine Verbindung zu dem herstellen kannst, was es erreichen will, gibt es dann noch andere Dinge, die hängen bleiben könnten? 20 Sekunden zum Einloggen, 20 Sekunden für AppCenter – nehmen wir mal an, du musst etwas reparieren und dich durchs System bewegen. Dauert dann jeder Klick in der Oberfläche oder jeder CLI-Befehl auch jeweils 20 Sekunden? Meiner Meinung nach ist das ein Vertrauensproblem.
Wir kennen seine Situation nicht. Im Moment ist er die einzige Person, von der ich gehört habe, dass sie sich über lange Login-Verzögerungen in Hero 6 beschwert. Wenn das ein generelles Problem wäre, würden sich bestimmt mehr Leute beschweren.
Genau. Deshalb habe ich gefragt, ob jemand anderes auf 6 das gesehen hat. Es ist wahrscheinlich ungewöhnlich, ohne Internetverbindung zu laufen, daher könnte das ein Randfall sein. Vielleicht könnten ein paar andere, die QuTS 6 benutzen, einfach mal ihr WAN-Kabel für eine Minute abziehen und bestätigen oder widerlegen.