Code as an Incus App container

Installation & Configuration
2

Hello @pachulo

I see what’s happening here. You’ve essentially dropped the docker run environment into an Incus/LXD “application container” but Collabora CODE is quite picky about Linux namespaces and capabilities.

From your log:

ERR enterMountingNS, unshare failed: Permission denied
ERR creating usernamespace for mount user failed
ERR Capability cap_sys_chroot is not set
ERR Capability cap_fowner is not set
ERR Capability cap_chown is not set

That’s the root of the problem.

Why it works with Docker but not Incus

  • Docker (or Podman) sets up the container with --cap-add, seccomp tweaks, user namespaces, and AppArmor allowances that Collabora relies on.
  • Incus app containers by default run with a restricted capability set and no unprivileged userns inside. So Collabora fails when trying to set up its jailed child processes (coolforkit, unshare, etc.).

Options you have

  1. Run as a system container instead of application container

    • In Incus you can do:

      incus launch images:debian/12 collabora-code
incus exec collabora-code -- bash
# install docker or podman inside, then run collabora/code

    • This way the container looks like a lightweight VM and you can run CODE inside with the privileges it expects.

  2. Stick with an application container but adjust security

    • Allow nesting and add missing capabilities:

      incus launch docker:collabora/code:latest collabora-code \
  --config security.nesting=true \
  --config security.syscalls.intercept.mknod=true \
  --config security.syscalls.intercept.mount=true \
  --config security.syscalls.intercept.setxattr=true \
  --config raw.lxc="lxc.cap.keep = sys_chroot chown fowner"

    • This gives it the same “extra powers” Docker grants.

    (If you already created the container, you can set those on it with incus config set collabora-code ....)

  3. Disable mount jail in Collabora

    • Inside the container edit /etc/coolwsd/coolwsd.xml and set:

      <mount_jail_tree>false</mount_jail_tree>

    • This bypasses the unshare failure, but you’ll still need cap_sys_chroot, cap_fowner, cap_chown for forkit. Otherwise, documents won’t open.

Suggested path

If your goal is simply to get CODE running under Incus reliably, I’d go with option 1 (system container). That avoids chasing all capability quirks. If you really want to use an application container, you’ll need to grant it those capabilities (option 2).

Thanks
Darshan