Possible to run Collabora Code docker image with gvisor?

Installation & Configuration
1

I’m attempting to run Collabora under podman and gvisor, however the container keeps crashing.

Essentially the container fails to chown a directory:

wsd-00001-00001 2025-09-03 21:49:11.597188 +0000 [ coolwsd ] ERR Failed to mount [/opt/cool/systemplate] -> [/opt/cool/child-roots/1-bafe7015/cool_test_mount] readonly| common/JailUtil.cpp:178 wsd-00001-00001 2025-09-03 21:49:11.597432 +0000 [ coolwsd ] ERR Bind-Mounting fails and will be disabled for this run. To disable permanently set mount_jail_tree config entry in coolwsd.xml to false.| common/JailUtil.cpp:454 wsd-00001-00001 2025-09-03 21:49:14.442473 +0000 [ coolwsd ] WRN File not found: Private key file: /etc/coolwsd/proof_key frk-00017-00017 2025-09-03 21:49:24.106857 +0000 [ coolforkit-ns ] WRN The systemplate directory [/opt/cool/systemplate] is read-only, and at least [/opt/cool/systemplate//etc/passwd] is out-of-date. Will have to clone dynamic elements of systemplate to the jails. To restore optimal performance, make sure the files in [/opt/cool/systemplate/etc] are up-to-date.| common/JailUtil.cpp:586 frk-00017-00017 2025-09-03 21:49:24.106957 +0000 [ coolforkit-ns ] WRN Failed to update the dynamic files in [/opt/cool/systemplate]. Will clone dynamic elements of systemplate to the jails.| common/JailUtil.cpp:529 frk-00017-00017 2025-09-03 21:49:24.110635 +0000 [ forkit ] WRN The systemplate directory [/opt/cool/systemplate] is read-only, and at least [/opt/cool/systemplate//etc/passwd] is out-of-date. Will have to clone dynamic elements of systemplate to the jails. To restore optimal performance, make sure the files in [/opt/cool/systemplate/etc] are up-to-date.| common/JailUtil.cpp:586 wsd-00001-00016 2025-09-03 21:49:24.144399 +0000 [ prisoner_poll ] WRN #16: Connection request received on /coolws/forkit endpoint from unexpected ForKit process. Skipped| wsd/COOLWSD.cpp:3114 kit-00022-00022 2025-09-03 21:49:24.209658 +0000 [ kit_spare_001 ] ERR Failed to stat or chown 65534:65534 /opt/cool/child-roots/1-bafe7015//linkable/opt/cool/systemplate/usr/share/zoneinfo/Pacific/Saipan: Invalid argument missing cap_chown?, disabling linkable| kit/Kit.cpp:459 kit-00022-00022 2025-09-03 21:49:24.210047 +0000 [ kit_spare_001 ] ERR link("/opt/cool/systemplate/usr/share/zoneinfo/Pacific/Saipan", "/opt/cool/child-roots/1-bafe7015/QTSgJEYobbXnVQnb/usr/share/zoneinfo/Pacific/Saipan") failed: Invalid argument. Very slow copying path triggered.| kit/Kit.cpp:475 kit-00022-00022 2025-09-03 21:49:27.671184 +0000 [ kit_spare_001 ] WRN Linking/copying files from /opt/collaboraoffice to /opt/cool/child-roots/1-bafe7015/QTSgJEYobbXnVQnb/lo/ is taking too much time. Enabling verbose link/copy logging.| kit/Kit.cpp:505 kit-00022-00022 2025-09-03 21:49:30.723881 +0000 [ kit_spare_001 ] WRN Failed to open /proc/self/smaps_rollup. Memory stats will be slower| kit/Kit.cpp:3645 wsd-00001-00016 2025-09-03 21:49:30.756077 +0000 [ prisoner_poll ] WRN #16: Attempted ping on non-upgraded websocket! #16| net/WebSocketHandler.hpp:638 wsd-00001-00016 2025-09-03 21:49:30.771588 +0000 [ prisoner_poll ] WRN Removing dead spare child [1].| wsd/COOLWSD.cpp:620

Then in gvisor debug logs, it mentions unknown mount options:

runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.753910 1 vfs.go:1018] ignoring unknown mount option "strictatime" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.753915 1 vfs.go:1018] ignoring unknown mount option "mode=755" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.753918 1 vfs.go:1018] ignoring unknown mount option "size=65536k" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.754044 1 vfs.go:1018] ignoring unknown mount option "nodev" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.754677 1 vfs.go:1018] ignoring unknown mount option "nodev" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755557 1 vfs.go:1018] ignoring unknown mount option "newinstance" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755561 1 vfs.go:1018] ignoring unknown mount option "ptmxmode=0666" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755564 1 vfs.go:1018] ignoring unknown mount option "mode=0620" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755567 1 vfs.go:1018] ignoring unknown mount option "gid=5" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755599 1 vfs.go:1018] ignoring unknown mount option "rprivate" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755602 1 vfs.go:1018] ignoring unknown mount option "nodev" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755769 1 vfs.go:1018] ignoring unknown mount option "rprivate" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.755976 1 vfs.go:1018] ignoring unknown mount option "rprivate" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.756130 1 vfs.go:1018] ignoring unknown mount option "rprivate" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.756134 1 vfs.go:1018] ignoring unknown mount option "nodev" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.756137 1 vfs.go:1018] ignoring unknown mount option "relatime" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.756301 1 vfs.go:1018] ignoring unknown mount option "rprivate" runsc.log.20250903-164909.322921.boot.txt:W0903 16:49:09.756439 1 vfs.go:1018] ignoring unknown mount option "rprivate"

As a workaround I tried changing the -overlay2 flag for runsc but didn’t have any luck.

Using the following run command for podman:

/usr/bin/podman run -t -d --name collabora
–runtime=runsc
–runtime-flag=“overlay2=all:memory”
–net podnet
–ip 172.19.0.10
–add-host nextcloud.example.com:10.0.3.9
-e “aliasgroup1=``https://nextcloud.example.com``,``https://nextcloud``\.example\.com|nextcloud\.example\.com:443”
-e “username=${COOL_USER}”
-e “password=${COOL_PASS}”
-e “server_name=``collabora.example.com:443``”
-e “extra_params=–o:ssl.termination=true”
–restart=always
–cap-drop=all
–cap-add=MKNOD
–cap-add=SYS_CHROOT
–cap-add=FOWNER
–cap-add=CHOWN
–subuidname=containers
–subgidname=containers
collabora/code:latest

Has anyone had any success with getting the docker image to work under gvisor? I’m guessing this maybe a gvisor limitation or something with podman (which as I understand doesn’t fully integrate with gvisor like docker does), but I was just curious.

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

3

Great, thank you for the detailed response! Exactly the information I was looking for

1 Like