Linux Podman setup issues/confusion | Friends of the Crustacean 🦞🤝 | Page 1

lean martenBOT Feb 18, 2026, 6:51 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

gentle nightBOT Feb 18, 2026, 6:56 AM

#

If you follow the Podman guide as-written, the “default”/recommended setup is:

1) Which user should the container run as?

As the dedicated openclaw user. ./setup-podman.sh creates that user and the launch script (./scripts/run-openclaw-podman.sh launch) will re-exec via sudo -u openclaw ..., so the container ends up in that user’s rootless Podman.

Quick sanity check:

sudo -u openclaw podman ps
# (and compare to:)
podman ps

Docs: https://docs.openclaw.ai/install/podman (see “The openclaw user (non-login)”)

2) Where are the config files held?

In the openclaw user’s home, by default:

#

/home/openclaw/.openclaw/openclaw.json
/home/openclaw/.openclaw/.env ← contains OPENCLAW_GATEWAY_TOKEN
/home/openclaw/.openclaw/workspace/ ← persistent workspace volume

Docs: https://docs.openclaw.ai/install/podman (see “Environment and config”)

You can run everything under your own user instead, but then you need to mount your ~/.openclaw and make ownership match (the docs call this out as “Optional: run as your own user”).

3) “device token mismatch” — what usually causes it in this setup

In practice, with Podman this often happens when you accidentally mix up tokens/config from different users:

you start the gateway as openclaw
but you paste a token from your ~/.openclaw/.env (or from an earlier run) into the Control UI

Fixes to try:

Open the UI locally (most reliable):

#

http://127.0.0.1:18789/

Copy the token from the openclaw config dir:
sudo -u openclaw cat /home/openclaw/.openclaw/.env
…and paste that OPENCLAW_GATEWAY_TOKEN into Control UI settings.
If it keeps looping: clear the site data for that dashboard origin (localStorage can cache an old token/device identity) and reconnect.

(Control UI auth background: https://docs.openclaw.ai/web/control-ui and troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting)

4) Hooking it up to other containers (Ollama / ComfyUI)

Key gotcha: from inside the OpenClaw container, 127.0.0.1 is the container itself, not your host.

So you generally do one of these:

Put OpenClaw + Ollama + ComfyUI on the same Podman network, and refer to them by container name (best container-to-container story), or
Expose Ollama/ComfyUI on the host and point OpenClaw at a host-reachable address (often host.containers.internal on Podman), or

#

Use Quadlet and add the right network settings there (cleaner than editing the run script long-term).

For Ollama specifically, OpenClaw’s auto-discovery assumes http://127.0.0.1:11434 — that won’t “just work” from inside the container unless Ollama is reachable there. You’ll likely want an explicit models.providers.ollama.baseUrl pointing at wherever Ollama is reachable. Docs: https://docs.openclaw.ai/providers/ollama

If you paste:

whether Ollama is on the host vs in another container, and
where you see “device token mismatch” (Control UI toast? gateway logs?) + which URL you opened the UI on (127.0.0.1 vs LAN IP),
I can point you to the exact cleanest networking/config approach for your layout.

spare sonnet Feb 19, 2026, 6:59 PM

#

gentle night If you follow the Podman guide as-written, the “default”/recommended setup is: ...

after running ./scripts/run-openclaw-podman.sh launch setup successfully, at the end I got this and no running podman container

Health check failed: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: loopback

gentle nightBOT Feb 19, 2026, 7:06 PM

#

A couple Podman-specific gotchas here:

1) “No running container” can be totally expected (and/or you’re checking the wrong user)

./scripts/run-openclaw-podman.sh launch setup runs the onboarding wizard in a one-off container (podman run --rm ... onboard). When it exits, that container is removed → you won’t see a long-running container.
The actual long-running gateway is started with:

./scripts/run-openclaw-podman.sh launch

Also: the default flow runs everything under the dedicated openclaw user, so containers live in that user’s rootless Podman store. If you run podman ps as your user, you’ll see nothing.

Check with:

sudo -u openclaw podman ps -a
sudo -u openclaw podman ps

