OpenClaw mit Service Unavailable weist nicht auf einen einzigen Fehler hin. Im IceWhale-Community-Thread vom Februar 2026 wurden bei der Fehlersuche nacheinander drei verschiedene Ebenen aufgedeckt: ein erforderliches Gateway-Token, unzureichende Berechtigungen zum Inspizieren von Docker über das ZimaOS-Hostkonto und schließlich ein OpenClaw-Container, der seine Erstkonfiguration noch nie abgeschlossen hatte.
Der Thread ist besonders nützlich, weil sich einige zwischenzeitliche Vorschläge für das von Big Bear paketierte Image als falsch herausstellten. Das Hinzufügen einer erfundenen GATEWAY_MODE Eine Umgebungsvariable löste die Neustartschleife nicht, und das Anhängen von --gateway.mode=local Der falsche Befehl führte zu einem unbekannte Option Der aktuelle OpenClaw-Dokumentation zufolge bestätigt der gateway.mode=local in die persistente Konfiguration von OpenClaw und dass Docker-Bereitstellungen das Onboarding oder die Einrichtung ausführen sollten, um diese Konfiguration zu erstellen.
Zuerst prüfen, ob der OpenClaw-Container tatsächlich ausgeführt wird
Der ursprüngliche Beitrag zeigte, dass die OpenClaw-App meldete, die Anwendung werde nicht ordnungsgemäß ausgeführt, und einen Hinweis anzeigte, dass OPENCLAW_GATEWAY_TOKEN.
Bevor du die Anwendungseinstellungen änderst, überprüfe den Containerstatus auf dem ZimaOS- oder CasaOS-Host:
docker ps -a | grep openclawWenn der Container neu gestartet wird oder beendet wurde, lies seine Logs:
docker logs big-bear-openclaw --tail 100Der genaue Containername kann abweichen. Verwende docker ps -a um den tatsächlichen Namen zu ermitteln, statt anzunehmen, dass er immer big-bear-openclaw.
OPENCLAW_GATEWAY_TOKEN generieren und speichern
Der erste Community-Vorschlag war, ein starkes zufälliges Gateway-Token zu generieren:
openssl rand -hex 32Falls OpenSSL nicht verfügbar ist, wurde im Thread eine lokale Alternative zur Erzeugung zufälliger Bytes vorgeschlagen:
head -c 32 /dev/urandom | xxd -p -c 32Auch die aktuelle offizielle Docker-Dokumentation von OpenClaw verwendet OPENCLAW_GATEWAY_TOKEN für die Gateway-Authentifizierung. Das standardmäßige Einrichtungsskript generiert ein Token und schreibt es in die .env Datei automatisch. In einer manuell paketierten CasaOS-Anwendung gib den generierten Wert in das für dieses Image vorgesehene Feld für Umgebungsvariablen ein.
Behandle dieses Token als Geheimnis. Füge es nicht in ein öffentliches Forum, einen Screenshot, ein Support-Ticket oder ein Repository ein.
Ein Docker-Berechtigungsfehler ist kein OpenClaw-Berechtigungsfehler
Nachdem ein Token hinzugefügt worden war, stellte der ursprüngliche Autor fest:
Berechtigung beim Versuch verweigert, eine Verbindung mit dem Docker-Daemon-Socket herzustellen
/var/run/docker.sock: Verbindung verweigert: Berechtigung verweigert
Die Empfehlung der Community lautete, vorübergehend erhöhte Berechtigungen zu verwenden, bevor administrative Docker-Befehle ausgeführt werden:
sudo -i
docker psVerwende Root-Berechtigungen nur für Befehle, die sie tatsächlich benötigen. Schwäche die /var/run/docker.sock Ändere nicht einfach Berechtigungen und mache den Docker-Socket nicht weltweit beschreibbar, nur um den Fehler zu beseitigen. Der Zugriff auf Docker gewährt effektiv administrative Kontrolle über den Host.
Der eigentliche OpenClaw-Fehler lautete „Missing config“
Sobald auf die Docker-Protokolle zugegriffen werden konnte, erschien die wichtige Meldung:
Missing config. Run `openclaw setup` or set gateway.mode=local
Dies war hilfreicher als die allgemeine Seite „Service Unavailable“. Die aktuelle OpenClaw-Gateway-Dokumentation bestätigt, dass das Gateway normalerweise nicht startet, wenn seine Konfiguration nicht Folgendes enthält:
gateway.mode = localIn der aktuellen OpenClaw-Dokumentation steht außerdem, dass entweder openclaw-Einrichtung oder openclaw onboard --mode local schreibt den lokalen Gateway-Modus in die dauerhafte Konfiguration.
Warum GATEWAY_MODE=local dieses Image nicht reparierte
Eine zwischenzeitliche Antwort aus der Community schlug vor, Folgendes hinzuzufügen:
GATEWAY_MODE=localDer Benutzer versuchte dies, doch die Neustartschleife wurde fortgesetzt. Diese wichtige Korrektur muss erhalten bleiben: Die aktuelle offizielle OpenClaw-Dokumentation definiert keine generische GATEWAY_MODE Umgebungsvariable als Ersatz für die dauerhafte gateway.mode Einstellung, die in diesem Ablauf verwendet wird.
Wandle nicht jeden punktgetrennten OpenClaw-Konfigurationsschlüssel in eine erfundene Umgebungsvariable in Großbuchstaben um. Verwende die Konfigurationsmethode, die für das jeweilige OpenClaw-Image oder die jeweilige Bereitstellungsvorlage dokumentiert ist.
Warum --gateway.mode=local „Unknown option“ ergab
Ein späterer Versuch der Community hängte Folgendes an:
--gateway.mode=localan den CasaOS-Containerbefehl an. Das Image gab anschließend Folgendes zurück:
unknown option '--gateway.mode'Der Thread identifizierte den Grund korrekt: CasaOS hängte den Parameter an eine Befehlsebene an, die ihn nicht akzeptierte. Die aktuelle OpenClaw-CLI verwendet Befehle wie openclaw gateway, openclaw-Einrichtung, openclaw onboardund openclaw config set; gateway.mode ist ein Konfigurationsschlüssel und kein universeller Laufzeitparameter auf oberster Ebene, der an beliebiger Stelle in einem Containerbefehl platziert werden kann.
Das Big-Bear-Image benötigte ein dauerhaftes, initialisiertes Konfigurationsverzeichnis
Die abschließende Diagnose der Community konzentrierte sich auf dieses Mount:
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawDer Container erwartete seine Konfiguration unter /home/node/.openclaw, das eingebundene Verzeichnis jedoch noch nicht initialisiert worden war. Dies stimmt mit der aktuellen OpenClaw-Docker-Dokumentation überein: Das eingebundene Konfigurationsverzeichnis enthält die dauerhaften openclaw.json, Authentifizierungsprofildaten und umgebungsvariablenbasierte Geheimnisse.
Der abschließende Vorschlag im Thread bestand darin, die Einrichtung innerhalb des Containers auszuführen, damit das eingebundene Verzeichnis eine tatsächliche OpenClaw-Konfiguration erhält. Der ursprüngliche Verfasser meldete sich nach dieser letzten Antwort jedoch nicht mehr mit einer abschließenden Bestätigung. Betrachte dies daher als stärkste Diagnose im Thread, nicht als verifizierte endgültige Lösung.
Bei einer Neuinstallation sollte das aktuelle OpenClaw-Docker-Onboarding bevorzugt werden
Folgen Sie bei einer aktuellen Bereitstellung dem offiziellen OpenClaw-Docker-Installationsleitfaden, statt die Fehlerbehebungssequenz für 2026 Fehler für Fehler nachzubilden.
OpenClaw stellt aktuell ein Docker-Einrichtungsskript bereit, das:
- erstellt das Gateway-Image oder lädt es herunter;
- führt das Onboarding aus;
- generiert ein Gateway-Token;
- schreibt eine persistente Konfiguration;
- erstellt die erforderlichen Verzeichnisstrukturen für Geheimnisse;
- startet das Gateway über Docker Compose.
Für eine headless Docker-Bereitstellung dokumentiert OpenClaw aktuell außerdem ein nicht interaktives Onboarding mit lokalem Gateway-Modus und Token-Authentifizierung. Das ist vorzuziehen, wenn es darum geht, Umgebungsvariablen manuell zu erfinden oder nicht unterstützte Flags anzuhängen.
Aktuelles Muster für die manuelle Konfiguration
Der aktuelle Docker-Leitfaden von OpenClaw beschreibt ein manuelles Muster, das Folgendem entspricht:
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanIn Docker Compose werden diese Befehle normalerweise über den dedizierten CLI- oder Onboarding-Container ausgeführt, der vom Projekt definiert wird. Fügen Sie Befehle auf dem Host nicht in ein vorgefertigtes CasaOS-Image ein, ohne zuvor dessen Entrypoint und Mounts zu prüfen.
Die aktuelle Dokumentation zur OpenClaw-Gateway-CLI bestätigt, dass openclaw setup und openclaw onboard --mode local die erforderliche lokale Gateway-Konfiguration erstellen.
Verwenden Sie dasselbe Gateway-Token in der Control UI
Die aktuelle OpenClaw-Docker-Dokumentation stellt die Control UI auf Port 18789 in der standardmäßigen Compose-Konfiguration und weist Benutzer an, das Gateway-Token aus der Bereitstellungsumgebung in die UI-Einstellungen einzufügen.
Eine Token-Diskrepanz kann zu Authentifizierungsfehlern führen, nachdem das Gateway betriebsbereit ist. Sie unterscheidet sich jedoch von einem Container, der wiederholt beendet wird, weil keine Konfiguration vorhanden ist. Diagnostizieren Sie zuerst den Start und anschließend die UI-Authentifizierung.
Machen Sie --allow-unconfigured nicht zur dauerhaften Lösung
OpenClaw bietet --allow-unconfigured für einen spontanen oder Entwicklungsstart. In der aktuellen Dokumentation wird ausdrücklich darauf hingewiesen, dass damit die Prüfung des lokalen Modus umgangen wird, ohne die Konfiguration zu schreiben oder zu reparieren. Das ist für Tests nützlich, ersetzt jedoch nicht die ordnungsgemäße Einrichtung eines persistenten Servers.
Checkliste zur Fehlerbehebung: OpenClaw-Dienst nicht verfügbar
- Prüfen Sie, ob der OpenClaw-Container läuft, beendet wurde oder neu gestartet wird.
- Lesen Sie die aktuellen Containerprotokolle, bevor Sie Einstellungen ändern.
- Bestätigen Sie
OPENCLAW_GATEWAY_TOKENvorhanden ist und als Geheimnis behandelt wird. - Wenn Docker-Befehle aufgrund verweigerter Berechtigungen für den Socket fehlschlagen, verwenden Sie eine autorisierte Administratorshell, anstatt die Berechtigungen des Docker-Sockets zu lockern.
- Suchen Sie gezielt nach
Fehlende Konfigurationodergateway.mode=localFehler. - Bestätigen Sie, dass der AppData-Pfad des Hosts in das von dem Image erwartete OpenClaw-Konfigurationsverzeichnis eingebunden ist.
- Führen Sie den unterstützten Einrichtungs- bzw. Onboarding-Ablauf von OpenClaw aus, damit
openclaw.jsonwird im persistenten Speicher erstellt. - Verlassen Sie sich nicht auf
GATEWAY_MODE=localan, sofern die Dokumentation des genauen Images dies nicht ausdrücklich definiert. - Hängen Sie nicht
--gateway.mode=localan einen beliebigen CasaOS-Containerbefehl. - Starten Sie den Container neu und überprüfen Sie die Protokolle erneut, nachdem die Konfiguration geschrieben wurde.
- Erst wenn das Gateway dauerhaft läuft, sollten Sie die Token-Authentifizierung der Control UI oder die Konfiguration des Modellanbieters untersuchen.
FAQ zur Nichtverfügbarkeit des OpenClaw-Dienstes
Benötigt OpenClaw OPENCLAW_GATEWAY_TOKEN?
Aktuelle OpenClaw-Docker-Bereitstellungen unterstützen und verwenden häufig OPENCLAW_GATEWAY_TOKEN für die Gateway-Authentifizierung. Das offizielle Einrichtungsskript kann automatisch einen solchen Token generieren. Paketierte Images von Drittanbietern können den Wert anders bereitstellen. Folgen Sie daher dem tatsächlichen Umgebungsvariablen-Schema des Images.
Was bedeutet „permission denied /var/run/docker.sock“?
Das bedeutet, dass der aktuelle Hostbenutzer nicht auf den Docker-Daemon zugreifen kann. Es bedeutet nicht automatisch, dass das interne Datenverzeichnis von OpenClaw nicht beschreibbar ist. Verwenden Sie für die Docker-Diagnose ein autorisiertes Administratorkonto.
Wie setze ich gateway.mode=local?
Verwenden Sie den unterstützten Einrichtungs-, Onboarding- oder Konfigurationsbefehl von OpenClaw, damit der Wert in den persistenten openclaw.json. In der aktuellen Dokumentation heißt es openclaw-Einrichtung oder openclaw onboard --mode local erstellt diese Einstellung.
Soll ich GATEWAY_MODE=local hinzufügen?
Nicht auf Grundlage dieses Threads. Dieser Vorschlag löste die Neustartschleife des paketierten Images nicht, und die aktuelle Upstream-Dokumentation behandelt gateway.mode als Konfiguration und nicht als generische Umgebungsvariable namens GATEWAY_MODE.
Warum wird --gateway.mode=local als unbekannte Option angezeigt?
Weil die Option in der CasaOS-Paketierung an die falsche Befehlsebene angehängt wurde. Ein Konfigurationsschlüssel mit Punkten ist nicht automatisch für jede OpenClaw-Binärdatei oder jeden Einstiegspunkt ein gültiges Befehlszeilenargument.
Wurde der Community-Thread definitiv gelöst?
Der Thread kam zu einer eindeutigen abschließenden Diagnose – ein nicht initialisiertes persistentes Konfigurationsverzeichnis – und empfahl, Folgendes auszuführen: openclaw-Einrichtung im Container. Der ursprüngliche Verfasser veröffentlichte nach dieser letzten Anweisung keine abschließende Bestätigung. Daher sollte die Seite keine verifizierte Lösung behaupten, die in der Quelle nicht enthalten ist.
