Benachrichtigungszentrum, QuLog Center und Container Station Web-Oberflächen funktionieren nicht über SmartURL/CloudLink – Rückschritt vermutlich nach myQNAPcloud Link 2.5.1 Update – TS-264

English Allgemein
,
1

Ich habe mit KI Fehlerbehebung durchgeführt und bei der folgenden Frage Hilfe erhalten. Der Haken hierbei ist, dass ich mir nicht zu 100 % sicher bin, wann das Problem begonnen hat – vermutlich kürzlich oder irgendwann im September.

System

  • Modell: TS-264
  • Firmware: QTS 5.2.10.3577 (Build 20260731), installiert am 2026-08-10
  • myQNAPcloud Link: automatisch aktualisiert von 2.4.73 auf 2.5.1 am 2026-10-01 um 23:18
  • Problem erstmals bemerkt: 2026-10-02

Symptome beim Login über SmartURL (qlink.to → myQNAPcloud-Login → .myqnapcloud.com):
- Benachrichtigungszentrum bleibt bei „Daten werden geladen, bitte warten“ hängen
- QuLog Center → Ereignisprotokoll / Zugriffsprotokoll / Online-Benutzer: „Es ist eine Service-Ausnahme aufgetreten. (403)“
- Container Station: Nach wenigen Sekunden erscheint „Verbindung verloren“, verschwindet nach dem Schließen kurz, taucht aber wieder auf

Die zugrundeliegenden Dienste funktionieren einwandfrei; nur die Weboberflächen scheitern über das Relay:

  • Das Benachrichtigungszentrum verschickt weiterhin E-Mail-Benachrichtigungen wie konfiguriert
  • QuLog protokolliert normal (Logs sind über lokale IP vollständig einsehbar)
  • Container laufen weiter und sind erreichbar (z.B. Plex funktioniert wie gewohnt)
  • Andere Web-Apps wie QTS Desktop, QuMagie und Music Station funktionieren über SmartURL problemlos

Die Webinterfaces dieser Anwendungen haben zuvor über SmartURL/CloudLink auf diesem NAS problemlos funktioniert. Ich kann nicht genau sagen, wann sie zuletzt funktioniert haben (irgendwann vor oder im September), aber es handelt sich um ein Problem nach einem Update und nicht um eine neue Einrichtung.

Beim direkten Login über die lokale IP (https) funktionieren alle Weboberflächen normal.

Durchgeführte Fehlerbehebung

  • Die SmartURL-Adresse (.myqnapcloud.com) zeigt auf das CloudLink-Relay und nicht auf meine WAN-IP. Meine primäre DDNS-Domain ist korrekt und stimmt mit meiner öffentlichen IP überein (kein Carrier-Grade NAT).
  • Das Deaktivieren von QuFirewall (ebenfalls aktualisiert am 2026-10-01 auf 2.6.1.0204) bringt keine Abhilfe.
  • NAS neu gestartet; in mehreren Browsern getestet; Systemzeit und Speicher sind in Ordnung.
  • Weitere Updates seit September:
    • myQNAPcloud 1.1.100 (2026-09-02)
    • myQNAPcloud SSL-Zertifikat erneuert (2026-09-22)
    • File Station 6 6.0.5.7994 (2026-09-24)
    • Download Station 5.10.4.368 (2026-10-01)
  • Ähnlicher Nutzerbericht: myQNAPcloud link

Fragen

  1. Ist dies ein bekanntes Problem mit myQNAPcloud Link 2.5.1? Wann wird ein Fix erwartet?
  2. Bitte stellt myQNAPcloud Link 2.4.73 (x86_64, TS-264) bereit, damit ich zurückrollen und überprüfen kann, ob dies die Ursache ist.
  3. Falls es nicht an myQNAPcloud Link 2.5.1 liegt: Könnte es mit myQNAPcloud 1.1.100 (installiert am 2026-09-02) oder der SSL-Zertifikatserneuerung (2026-09-22) zusammenhängen?
2

Stell wirklich dreifach sicher, dass du niemals Ports vom WAN zu deinem QNAP weiterleitest. (Malware)

3

Gleiche Symptome hier. QNAP TVS-h674. Keine Änderungen vorgenommen, außer der Installation veröffentlichter QNAP-Updates. Das Problem bleibt auch nach einem Neustart bestehen. Ich warte darauf, dass ein Rollback verfügbar wird.

4

Sie wird niemals auf deine WAN-IP zeigen und sollte das auch nicht. Wie @dolbyman schon gesagt hat, möchtest du dein NAS niemals ins WAN stellen. MyQNAPCloudLink ist die sichere (oder zumindest sicherere) Methode dafür.

6

Es wird nie auf dein WAN zeigen und sollte das auch nicht. Wie @dolbyman schon sagte, möchtest du dein NAS niemals ins WAN stellen. MyQNAPCloudLink ist der sichere (oder sicherere) Weg, das zu machen.

Zur Klarstellung: Das NAS ist nicht dem WAN ausgesetzt. Es gibt kein Port-Forwarding und UPnP ist deaktiviert; ich greife ausschließlich über SmartURL/myQNAPcloud Link darauf zu. Der DNS-Check war nur, um zu bestätigen, dass meine Sitzungen über das CloudLink-Relay laufen, was auch zu erwarten ist.

7

Weißt du, zwischen welchen Updates dieses Problem aufgetreten ist?

8

Entschuldigung für die Unannehmlichkeiten. Die Ursache dürfte das Upgrade von myQNAPcloud Link 2.5.1 sein. Wir haben das Problem bestätigt und planen, es im nächsten Update von myQNAPcloud Link zu beheben.

9

Hallo,

Ich habe das gleiche Problem auf einem QNAP TS-473 mit QTS 5.2.10.3577.

Das Problem ist nach dem Update von myQNAPcloud Link auf 2.5.1 aufgetreten: QuLog Center gibt den Fehler 403 zurück und Notification Center bleibt bei „Daten werden geladen, bitte warten.“ hängen.

Der Remote-Zugriff auf den QTS-Desktop funktioniert weiterhin. Momentan habe ich nur Remote-Zugriff, daher habe ich es lokal noch nicht getestet.

10

Super, danke, dass du dir das angeschaut und das Problem behoben hast!

11

Nein, ich kann nicht sehen, welches Update das verursacht hat, da das Log Center ebenfalls infolgedessen nicht erreichbar ist. Alles, was ich weiß, ist, dass es irgendwann im September war. Nur zur Info: Ich habe die QNAP Android-App installiert und konnte eingeschränkten Zugriff auf das Benachrichtigungszentrum bekommen. Viel kann man in der App nicht machen, aber ich konnte einige Benachrichtigungen ausschalten, die ich zum Testen eingerichtet hatte und die meine Posteingänge verstopft haben.