#

That output is consistent with one specific thing: launch setup does not leave a gateway container running.

Why you see “no running podman container”

./scripts/run-openclaw-podman.sh launch setup runs the onboarding wizard as an ephemeral container (podman run --rm ... node dist/index.js onboard). When it finishes, the container is removed → so podman ps won’t show anything afterward.

Why the health check fails (1006)

At the end, the wizard tries to do a health check against a gateway at ws://127.0.0.1:18789. If you haven’t started the actual gateway container yet, that check can fail with the generic websocket “1006 abnormal closure”.

What to run next

Start the real gateway container (this is the one that should stay up):

./scripts/run-openclaw-podman.sh launch

Then check containers as the openclaw user (important with rootless Podman):

#

2) Where config/workspace live (host vs container)

With the default setup, host files live in:

Config: /home/openclaw/.openclaw/openclaw.json
Env (token, provider keys): /home/openclaw/.openclaw/.env
Workspace: /home/openclaw/.openclaw/workspace/

Those are bind-mounted into the container at /home/node/.openclaw/... (that’s why your error mentions /home/node/.openclaw/openclaw.json).

(Ref: https://docs.openclaw.ai/install/podman)

3) Your specific error: `Health check failed: gateway closed (1006 …)`

That means the wizard tried to talk to a gateway and the websocket got closed unexpectedly. The next step is to see container logs for the gateway process.

Run this and paste the output (redact tokens/secrets):

openclaw --version

#

sudo -u openclaw podman ps
sudo -u openclaw podman logs -f openclaw

If it’s exiting immediately, grab the tail:

sudo -u openclaw podman ps -a --filter name=openclaw
sudo -u openclaw podman logs --tail=200 openclaw

About `/home/node/.openclaw/...` in the message

That path is inside the container. It’s bind-mounted from the host (typically /home/openclaw/.openclaw/...), so seeing /home/node/.openclaw/openclaw.json in messages is normal in the Podman flow.

Docs reference: https://docs.openclaw.ai/install/podman

#


# start the real gateway container
./scripts/run-openclaw-podman.sh launch

# see if it’s up (as the right user!)
sudo -u openclaw podman ps -a
sudo -u openclaw podman logs --tail=200 openclaw

If podman ps shows it immediately exits, also paste:

sudo -u openclaw podman inspect openclaw --format '{{.State.Status}} {{.State.ExitCode}}'

Common causes on Arch/rootless Podman:

missing /etc/subuid + /etc/subgid entries for openclaw (setup prints a warning about this)

#

If you paste the podman logs --tail=200 openclaw output (redact tokens), I can tell you whether the gateway is starting cleanly or crashing for a specific reason.

#

permissions/ownership mismatch on /home/openclaw/.openclaw (container runs with --userns=keep-id)

4) “device token mismatch”

That one is usually Control UI/browser state (stale device token in the browser vs what the gateway expects). Quick fix is typically:

hard refresh, or open the dashboard in a private window
clear site data for http://127.0.0.1:18789

But let’s first get the gateway actually staying up.

5) Ollama/comfyui integration tip (container networking)

If Ollama is running on the host, the gateway container can’t reach it via 127.0.0.1 (that would be “inside the container”). In Podman, use:

host.containers.internal

So for Ollama you’d set models.providers.ollama.baseUrl to:
http://host.containers.internal:11434/v1
Docs: https://docs.openclaw.ai/providers/ollama

#

Post the podman logs tail and we can pinpoint why the gateway is closing.

spare sonnet Feb 19, 2026, 9:10 PM

#

@gentle night the image is running. However, in the openclaw gateway dashboard I get disconnected (1008): pairing required. I think I need to do openclaw devices list and openclaw security audit --deep but how?

gentle nightBOT Feb 19, 2026, 9:15 PM

#

disconnected (1008): pairing required in the Control UI means: your browser/device identity needs a one-time approval in the gateway’s device-pairing store. The gateway token/password alone isn’t enough.

Approve the browser (Podman / dedicated `openclaw` user)

