OpenClaw som visar Service Unavailable pekar inte ut ett enda fel. I IceWhale Community-tråden från februari 2026 avslöjade felsökningen tre olika lager i följd: en obligatorisk gateway-token, otillräckliga behörigheter för att inspektera Docker från ZimaOS-värdkontot och slutligen en OpenClaw-container som aldrig hade slutfört sin ursprungliga konfiguration.
Tråden är särskilt användbar eftersom vissa mellanliggande förslag visade sig vara felaktiga för Big-Bear-avbilden. Att lägga till en påhittad GATEWAY_MODE miljövariabeln löste inte omstartsloopen, och att lägga till --gateway.mode=local till fel kommando ledde till ett okänd flagga fel. Den aktuella OpenClaw-dokumentationen bekräftar att Saknad konfiguration hör hemma i OpenClaws beständiga konfiguration och att Docker-distributioner bör köra onboarding eller installation för att skapa den konfigurationen.
Kontrollera först om OpenClaw-containern faktiskt körs
Det ursprungliga inlägget visade att OpenClaw-appen rapporterade att applikationen inte kördes korrekt och visade ett tips om OPENCLAW_GATEWAY_TOKEN.
Innan du ändrar applikationsinställningarna bör du inspektera containerns status från ZimaOS- eller CasaOS-värden:
docker ps -a | grep openclawOm containern startas om eller har avslutats kan du läsa loggarna:
docker logs big-bear-openclaw --tail 100Det exakta containernamnet kan skilja sig. Använd docker ps -a för att identifiera det faktiska namnet i stället för att anta att det alltid är big-bear-openclaw.
Generera och lagra OPENCLAW_GATEWAY_TOKEN
Det första förslaget från communityn var att generera en stark slumpmässig gateway-token:
openssl rand -hex 32Om OpenSSL inte är tillgängligt föreslog tråden ett lokalt alternativ för slumpmässiga byte:
head -c 32 /dev/urandom | xxd -p -c 32Den aktuella officiella OpenClaw-Docker-dokumentationen använder också OPENCLAW_GATEWAY_TOKEN för gateway-autentisering. Dess standardinstallationsskript genererar en token och skriver den till distributionens .env filen automatiskt. I en manuellt paketerad CasaOS-applikation anger du det genererade värdet i det miljövariabelfält som avbilden förväntar sig.
Behandla denna token som en hemlighet. Klistra inte in den i ett offentligt forum, en skärmbild, ett supportärende eller ett kodförråd.
Ett Docker-behörighetsfel är inte ett OpenClaw-behörighetsfel
Efter att en token lagts till stötte den ursprungliga författaren på följande:
åtkomst nekas vid försök att ansluta till Dockers daemon-socket
/var/run/docker.sock: anslutning: åtkomst nekas
Communityns rekommendation var att tillfälligt höja behörigheterna innan administrativa Docker-kommandon kördes:
sudo -i
docker psAnvänd root-behörigheter endast för de kommandon som verkligen kräver det. Försvaga inte /var/run/docker.sock behörigheter eller gör Docker-socketen skrivbar för alla bara för att ta bort felet. Åtkomst till Docker ger i praktiken administrativ kontroll över värden.
Det verkliga OpenClaw-felet var ”Konfiguration saknas”
När Docker-loggarna blev åtkomliga visades det viktiga meddelandet:
Konfiguration saknas. Kör `openclaw setup` eller ange gateway.mode=local
Detta var mer handlingsbart än den generiska sidan för tjänsten otillgänglig. OpenClaws aktuella gateway-dokumentation bekräftar att gatewayen normalt vägrar starta om dess konfiguration inte innehåller:
gateway.mode = localAktuella OpenClaw anger också att antingen openclaw-installation eller openclaw onboard --mode local skriver det lokala gateway-läget till den beständiga konfigurationen.
Varför GATEWAY_MODE=local inte löste problemet i denna avbildning
Ett mellanliggande svar från communityn föreslog att lägga till:
Förlita dig inte påAnvändaren provade detta, men omstartsloopen fortsatte. Det är en viktig korrigering att bevara: aktuell officiell OpenClaw-dokumentation definierar inte en generell GATEWAY_MODE miljövariabel som ersättning för den beständiga gateway.mode inställning som används i detta arbetsflöde.
Gör inte om varje punktavgränsad OpenClaw-konfigurationsnyckel till en påhittad miljövariabel med versaler. Använd den konfigurationsmetod som dokumenteras för den exakta OpenClaw-avbildningen eller distributionsmallen.
Varför --gateway.mode=local gav ”Okänd flagga”
Ett senare försök från communityn lade till:
--gateway.mode=locali CasaOS containerkommando. Avbildningen returnerade sedan:
okänd flagga '--gateway.mode'Tråden identifierade korrekt varför: CasaOS lade till flaggan i ett kommandolager som inte accepterade den. OpenClaws aktuella CLI använder kommandon som openclaw gateway, openclaw-installation, openclaw onboardoch openclaw config set; gateway.mode är en konfigurationsnyckel, inte en universell toppnivåflagga som kan placeras var som helst i ett containerkommando.
Big-Bear-avbildningen behövde en beständig, initierad konfigurationskatalog
Den slutliga diagnosen från communityn fokuserade på denna montering:
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawContainern förväntade sig sin konfiguration under /home/node/.openclaw, men den monterade katalogen hade inte initierats. Detta överensstämmer med aktuell OpenClaw-dokumentation för Docker: den monterade konfigurationskatalogen innehåller den beständiga openclaw.json, autentiseringsprofildata och hemligheter från miljövariabler.
Trådens slutliga förslag var att köra konfigurationen inuti containern så att den monterade katalogen skulle få en faktisk OpenClaw-konfiguration. Originalförfattaren återkom dock inte med någon slutlig bekräftelse efter det sista svaret. Betrakta detta som trådens starkaste diagnos, inte som en verifierad slutgiltig lösning.
Föredra aktuell Docker-onboarding för OpenClaw vid en nyinstallation
För en aktuell distribution bör du följa den officiella Docker-installationsguiden för OpenClaw i stället för att återskapa felsökningsförloppet från 2026, ett fel i taget.
OpenClaw tillhandahåller numera ett Docker-installationsskript som:
- bygger eller hämtar gateway-avbildningen;
- kör onboarding;
- genererar en gateway-token;
- skriver beständig konfiguration;
- skapar nödvändiga kataloger för hemligheter;
- startar gatewayen via Docker Compose.
För huvudlös Docker-distribution dokumenterar OpenClaw numera även icke-interaktiv onboarding med lokalt gatewayläge och tokenautentisering. Det är att föredra framför att manuellt hitta på miljövariabler eller lägga till flaggor som inte stöds.
Aktuellt mönster för manuell konfiguration
OpenClaws aktuella Docker-guide dokumenterar ett manuellt mönster som motsvarar:
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanI Docker Compose körs dessa kommandon normalt via den särskilda CLI- eller onboarding-container som definieras av projektet. Klistra inte in värdkommandon i en paketerad CasaOS-avbild utan att först kontrollera dess entrypoint och monteringar.
Den aktuella dokumentationen för OpenClaw Gateway CLI bekräftar att openclaw setup och openclaw onboard --mode local skapar den lokala gateway-konfiguration som krävs.
Använd samma gateway-token i Control UI
Den aktuella Docker-dokumentationen för OpenClaw exponerar Control UI på port 18789 i standardkonfigurationen för Compose och instruerar användarna att klistra in gateway-token från distributionsmiljön i användargränssnittets inställningar.
En token som inte stämmer kan orsaka autentiseringsfel efter att gatewayen fungerar, men det skiljer sig från en container som avslutas upprepade gånger eftersom ingen konfiguration finns. Felsök starten först och därefter autentiseringen i användargränssnittet.
Gör inte --allow-unconfigured till den permanenta lösningen
OpenClaw tillhandahåller --allow-unconfigured för tillfällig start eller utvecklingsstart. Den aktuella dokumentationen säger uttryckligen att den kringgår spärren för lokalt läge utan att skriva eller reparera konfigurationen. Den är användbar för testning, men ersätter inte korrekt onboarding av en permanent server.
Checklista för felsökning av OpenClaw-tjänsten är inte tillgänglig
- Check whether the OpenClaw container is running, exited, or restarting.
- Kontrollera om OpenClaw-containern körs, har avslutats eller startas om upprepade gånger.
- Läs de aktuella containerloggarna innan du ändrar några inställningar.
OPENCLAW_GATEWAY_TOKENBekräfta - finns och behandlas som en hemlighet.
- Om Docker-kommandon misslyckas med behörighetsfel för socketen ska du använda ett auktoriserat administratörsskal i stället för att försvaga behörigheterna för Docker-socketen.
Leta särskilt efterellerSaknad konfigurationgateway.mode=local - fel.
- Bekräfta att värdens AppData-sökväg är monterad till den OpenClaw-konfigurationskatalog som avbildningen förväntar sig.
openclaw.jsonKör OpenClaws stödda installations- eller onboardingflöde så att - skapas i beständig lagring.
Förlita dig inte påsåvida inte dokumentationen för den exakta avbildningen uttryckligen definierar det. - Lägg inte till
--gateway.mode=localtill ett godtyckligt CasaOS-containerkommando. - Starta om containern och kontrollera loggarna igen efter att konfigurationen har skrivits.
- Först när gatewayen förblir igång bör du felsöka tokenautentisering i Control UI eller konfigurationen av modellprovidern.
Vanliga frågor om OpenClaw-tjänsten är otillgänglig
Kräver OpenClaw OPENCLAW_GATEWAY_TOKEN?
Aktuella OpenClaw Docker-distributioner har stöd för och använder vanligtvis OPENCLAW_GATEWAY_TOKEN för autentisering av gatewayen. Det officiella installationsskriptet kan generera en automatiskt. Paketerade avbildningar från tredje part kan exponera värdet på ett annat sätt, så följ avbildningens faktiska miljöschema.
Vad betyder ”permission denied /var/run/docker.sock”?
Det innebär att den aktuella värden inte kan komma åt Docker-daemonen. Det betyder inte i sig att OpenClaws interna datakatalog inte är skrivbar. Använd ett auktoriserat administratörskonto för Docker-diagnostik.
Hur ställer jag in gateway.mode=local?
Använd OpenClaws stödda installations-, onboarding- eller konfigurationskommando så att värdet skrivs till beständig openclaw.json. Den aktuella dokumentationen säger openclaw-installation eller openclaw onboard --mode local skapar den här inställningen.
Bör jag lägga till GATEWAY_MODE=local?
Inte enligt den här tråden. Det förslaget löste inte användarens omstartsloop i den paketerade avbildningen, och den aktuella dokumentationen från uppströmsprojektet anger gateway.mode som konfiguration i stället för som en generell miljövariabel med namnet GATEWAY_MODE.
Varför säger --gateway.mode=local att alternativet är okänt?
Eftersom alternativet lades till i fel kommandolager i CasaOS-paketet. En punktseparerad konfigurationsnyckel är inte automatiskt en giltig kommandoradsflagga för alla OpenClaw-binärfiler eller startpunkter.
Löstes forumtråden definitivt?
Tråden nådde en tydlig slutdiagnos – en oinitierad beständig konfigurationskatalog – och rekommenderade att köra openclaw-installation inuti containern. Det ursprungliga inlägget publicerade ingen slutlig bekräftelse efter den sista instruktionen, så sidan bör inte hävda att problemet löstes verifierat när källan inte innehåller något sådant.
