16 hours ago
Does Railway V2 reliably support Chromium’s user-namespace sandbox when Chromium runs as a non-root user?
We’re testing Python Playwright 1.63.0 with Chromium 153.0.8010.12, using mcr.microsoft.com/playwright/python:v1.63.0-noble. Chromium runs as pwuser with chromium_sandbox=True and no sandbox-disabling flags.
The environment is a single EU service with 1 vCPU, 2 GB RAM, and restart policy NEVER. Tests are bounded, account-free, one-shot launches against about:blank or local HTML with fresh temporary profiles. There are no credentials, saved sessions, persistent volumes, or public endpoints.
One headed run rendered local HTML successfully, but several launches failed with:
FATAL sandbox/linux/services/credentials.cc:131 Check failed: . : Permission denied (13)
The process then terminated with SIGTRAP. The matching Chromium source points to CheckCloneNewUserErrno, which handles failed CLONE_NEWUSER clone/unshare operations. We haven’t established the exact failing syscall or host policy.
Is this configuration supported reliably? If so, what supported configuration or provider-side change allows it to work while retaining Chromium’s sandbox?
1 Replies
Status changed to Awaiting Railway Response Railway • about 16 hours ago
9 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 9 hours ago
5 hours ago
No. Railway V2 does not reliably support Chromium’s unprivileged user-namespace sandbox because its multi-tenant host kernel restricts CLONE_NEWUSER (EACCES / Permission denied 13).
To run reliably:
- Standard fix: Launch Chromium with
--no-sandbox(since the Railway container already acts as your execution boundary). - If you must keep the sandbox: Switch to a microVM or dedicated host (such as Fly.io or AWS EC2) where you have kernel-level control or can run containers without seccomp/AppArmor namespace restrictions.