[Ubuntu 24.04][Onboard] child-process onboard reports Docker unreachable while the daemon probe succeeds

[mercl-lau]

Description

NemoClaw onboarding launched from a non-interactive Node.js child process reports that Docker is unreachable even though the same user can query the daemon successfully immediately before and after onboarding. The failure occurs before a sandbox or gateway is created.

Platform scope: Reproduced on Ubuntu 24.04 only; other platforms not tested
Regression: Unknown — earlier versions not tested
OpenShell issue: No

Environment

Device:        Ubuntu server
OS:            Ubuntu 24.04.4 LTS
Architecture:  x86_64
Node.js:       Not captured
npm:           Not captured
Docker:        29.5.3
OpenShell CLI: 0.0.101
NemoClaw:      0.0.107
OpenClaw:      N/A (onboard not completed)

Steps to Reproduce

1. Install NemoClaw and OpenShell on an Ubuntu host whose current user belongs to the docker group.

2. Confirm the exact formatted probe succeeds:

   docker info --format '{{json .}}'

3. From a non-interactive Node.js child process, launch:

   nemoclaw onboard --non-interactive --fresh --no-gpu --agent openclaw --yes

   Use a local OpenAI-compatible endpoint and the documented non-interactive custom-provider environment variables.

4. Run the formatted Docker probe again as the same user.

Expected Result

Onboarding recognizes the reachable Docker daemon and proceeds to create the gateway and sandbox.

Actual Result

Docker is not reachable. Please fix Docker and try again.
Docker is installed and the service is running, but the current user cannot reach the daemon.

The formatted Docker probe exits successfully before and after the failed onboarding attempt, returns valid JSON with a non-empty ServerVersion, and reports no ServerErrors.

Logs

Docker is not reachable. Please fix Docker and try again.
Docker is installed and the service is running, but the current user cannot reach the daemon.

[yanyunl1991]

Thanks for the report — I reproduced this on v0.0.107 and it is already fixed on the current main.

Root cause

Before onboarding runs any Docker command, it resolves a Docker "authority". On v0.0.107, when DOCKER_HOST is unset, that resolver returned unix://<first Docker/Podman socket that exists on disk> without probing whether it is reachable, and injected it as DOCKER_HOST for the subsequent docker info probe. On a host with a leftover/inactive rootless Podman socket (/run/user/<uid>/podman/podman.sock) — which sorts ahead of /var/run/docker.sock in the candidate list — onboarding pointed docker info at that dead socket and reported "Docker is not reachable / the current user cannot reach the daemon", even though a plain docker info (using the Docker CLI default) reached the healthy Engine. Launching from a non-interactive child process just makes it easy to hit: the socket-file scan is the same regardless of the launching shell.

Already fixed

#8823 ("fix(cli): preserve healthy Docker authority", Fixes #8816) reworked this: onboarding now probes the Docker CLI default first and preserves it when reachable, only falling back to a local socket after verifying that socket is reachable and identifies as Docker or Podman. #8823 landed after the v0.0.107 tag, so it is on main but not in 0.0.107. This is the same underlying defect as #8816 (there the leftover Podman socket was live, so the runtime was misreported as Podman; here it is a stale socket, so the injected DOCKER_HOST is unreachable).

Verification (our Ubuntu 24.04 x86_64 test host, no GPU; a stale rootless Podman socket present, Docker Engine healthy on the default socket)

• v0.0.107: nemoclaw onboard --non-interactive --fresh --no-gpu --agent openclaw --yes from a Node child process → Docker is not reachable. Please fix Docker and try again. (exit 1), while docker info --format '{{json .}}' succeeds before and after (ServerVersion non-empty, no ServerErrors).
• current main: same host, same stale socket → Docker is running, and onboarding proceeds to create the gateway and sandbox.

Could you re-run against the latest main (or the next release after 0.0.107) and confirm? If you still see it there, please share ls -l /run/user/$(id -u)/podman/podman.sock /var/run/docker.sock, docker context ls, and env | grep -i docker and I'll take another look.

[prekshivyas]

Stale-issue verification — automated

Reported on: v0.0.107
Verified on: v0.0.109 (commit d027b77)
Verification mode: bounded runtime verification on Brev CPU; the same reviewed reproducer (SHA-256 682d6ee310d0635a8c3e8ada4f009160023e8978ffde33a7f99aedbcadf3b4d6) ran against both exact release tags.

Baseline

The installed authority selector chose the stale Podman socket even though the Docker CLI default was healthy.

Newest release

The identical controlled observation preserved the reachable Docker CLI default and ignored the stale socket.

Relevant merged changes: #8823, #9095.

Verdict

Fixed on latest with confidence 65 / 100. This pilot posted proof only; it did not close, label, assign, or change a Project field.

@mercl-lau — please test v0.0.109 or newer and reply with a reproducer if the symptom remains.