Skip to content

fix(vm): make /sandbox chown non-fatal for virtiofs rootless hosts#1389

Merged
drew merged 1 commit into
NVIDIA:mainfrom
russellb:fix/vm-chown-nonfatal
May 14, 2026
Merged

fix(vm): make /sandbox chown non-fatal for virtiofs rootless hosts#1389
drew merged 1 commit into
NVIDIA:mainfrom
russellb:fix/vm-chown-nonfatal

Conversation

@russellb
Copy link
Copy Markdown
Contributor

Summary

On Linux non-root hosts, virtiofs maps guest root to the host user, so chown inside the VM is denied. This causes the init script to abort under set -e, preventing the sandbox from starting. Make the chown best-effort so the VM boots successfully.

Related Issue

The /sandbox ownership fix was added in #1176 for macOS hosts where guest root has real root privileges (Hypervisor.framework) and chown succeeds. This PR extends it to handle the Linux non-root case where chown is denied.

Changes

  • Make chown -R /sandbox non-fatal: suppress stderr and log a warning on failure instead of aborting
  • Add comment explaining the macOS vs Linux virtiofs behavior difference

This is a pragmatic workaround — anything that would break due to the failed chown will still break, just later and with a clearer error rather than a cryptic boot failure. In practice the sandbox functions normally because the supervisor sets up its own working directories.

Testing

  • mise run pre-commit passes
  • Verified on a Linux non-root host with the VM driver — sandbox boots successfully, console log shows chown /sandbox denied (virtiofs rootless host), continuing
  • Bypass detection e2e test passes on the VM driver with this fix

Checklist

  • Follows Conventional Commits
  • Commits are signed off (DCO)

On Linux non-root hosts, virtiofs maps guest root to the host user,
so chown inside the VM is denied. This causes the init script to
abort under set -e, preventing the sandbox from starting.

Make the chown best-effort: if it fails, log a warning and continue.
The supervisor's own filesystem preparation handles ownership for the
paths that matter, so the sandbox works correctly without it.

This is a pragmatic workaround — anything that would break due to
the failed chown will still break, just later and with a clearer
error rather than a cryptic boot failure. In practice the sandbox
functions normally because the supervisor sets up its own working
directories.

Signed-off-by: Russell Bryant <russell.bryant@gmail.com>
@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented May 14, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@russellb
Copy link
Copy Markdown
Contributor Author

This is admittedly a hack on top of a hack. It unblocked my testing and I no longer hit errors, but I think this will need to be revisited at some point.

Copy link
Copy Markdown
Collaborator

@drew drew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree it's a hack.

I'm good merging this to keep you unblocked.

I'm working on a fairly large change to how storage here works. Preferring to instead unpack the requested sandbox image inside the guest VM onto a per-sandbox overlay disk.

@drew drew merged commit 0dee90a into NVIDIA:main May 14, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants