bug: Kubernetes sandbox crashes EROFS — recursive chown /sandbox fails on read-only submounts (0.0.82) #2294

Summary

On the Kubernetes driver, the sandbox supervisor performs a recursive chown /sandbox ("Chowning /sandbox for driver-injected UID/GID") during startup. If a read-only volume mount exists at any path under /sandbox (a common pattern for making a workspace subdirectory immutable), the recursive chown hits that read-only mount and aborts with EROFS: Read-only file system. The agent process never starts and the pod goes CrashLoopBackOff.

The same pod spec (with read-only submounts under the workspace) worked on our previous version (~0.0.39-era); it began failing after upgrading to 0.0.82.

Environment

• OpenShell 0.0.82 — gateway ghcr.io/nvidia/openshell/gateway:0.0.82 + its bundled/version-pinned supervisor
• Kubernetes compute driver (in_tree=true)
• Sandbox pods run under gVisor (runsc RuntimeClass)
• server.disableTls: true; policy has landlock.compatibility: best_effort

Steps to reproduce

1. Create a sandbox whose pod mounts a readOnly: true volume (e.g. an emptyDir) at a subpath of the workspace — for example /sandbox/.openclaw/skills — to make that directory immutable.
2. Start the sandbox on 0.0.82 (Kubernetes driver).
3. The agent container crash-loops.

Actual behavior

Supervisor log (protocol noise trimmed); chown /sandbox is the last real operation before teardown:

INFO  openshell_supervisor_process::process: Updated /etc/passwd and /etc/group for sandbox identity
INFO  openshell_supervisor_process::process: Chowning /sandbox for driver-injected UID/GID
DEBUG openshell_supervisor_process::netns: Cleaning up network namespace       # teardown starts
OCSF  CONFIG:CLEANED_UP [INFO] Network namespace cleaned up
Error:   × EROFS: Read-only file system
stream closed: EOF (agent)

The error is a bare EROFS with no path; it correlates exactly with a readOnly mount located under /sandbox. Moving that same read-only mount outside /sandbox (and symlinking it in — chown -R doesn't descend into symlinks / out-of-tree targets) makes the sandbox start normally, which confirms the recursive chown as the cause.

Expected behavior

Chowning a read-only mount is expected to fail; it should not be fatal. The recursive workspace chown should do one of:

• skip paths on read-only filesystems (detect the read-only mount / EROFS and continue), or
• not descend into nested mount points (don't cross filesystem boundaries during the recursive chown), or
• treat a per-entry EROFS as a non-fatal warning.

Why this matters (gVisor)

Making specific workspace subdirectories immutable via read-only mounts is the only option under gVisor: the filesystem_policy read_only mechanism relies on Landlock, which runsc does not implement (OCSF FINDING [HIGH] "Landlock Filesystem Sandbox Unavailable"). So read-only mounts are the sole gVisor-compatible way to enforce per-directory immutability — and they are exactly what this recursive chown breaks.

Workaround

Relocate the read-only mounts outside /sandbox and symlink the in-workspace paths to them (create the symlinks before the agent starts). The recursive chown /sandbox then leaves them alone, and the agent still sees a read-only directory. Verified working on 0.0.82, but it shouldn't be necessary.

Related

• openshell-driver-vm 0.0.39 on macOS: sandbox init's chown -R over virtio-fs fails, VM exits status 1, sandbox never reaches Ready #1356 — sibling recursive chown -R /sandbox failure, but on the VM driver / macOS / virtio-fs (Permission denied); fixed by moving /sandbox onto a writable overlay (PR #1263). That fix does not cover the Kubernetes driver + read-only-submount case reported here.
• prepare_filesystem() should not chown existing directories in read_write #783 — prepare_filesystem() chowning read_write directories (related chown behavior).
• feat: inject sandbox UID via compute driver instead of requiring it in container images #1959 — proposal to inject the sandbox UID via the compute driver instead of chowning, which would remove the need for this recursive chown entirely (appears stale).