Community-Lösung

Welche Ports ZimaOS-Apps verwenden: Dockpeek, Docker-Portzuordnung und die Socket-Falle

A January 2026 thread asking for a GUI list of ports used by ZimaOS applications. Community users suggested Docker inspection and Dockpeek; one tester broke Dockpeek by replacing its required /var/run/docker.sock volume, then confirmed reinstalling it with the original socket mapping restored container visibility.

ZimaOS bot in diesem Thread vom Januar 2026 kein eigenes Dashboard für „alle Anwendungsports“, daher griffen die Nutzer auf die Inspektion auf Docker-Ebene und ein Community-App-Store-Tool namens Dockpeek zurück. Dockpeek kann genau die vom ursprünglichen Verfasser gewünschte Übersicht bereitstellen: Containername, Image, veröffentlichte Ports, Status und zugehörige Metadaten in einer einzigen Tabelle.

Der Thread dokumentierte außerdem einen wichtigen Docker-spezifischen Fehler. Ein Nutzer folgte seiner üblichen Vorgehensweise, die Volume-Pfade von Drittanbieter-Apps in /DATA/AppData/... zu ändern, und ersetzte dabei versehentlich das spezielle Docker-Socket-Mount von Dockpeek. Die App ließ sich öffnen, zeigte jedoch keine Container an. Nach einer Neuinstallation, ohne das Socket-Volume zu ändern, wurde die Liste wieder angezeigt.

Ein Portverzeichnis kann zwei verschiedene Bedeutungen haben

Bei Docker-Apps ist es sinnvoll, zwischen folgenden Begriffen zu unterscheiden:

  • Container-Port: der Port, auf dem die Anwendung innerhalb von Docker lauscht;
  • Host-Port: der Port, den ZimaOS auf seiner eigenen Netzwerkschnittstelle bereitstellt.

Eine Zuordnung wie Host 3420 → Container 8000 bedeutet, dass Nutzer den ZimaOS-Host über Port 3420 erreichen, obwohl die Anwendung innerhalb ihres Containers auf Port 8000 lauscht.

Dockpeek bietet eine grafische Übersicht über Container-Ports

Dockpeek-Dashboard mit ZimaOS-Docker-Containern, Images, veröffentlichten Ports und Statusinformationen
Dockpeek bot der Community die gewünschte Übersicht auf einen Blick, welche Docker-Apps welche Host-Ports verwendeten.

Der Quell-Screenshot zeigt Container mit veröffentlichten Ports wie 9100, 8888, 8443, 8090, 8081 und 7580 sowie die zugehörigen Anwendungsnamen und Images.

Ein leeres Dockpeek-Fenster bedeutet nicht, dass Docker keine Container hat

Dockpeek-Dashboard ohne Container, nachdem die Docker-Socket-Zuordnung geändert wurde
Ein Nutzer sah zunächst eine leere Dockpeek-Liste, obwohl auf dem ZimaOS-Server zahlreiche Anwendungen ausgeführt wurden.

Das Problem lag nicht bei der Docker-Erkennung selbst. Dockpeek benötigt Zugriff auf das Unix-Socket von Docker, um den Daemon abfragen zu können.

/var/run/docker.sock muss auf denselben Pfad im Container gemountet bleiben

ZimaOS-Dockpeek-Einstellungen mit dem auf denselben Pfad im Container gemounteten /var/run/docker.sock und DOCKER_HOST unter Verwendung des Unix-Sockets
Dockpeek ist auf das Docker-Socket des Hosts und den passenden Wert von DOCKER_HOST angewiesen, um Container aufzulisten.

Dieses Volume enthält keine Anwendungsdaten. Wird es durch einen normalen AppData-Ordner ersetzt, verliert Dockpeek seine Verbindung zum Docker-Daemon.

Nicht jedes Volume sollte nach AppData verschoben werden

Der Nutzer erklärte, dass ihn Drittanbieterpakete aus dem App Store dazu gebracht hatten, Volume-Pfade genau zu prüfen und persistente Daten in standardisierte AppData-Verzeichnisse zu verschieben. Das ist für Anwendungsdatenbanken und Konfigurationen in der Regel sinnvoll. Spezielle Mounts wie Docker-Sockets, Geräte, Zertifikate oder Systemdateien des Hosts erfüllen jedoch einen anderen Zweck.

Die aktuelle ZimaOS-Dokumentation erklärt, wie normale Anwendungsdaten dem Host-Speicher zugeordnet werden. Verwenden Sie dieses Modell für persistente Daten, ändern Sie jedoch kein spezielles System-Mount, solange Sie nicht verstehen, warum der Container es benötigt.

Ein bereits verwendeter Port muss seinem aktuellen Besitzer zugeordnet werden

Der ursprüngliche Verfasser wollte insbesondere die Ports 80 und 443 freigeben, nachdem zuvor Nginx installiert war. Eine Antwort aus der Community vermutete, dass ZimaOS selbst zumindest Port 80 verwendete. Der Thread enthielt jedoch keine von IceWhale bestätigte Aussage, dass beide Ports in jeder Version dauerhaft reserviert sind.

Bevor Sie eine App löschen oder den Port eines Dashboards ändern, ermitteln Sie den tatsächlichen Listener oder das Docker-Mapping auf dem aktuellen System.

Auch die Docker-CLI kann ein Portverzeichnis erstellen

Ein Community-Mitglied stellte Docker-Befehle vor, die Containernamen, Images und Portzuweisungen auflisten und in eine Textdatei exportieren können. Da diese Befehle von der Community erstellt wurden und keine Anweisungen von IceWhale sind, übernimmt diese Seite lediglich das Konzept, nicht die genaue Shell-Pipeline als offizielles ZimaOS-Verfahren.

Wer das Terminal bevorzugt, kann die zugrunde liegenden Daten über die Container-Inspektion von Docker abrufen, die Dockpeek visualisiert.

Der Zugriff auf das Docker-Socket ist weitreichend

Ein Container, der auf /var/run/docker.sock zugreifen kann, kann den Docker-Daemon inspizieren und je nach Verhalten der Anwendung möglicherweise steuern. Behandeln Sie Dockpeek und ähnliche Verwaltungstools daher als privilegierte Infrastruktur und nicht als gewöhnliche Web-Apps.

Veröffentlichen Sie die Dockpeek-Weboberfläche nicht ohne Authentifizierung und eine geeignete Zugriffskontrollschicht im Internet.

FAQ zur ZimaOS-Portansicht

Kann Dockpeek anzeigen, welche ZimaOS-App einen veröffentlichten Docker-Port verwendet?

Ja. Der Quell-Screenshot zeigt Containername, Images, Portzuordnungen und Status gemeinsam an.

Warum wurden bei einem Nutzer in Dockpeek keine Container angezeigt?

Er hatte das erforderliche Volume /var/run/docker.sock geändert. Eine Neuinstallation, bei der dieses spezielle Mount nicht verändert wurde, stellte die Liste wieder her.

Sollte jedes Volume einer Drittanbieter-App nach /DATA/AppData verschoben werden?

Nein. Persistente Anwendungsdaten gehören häufig dorthin, spezielle Mounts wie das Docker-Socket müssen jedoch die dafür vorgesehene Ressource des Hosts beibehalten.