Because the Podman guide stores state under /home/openclaw/.openclaw, run the CLI as the openclaw user:

sudo -u openclaw -H openclaw devices list

You should see a pending request with a requestId. Approve it:

sudo -u openclaw -H openclaw devices approve <requestId>

Then reload the dashboard tab; it should stop disconnecting.

#

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection
(also CLI ref: https://docs.openclaw.ai/cli/devices)

Run the security audit (deep)

Same deal — run it against the same state/config (so: as openclaw):

sudo -u openclaw -H openclaw security audit --deep

If any of these commands say “can’t connect” or “unauthorized”, paste the exact output (redact tokens), plus:

openclaw --version
sudo -u openclaw podman logs --tail=200 openclaw

(And don’t post your gateway token in the channel.)

spare sonnet Feb 19, 2026, 9:17 PM

#

@gentle night both commands for security and devices return:
sudo: openclaw: command not found

gentle nightBOT Feb 19, 2026, 9:19 PM

#

That means the OpenClaw CLI isn’t installed on the host (so there’s no openclaw binary in PATH). In the Podman flow you can just run the CLI inside the running gateway container.

First, confirm the container name (usually openclaw):

sudo -u openclaw podman ps

Run the devices commands inside that container:

sudo -u openclaw podman exec -it openclaw node dist/index.js devices list
sudo -u openclaw podman exec -it openclaw node dist/index.js devices approve <requestId>

And your security audit:

sudo -u openclaw podman exec -it openclaw node dist/index.js security audit --deep

#

Then reload the Control UI tab — the “(1008): pairing required” disconnect should be gone after approval.

Docs for the pairing flow: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection

If podman ps shows a different container name, paste that line and I’ll adapt the commands.

spare sonnet Feb 19, 2026, 9:23 PM

#

@gentle night sudo -u openclaw podman exec -it openclaw node dist/index.js devices list returns

gateway connect failed: Error: unauthorized: device token mismatch (rotate/reissue device token)

[openclaw] CLI failed: Error: gateway closed (1008): unauthorized: device token mismatch (rotate/reissue device token)
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: loopback
at Object.onClose (file:///app/dist/call-pduzpefz.js:439:10)
at WebSocket.<anonymous> (file:///app/dist/client-hc4zXmLk.js:1538:23)
at WebSocket.emit (node:events:519:28)
at WebSocket.emitClose (/app/node_modules/.pnpm/ws@8.19.0/node_modules/ws/lib/websocket.js:273:10)
at Socket.socketOnClose (/app/node_modules/.pnpm/ws@8.19.0/node_modules/ws/lib/websocket.js:1346:15)
at Socket.emit (node:events:519:28)
at TCP.<anonymous> (node:net:346:12)

gentle nightBOT Feb 19, 2026, 9:27 PM

#

That error means the CLI inside the container is trying to authenticate with a stale “device token” (cached on disk), and the gateway rejects it.

Fix is: run the devices command using the gateway shared token (so it doesn’t use the stale device token), then approve the pending Control UI browser device.

1) Run `devices list` using the gateway token (without printing it)

sudo -u openclaw podman exec -it openclaw sh -lc '
set -a
[ -f /home/node/.openclaw/.env ] && . /home/node/.openclaw/.env
node dist/index.js devices list --token "$OPENCLAW_GATEWAY_TOKEN"
'

2) Approve the pending request (the one from your browser / Control UI)

sudo -u openclaw podman exec -it openclaw sh -lc '

#

set -a
[ -f /home/node/.openclaw/.env ] && . /home/node/.openclaw/.env
node dist/index.js devices approve <requestId> --token "$OPENCLAW_GATEWAY_TOKEN"
'

Reload the dashboard tab after approving — the “(1008): pairing required” disconnect should stop.

If you still get “device token mismatch”

Nuke the cached device token file and try step (1) again:

sudo -u openclaw podman exec -it openclaw sh -lc '
mv /home/node/.openclaw/identity/device-auth.json /home/node/.openclaw/identity/device-auth.json.bak 2>/dev/null || true
'

#Linux Podman setup issues/confusion