Possible to run Collabora Code docker image with gvisor?

Installation & Configuration
2

hii @4oo4

A few key things in your logs stand out:

  • Failed to stat or chown … Invalid argument missing cap_chown?
    Collabora’s kit process tries to chown() files inside its child jail roots. gVisor deliberately does not support some ownership-changing operations (especially when user namespaces and overlay are involved). Even with --cap-add=CHOWN, gVisor maps syscalls in a restrictive way.
  • ignoring unknown mount option "strictatime", "mode=755", "size=65536k", "newinstance", "ptmxmode=0666" …
    gVisor’s VFS layer doesn’t implement all the mount options the OCI runtime is trying to apply. Normally runc/overlay2 handles these fine, but with runsc you only get what gVisor implements. Overlay and tmpfs options are particularly limited.
  • systemplate … read-only warnings. Collabora’s “systemplate” jail tree is supposed to be writable or at least clonable. gVisor’s semantics around bind mounts and remount flags are not complete, so COOL is forced into slow-copy fallback mode (and then failing because of the chown issue above).

Why this happens

  • Collabora’s design: COOL forks many jailed child processes and does a lot of bind-mount/link/copy work into /opt/cool/child-roots/... to isolate documents. This is pretty mount- and chown-heavy.
  • gVisor’s design: prioritizes syscall isolation and only implements a subset of Linux FS features. It does not aim to fully support overlay2, bind-mount options, or all chown/link semantics. This makes it great for untrusted workloads, but problematic for workloads like Collabora that need low-level FS tricks.

Bottom line

Collabora Online is not well-suited to gVisor today. It depends on filesystem operations that gVisor does not emulate (chown/link/mount flags). You might get it limping along by disabling the jail tree (mount_jail_tree=false) and running with overlay=none, but expect degraded performance and possibly other edge-case crashes.

Thanks
Darshan