Bug type: Behavior bug (incorrect output/state without crash)

Summary

setup-podman.sh fails during the podman load step with cannot chdir to <cwd>: Permission denied when the script is run from a directory that the newly-created openclaw user cannot access (e.g. a user's home directory or repo checkout).

Steps to reproduce

1. Clone the repo into a directory not accessible to other users (e.g. ~/openclaw-attempt/openclaw/openclaw).
2. Run sudo ./setup-podman.sh --quadlet from that directory.
3. Watch the build succeed but podman load fail.

Expected behavior

setup-podman.sh completes successfully regardless of the working directory it was invoked from.

Actual behavior

Loading image into openclaw's Podman store...
Using temporary image dir: /var/tmp
[... blob copying succeeds ...]
cannot chdir to /home/<user>/openclaw-attempt/openclaw/openclaw: Permission denied
Error: setting up the process

Root cause

At line ~270, the script runs:

cat "$TMP_IMAGE" | run_as_user "$OPENCLAW_USER" env HOME="$OPENCLAW_HOME" podman load

run_as_user calls sudo -u openclaw, which inherits the calling shell's working directory. Since openclaw is a nologin user with no access to the caller's cwd, podman fails immediately when it tries to verify the inherited cwd.

Fix

Wrap the call in a subshell that first cds to a world-accessible directory:

(cd "${TMPDIR:-/tmp}" && cat "$TMP_IMAGE" | run_as_user "$OPENCLAW_USER" env HOME="$OPENCLAW_HOME" podman load)

$TMP_IMAGE is always an absolute path (created via mktemp -d) so the cd does not affect cat.

OpenClaw version: main (post ec817b48d)

Operating system: Fedora 43 / Linux (reproduced; likely affects any Linux host where the invoking user's cwd is not world-accessible)

Install method: ./setup-podman.sh --quadlet from repo root

Impact and severity

• Affected: anyone running setup-podman.sh from a private directory (standard for most home directory checkouts)
• Severity: blocks initial setup completely — the image cannot be loaded into the openclaw user's Podman store
• Frequency: 100% repro when cwd is not world-accessible (the common case)
• Consequence: failed onboarding; user must manually work around by cd /tmp before running the script