Modell: TS-644
Firmware: QuTS hero h6.0.1.3500 (Upgrade von 5.x, lief zuvor zwei Jahre problemlos)
Client-Betriebssystem: macOS Tahoe 26.5.2
Problem: Beim Durchsuchen eines verschlüsselten freigegebenen Ordners über SMB verursachen CPU und Arbeitsspeicher des NAS durch den SMB-Dienst innerhalb von Sekunden einen starken Anstieg, gefolgt von SMB-Dienst-Neustartfehlern im Systemprotokoll. Der Client (Finder) hängt sich dabei auf oder stürzt ab.
Isolation durchgeführt: - Unverschlüsselte SMB-Shares auf demselben NAS, demselben Pool, demselben Client – einschließlich großer Shares mit vielen Dateien/Ordnern – funktionieren einwandfrei, kein CPU-/RAM-Problem. - Nur der verschlüsselte Freigabeordner löst das Problem aus, und zwar zuverlässig und jedes Mal innerhalb weniger Sekunden beim Durchsuchen.
Der Zugriff auf denselben verschlüsselten Ordner lokal über File Station (Web-GUI) funktioniert problemlos – das Problem betrifft ausschließlich den SMB-Zugriffspfad und nicht die eigentliche Verschlüsselung/Entschlüsselung der Daten.
Bereits getestet, ohne Auswirkung auf das Problem: - „Dateiübertragung mit Kernel-SMB-Daemon beschleunigen“ deaktiviert - „Asynchrones I/O aktivieren“ deaktiviert - „Kopieren einer großen Anzahl kleiner Dateien beschleunigen“ deaktiviert - Und alle drei Optionen gleichzeitig deaktiviert
Auswirkung: Dieser Share war der Hauptanwendungsfall für dieses NAS und funktionierte jahrelang problemlos vor dem Upgrade auf h6. Ein unterstütztes Downgrade von h6 ist nicht möglich (ZFS-Pool-/ACL-Format wird dabei inplace aktualisiert), daher ist das derzeit ein Blocker ohne SMB-Workaround. Verwandte Community-Berichte (gleiche Firmware-Linie, gleiches Symptom – SMB-Speicher-/CPU-Überlastung mit macOS-Clients auf h6):
Anfrage: Bitte behandeln Sie dies als Regression, die explizit mit dem SMB-Zugriff auf den verschlüsselten Freigabeordner zusammenhängt (kein generelles macOS/SMB-Problem), da sie im klaren Isolationstest reproduzierbar ist – identischer Client, identisches NAS, identische Firmware, unverschlüsselte Shares nicht betroffen. Gern stelle ich Systemprotokolle, eine Bildschirmaufnahme des CPU-/RAM-Anstiegs oder SSH-Zugang für Live-Debugging zur Verfügung, falls dies die Fehlersuche beschleunigt.
Gleiche Geschichte wie bei allen anderen – h6-Upgrade, ein bestimmtes SMB-Share auf macOS (bei mir ein verschlüsseltes Share, aber laut anderen Berichten scheint das Problem nicht nur auf einzelne Verschlüsselungsorte beschränkt zu sein) lässt zuverlässig CPU/RAM schon nach wenigen Sekunden beim Browsen in die Höhe schnellen und erzwingt einen Neustart des SMB-Dienstes. Habe Kernel-Mode SMB-Daemon, asynchrones I/O und den Small-Files-Beschleuniger deaktiviert – nichts hat das Problem beeinflusst.
Meine aktuelle, getestete Übergangslösung, bis das behoben ist:
NFS ist auf QuTS hero ein komplett eigener Dienst neben SMB und umgeht somit alles, was im SMB-Stack kaputt ist. Vorgehen:
Systemsteuerung → Netzwerk & Dateidienste → Win/Mac/NFS/WebDAV → NFS-Dienst → prüfen, dass aktiviert (v2 und v3 funktionieren bei mir aktuell beide).
Systemsteuerung → Privilegien → Freigabeordner → [Dein Share] → Freigabeordner-Berechtigung bearbeiten → NFS-Hostzugriff → Zugriffshäkchen setzen, die IP deines Macs (oder Subnetz) eintragen, Squash auf „keine Benutzer“ (no_root_squash) stellen, Berechtigungen nach Bedarf anpassen.
Am Mac: Finder → Cmd+K → nfs://<nas-ip>/yourshare → Verbinden.
Kein Terminal nötig, wird wie ein normales Netzlaufwerk eingebunden. Das ist zwar keine echte Lösung (QNAP muss den SMB-Fehler noch beheben), aber bei mir läuft es so absolut stabil, wo SMB nicht mehr benutzbar war. Wenn du nicht auf das Support-Ticket warten willst und dringend Zugang brauchst, ist das einen Versuch wert.
Ich betreibe einen TS-h973ax und habe genau die gleichen Probleme. Es ist echt verrückt, dass Unternehmen die wichtigsten Aspekte ihrer Software nicht auf Qualität testen, bevor sie sie in die Produktion schicken.
Im Zeitalter von KI ist das einfach nicht akzeptabel. QNAP, reißt euch zusammen.
Update: Ich habe mein Problem gelöst. Die Ursache scheint darin zu liegen, dass Datei- und Ordner-Metadaten aktualisiert werden müssen.
Gehe in den Einstellungen zu deinen „Freigegebenen Ordnern“, und das System beginnt, sämtliche Metadaten neu zu erstellen. Das kann bei sehr großen Ordnern lange dauern, da der komplette Baum durchlaufen werden muss. Nach Abschluss funktionieren große Ordner, die zuvor gehangen haben, wieder ganz normal.
Mehr von QNAPS KI:
Ich verstehe – nach dem Upgrade auf QuTS wurden deine SMB-Freigaben langsam oder hängten sich auf, und durch das manuelle Aktualisieren jedes freigegebenen Ordners wurden diese wieder repariert. Hier ist die wahrscheinlichste Ursache und was das Aktualisieren bewirkt hat.
Mögliche Ursachen:
Der SMB-Dienst oder die Freigabe-Metadaten-Caches wurden nach dem Firmware-Upgrade inkonsistent (Zugriffslisten, Mount-Zustände oder gecachte Attribute).
Eine Firmware-Änderung hat die SMB-I/O-Pfade oder das Logging-Verhalten beeinflusst, wodurch langsame Antworten entstanden, bis die Metadaten bzw. der Zustand der Freigabe neu geladen wurden. (Die Release Notes enthalten Fehlerbehebungen für langsames SMB unter bestimmten Bedingungen.)
Hintergrundaufgaben (ACL-Anwendung oder Berechtigungs-Indexierung) wurden möglicherweise durch das Update unterbrochen und mussten manuell neu gestartet werden.
Warum das Aktualisieren geholfen hat:
Das Aktualisieren eines freigegebenen Ordners in Systemsteuerung > Privilegien > Freigegebene Ordner > Freigegebener Ordner zwingt das NAS dazu, die Metadaten, Berechtigungen und den Mount-Zustand der Freigabe neu zu prüfen — alte Caches werden gelöscht und die SMB-Handler für diese Freigabe werden neu initialisiert.
Diese Reinitialisierung ermöglicht es den SMB-Daemons, ihren internen Zustand neu aufzubauen und die normale Reaktionsfähigkeit wiederherzustellen.
Empfohlene Schritte (nicht destruktiv):
Stelle sicher, dass du die neueste QuTS-Version und die Release Notes hast; wende ggf. Hotfixes an.
Unter Systemsteuerung > Netzwerk & Dateidienste > Win/Mac/NFS SMB kurzzeitig deaktivieren und wieder aktivieren, um einen globalen Dienstneustart zu erzwingen.
In Systemsteuerung > System > Systemprotokolle nach SMB-bezogenen Warnungen suchen und unterbrochene Hintergrundaufgaben prüfen.
Wenn bestimmte Freigaben weiterhin hängen, führe eine Berechtigungsaktualisierung für die betreffende Freigabe durch und prüfe den Zustand des Storage-Pools/RAID in Speicher & Snapshots.
Überprüfung: Nach den oben genannten Schritten greife von einem Mac-/Windows-Client auf jede SMB-Freigabe zu und prüfe die normale Verzeichnisauflistung sowie die Lese-/Schreibleistung. Überwache die Protokolle auf wiederkehrende SMB-Fehler.
Sollten die Probleme bei mehreren Freigaben anhalten oder nach einem Neustart wieder auftreten, öffne bitte ein Ticket über das QNAP Service Portal, damit die Ingenieure die Protokolle sammeln und eine ausführlichere Diagnose durchführen können.
