Collabora Capabilities Error on Docker

🚧 Installation
1

I’m just upgraded OC10 to NC12 and am trying to setup a Collabora instance to integrate with it.

I’ve been trying to adapt the tutorial to use docker-compose.

When I try to bring it up, I get the following in the logs.

office    | e is 65537 (0x10001)
office    | Signature ok
office    | subject=/C=DE/ST=BW/L=Stuttgart/O=Dummy Authority/CN=localhost
office    | Getting CA Private Key
office    | wsd-00026-00026 08:51:18.197437 [ loolwsd ] ERR  Failed to write to pipe. Data: [setconfig limit_virt_mem_mb 0
office    | setconfig limit_stack_mem_kb 8000
office    | setconfig limit_file_size_mb 50
office    | ]. (errno: Bad file descriptor)| common/IoUtil.cpp:200
office    | loolforkit version details: 2.1.3 - 277d2b8
office    | frk-00028-00028 08:51:18.211782 [ forkit ] ERR  Failed to set RLIMIT_NOFILE to 52428800 bytes. (errno: Operation not permitted)| common/Seccomp.cpp:273
office    | frk-00028-00028 08:51:18.211873 [ forkit ] FTL  Capability cap_sys_chroot is not set for the loolforkit program.| kit/ForKit.cpp:168
office    | frk-00028-00028 08:51:18.211893 [ forkit ] FTL  Capability cap_mknod is not set for the loolforkit program.| kit/ForKit.cpp:168
office    | frk-00028-00028 08:51:18.211899 [ forkit ] FTL  Capability cap_fowner is not set for the loolforkit program.| kit/ForKit.cpp:168
office    | FATAL: Capabilities are not set for the loolforkit program.
office    | If you are on SLES11, please set 'file_caps=1' as kernel boot option.

I did see this thread on the same subject.

My problem is that I already have a lot of AUFS containers running and don’t relish the risk involved in stopping them all, ripping out the file system and then praying that it all comes back up with no issues.

Do we know why AUFS is an issue for CODE? Is there any fix in the works that I can wait for?

2

Same problem here (a lot of old containers, creating using debian 8 but now running debian 9). @Banjo any updates from your side on this? Did you get it working?

Did you try to this to migrate your existing ones?

Edit: Regarding your second last question: I looks like AUFS is somewhat broken. See here and here:

The aufs driver is the oldest, but is based on a Linux kernel patch-set that is unlikely to be merged into the main kernel. These are also known to cause some serious kernel crashes.

3

I bit the bullet and switched it. Mostly seemless, although I did realise there was a small issue with my disaster recovery scheme. I have docker images in a local repository, including my custom SSL proxy. Unfortunately, the images are tagged using the https address which isn’t accessible without the proxy! Oops.

Still, the git server comes from Docker Hub so I could just get that run up, checkout the code and rebuild the docker images that way.

And yes, the other option, which I found afterward, would be to use docker save and docker load to migrate the images across.

Interestingly, the aufs containers are still there and useable. If you switch the /etc/docker/daemon.json flag back to aufs then you can immediately run up the previous instances of our services, in case you forget something. :wink: