Container Station zeigte wiederholt die Meldung „Fehler beim Ändern des Container-Ordners“, sobald ich versuchte, ein benutzerdefiniertes Verzeichnis für den Container-Speicher auszuwählen. Selbst nach Neuerstellung des Ordners, Korrektur der Berechtigungen, Wiederaufbau der ZFS-Datasets und Neuinstallation von Container Station blieb der Fehler bestehen.
Ursache
QuTS hero erzwingt strenge Validierungsregeln für Container Station-Speicherpfade:
Der Ordner muss ein QTS-Freigabeordner sein, kein manuell erstelltes Verzeichnis unter /share.
Der Name „Container“ ist reserviert und darf nicht für Freigabeordner oder Datasets verwendet werden.
Manuell erstellte ZFS-Datasets (über CLI) werden nicht in der internen QTS-Konfiguration registriert, daher lehnt Container Station sie ab.
Container Station akzeptiert nur Ordner, die über Systemsteuerung → Freigabeordner erstellt wurden.
Lösung
Einen neuen Freigabeordner über die GUI mit einem nicht reservierten Namen (ContainerData) erstellt.
Diesen Freigabeordner direkt in den Speicher-Einstellungen von Container Station ausgewählt.
Container Station akzeptierte den Ordner sofort, sobald er als korrekt registrierter Freigabeordner vorlag.
Der UPnP-Status zeigte gemischte Ergebnisse: TCP-Dienste wurden korrekt weitergeleitet, aber mehrere VPN-Dienste (PPTP, OpenVPN, QBelt) scheiterten konsequent beim UPnP-Portmapping. Nur L2TP/IPSec war erfolgreich.
Ursache
Das Muster zeigte:
UDP-Ports schlugen fehl, während TCP-Ports funktionierten.
QBelt verwendete UDP 443, einen Port, der oft von Routern/ISPs blockiert oder reserviert wird.
Manche Router unterstützen kein UPnP für UDP-Mappings.
Mögliche Double NAT- oder ISP-Beschränkungen bei niedrig nummerierten UDP-Ports.
Lösung
QBelt auf einen hohen, unverbrauchten UDP-Port (60000) umgestellt, um Router- und ISP-Filter zu vermeiden.
Den Port manuell am Router weitergeleitet (UDP 60000 → NAS_IP).
QVPN-Dienst neu gestartet.
QBelt und andere VPN-Dienste funktionierten nach dem Wechsel auf einen hoch nummerierten UDP-Port normal.
3. ZFS-Dataset-Verhalten unter QuTS hero
Zusammenfassung
Manuell erstellte ZFS-Datasets wurden korrekt eingehängt, aber nicht von QTS-Diensten wie Container Station erkannt.
Ursache
QuTS hero verlangt, dass Datasets als Freigabeordner über die GUI erstellt werden, damit sie:
in der QTS-Konfiguration registriert werden
die richtigen ACLs erhalten
für Systemdienste sichtbar sind
von Container Station validiert werden
CLI-erstellte Datasets umgehen diese Registrierungsschritte.
Lösung
Das Dataset als Freigabeordner über die GUI neu erstellt.
QTS die Verwaltung von Mountpoints, ACLs und Metadaten überlassen.
Alle abhängigen Dienste (Container Station, QVPN) erkannten den Ordner danach korrekt.
Freigegebene Ordner sind in QuTS Hero völlig anders als in QTS. Dies ist einer der Hauptunterschiede zwischen den beiden Betriebssystemen.
Ich weiß nicht, ob QTS den „Container“-Ordner benötigt, aber Container Station in QuTS Hero erstellt ihn automatisch. Dies ist ein bekanntes Verhalten.
Mit deinem YAML-Code kannst du dann ein anderes Volume auf dem NAS oder einen anderen Ordnerpfad für die Datenspeicherung, den Zugriff durch den Container usw. verwenden.
Ich wollte gerade den Screenshot teilen, der zeigt, wie ich das Problem gelöst habe, aber sobald ich Qsirch wieder aktiviert habe, wurde mein NAS nicht mehr ansprechbar. Das ist genau das gleiche Verhalten wie zuvor – lange Phasen, in denen das System nicht erreichbar ist. Daher kann ich den Screenshot im Moment nicht machen, bis sich das NAS wieder erholt hat.
Sobald es sich stabilisiert hat, teile ich die Details dessen, was ich gemacht habe.
Danke für die Erklärung – das ergibt Sinn. In meinem Fall scheint es jedoch so zu sein, dass die Demo-Firmware den Container-Ordner überhaupt nicht erstellt hat oder die Erstellung zumindest fehlgeschlagen ist. Er ist auf meinem System nie automatisch erschienen.
Ich habe sogar versucht, den Ordner manuell über SSH zu erstellen, aber Container Station hat ihn trotzdem nicht erkannt. Die einzige Möglichkeit, wie es funktioniert hat, war, einen anderen Ordnernamen zu verwenden und Container Station stattdessen auf diesen Pfad zu verweisen.
Das könnte also ein Fehler in der Demo-Firmware sein oder zumindest etwas, das nicht mit dem Verhalten der finalen QuTS Hero-Versionen übereinstimmt. Ich wollte nur teilen, was mir passiert ist, falls noch jemand auf das gleiche Problem stößt.
Die Firmware erstellt den Ordner erst, wenn Sie Container Station zum ersten Mal starten. Dann wird er angelegt. Sie sollten also alles, was Sie erstellt haben, löschen und von vorne beginnen.
Außerdem handelt es sich hierbei nicht um Demo-Firmware, sondern um Beta-Firmware. Das ist ein großer Unterschied.
Das ist mir immer wieder passiert, und das sollte nach einer beträchtlichen Investition in den T464 nicht zu erwarten sein. Als ich ein Support-Ticket eröffnet habe, wurde ich gebeten, etwas zu installieren, das mein Media-Laufwerk lahmgelegt hat (ACL 2.0 wird seit über anderthalb Wochen angewendet). Das ist einfach Mist.
Ich werde ein anderes Betriebssystem darauf installieren, wenn ich keine Stabilität oder die verdammt normale Leistung bekomme, die man von einem QNAP NAS erwarten kann!
Sie testen eine BETA-Version der Software. Das bedeutet, dass möglicherweise nicht alles korrekt funktioniert. Wenn Sie kein unveröffentlichtes Produkt mit potenziellen Fehlern mehr testen möchten, dann wechseln Sie einfach auf eine Produktionsversion von Hero. So einfach ist das.
Ich werde es weiterhin sagen, wenn du nur kommst, um die Hardware und das Unternehmen schlechtzumachen.
Lass mich es wiederholen: Du TESTEST SOFTWARE IM BETA-STADIUM. Das bedeutet, selbst die „Fixes“ könnten nicht funktionieren. Wenn du das Risiko nicht willst, dann teste keine Beta-Versionen. Punkt.
Und außerdem solltest du nicht einfach drauflosreden, wenn du hereinkommst und den Thread eines anderen mit einem völlig anderen Problem übernimmst. Es handelt sich immer noch um Beta-Tests. Wenn du das Produkt schlechtmachen willst, dann tu das in deinem eigenen Mülleimer und nicht hier.