Issue installing Collabora following official guide

Same for me.

I would really like to read about success stories in the thread I just created. That could help us in finding the solutions.


Hopefully , I have been trying hard to get it working but all in vain.

1 Like

Can you please let me know the redirect ? both for HTTP and HTTPS ?

Hi @Ccandreva, I double @faisalna s demand :slight_smile:

1 Like

Guys any help here ? can please past your vhosts for both office and nextcloud , created the redirects but still issues are same.

One possible solution of connection error may be disabling “allow only for groups x” in the app section.

Cudos to Jakob42 - well, we know what 42 means :slight_smile:

1 Like

I am a little bit confused about my ifconfig output:

docker0   Link encap:Ethernet  HWaddr 02:42:50:5c:d8:21  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::42:50ff:fe5c:d821/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1608 (1.6 KB)  TX bytes:23277 (23.2 KB)

Do I have to change the IP-Address here?
docker run -t -d -p -e "domain=cloud\.nextcloud\.com" --restart always --cap-add MKNOD collabora/code

And what about the vhost config?
> # static html, js, images, etc. served from loolwsd

      # loleaflet is the client part of LibreOffice Online
      ProxyPass           /loleaflet retry=0
      ProxyPassReverse    /loleaflet
      # WOPI discovery URL
      ProxyPass           /hosting/discovery retry=0
      ProxyPassReverse    /hosting/discovery
      # Main websocket
      ProxyPass   /lool/ws      wss://
      # Admin Console websocket
      ProxyPass   /lool/adminws wss://
      # Download as, Fullscreen presentation and Image upload operations
      ProxyPass           /lool
      ProxyPassReverse    /lool

Please let me know how to set these things up properly is localhost. If your base system is setup correctly, this IP address always refers to the local system itself, so if you’re running Collabora there, the IP is correct.

Hi all,
since last update yesterday my nextcloud cannot completely connect to the document. It gives the error “Well, this is embarrassing, we cannot connect to your document. Please try again.”. The docker container seems to run fine and it worked before with the same config. Anyone seeing the same problem?

Check this line in your Apache Config…

Main websocket

ProxyPassMatch “/lool/(.*)/ws$” wss://$1/ws

1 Like

You are not alone. I keep checking daily for updates to either the CODE Docker image or the Collabora Online Nextcloud app. Hopefully this will get resolved soon!

Edit: Ah, got it! Thanks for the clue @Pisoko

Sorry I haven’t been back in a while. This is what I have for vhosts for standard http (https is right out of the docs).

<VirtualHost *:80>
   DocumentRoot /var/www/nextcloud
   RedirectPermanent /
	ErrorLog logs/nextcloud/error_log
	TransferLog logs/nextcloud/access_log

<VirtualHost *:80>
   DocumentRoot /var/www/collabora
   RedirectPermanent /
	ErrorLog logs/collabora/error_log
	TransferLog logs/collabora/access_log

Ubuntu 16.10 users get the following error when starting the the new version :(or previous version actually)
kit-00057-00 00:00:28.213298 [ loolkit ] mknod(/opt/lool/child-roots/57//dev/random) failed. (errno: Operation not permitted)
kit-00057-00 00:00:28.213344 [ loolkit ] mknod(/opt/lool/child-roots/57//dev/urandom) failed. (errno: Operation not permitted)
kit-00057-00 00:00:28.213364 [ loolkit ] chroot("/opt/lool/child-roots/57/")
kit-00057-00 00:00:28.213391 [ loolkit ] chroot("/opt/lool/child-roots/57/") failed. (errno: Operation not permitted)

In Ubuntu 16.10 the kernel configuration CONFIG_AUFS_XATTR=y has been omitted.
$ grep AUFS_X /boot/config-4.8.0-22-generic

grep AUFS_X /boot/config-4.4.0-42-generic

Without CONFIG_AUFS_XATTR docker users using the AUFS driver can not use the image

I finally got my setup working after I was receiving the following error all the time:

BadRequestException: Invalid URI or access denied.

I made sure that all connections to the nextcloud server and/or collabora server where comming from the public IP that matches the DNS names for them, so my working set-up is now:

  • a VPS with Ubuntu 16.04 server running nextcloud (on NGINX) in an LXD container (IP: behind an NGINX reversed proxy (IP: in another LXD container. Subnet for LXD is

  • On the same VPS I have docker installed and runs with docker0 subnet

  • Started the collabora docker container (IP: without the -p settings and used \\ for the domain variable like the guide says (so -e “domain=cloud\\.example\\.com” )

  • iptable rules to apply on the VPS:
    iptables -t nat -I PREROUTING -s -d -p tcp --dport 443 -j DNAT --to
    iptables -t nat -I POSTROUTING -s -d -p tcp --dport 443 -j SNAT --to

the public IP of the VPS stands for and in DNS

Hope this helps someone else as well. The video tutorial hinted me to backtrace the communication flow whereas a home server normally is behind a NAT internet router, which will source NAT addresses from the LAN into it’s public IP and than concludes that it has to forward this traffic back into the LAN to the reversed proxy :wink:

Hi guys,
Installed my collabora/code successfully. Docker is running and the connector works as well.
Until I open or create a document… You know… the known error… (connnecting… couldn’t connect to the document blablabla…)
I checked my apache-settings and they seem to be up to date and correct…

docker log says:

frk-00033-00 00:00:48.639055 [ loolforkit ] Child 84 has exited, removing its jail '/opt/lool/child-roots/84’
wsd-00024-03 00:00:51.660485 [ client_ws_0002 ] getNewChild: No live child, forking more.
wsd-00024-03 00:00:51.660580 [ client_ws_0002 ] getNewChild: No available child. Sending spawn request to forkit and failing.
wsd-00024-03 00:00:51.660667 [ client_ws_0002 ] getNewChild: Have 0 children, forking 1
wsd-00024-03 00:00:51.660730 [ client_ws_0002 ] MasterToForKit: spawn 1
wsd-00024-03 00:00:51.660790 [ client_ws_0002 ] Writing to pipe. Data: [spawn 1].
frk-00033-00 00:00:51.636432 [ loolforkit ] readFIFO for pipe: wsd_pipe_rd returned: 8
frk-00033-00 00:00:51.636473 [ loolforkit ] Read line from pipe: wsd_pipe_rd, line: [spawn 1], data: [].
frk-00033-00 00:00:51.636488 [ loolforkit ] ForKit command: [spawn 1].
frk-00033-00 00:00:51.636508 [ loolforkit ] Spawning 1 child per request.
frk-00033-00 00:00:51.636522 [ loolforkit ] Creating 1 new child.
frk-00033-00 00:00:51.636533 [ loolforkit ] Forking a loolkit process.
frk-00033-00 00:00:51.638347 [ loolforkit ] Forked kit [89].
kit-00089-00 00:00:51.638632 [ loolforkit ] Initializing kit
kit-00089-00 00:00:51.638688 [ loolforkit ] Log level is [8].
kit-00089-00 00:00:51.638775 [ loolkit ] Process started.
kit-00089-00 00:00:51.638909 [ loolkit ] Jail path: /opt/lool/child-roots/89/
kit-00089-00 00:00:51.639212 [ loolkit ] symlink("…/lo","/opt/lool/child-roots/89/opt/collaboraoffice5.1")
kit-00089-00 00:00:51.639857 [ loolkit ] link("/opt/lool/systemplate/etc/resolv.conf","/opt/lool/child-roots/89/etc/resolv.conf") failed. Exiting. (errno: Operation not permitted)

OS is Debian Jessie with Kernel 3.16.0-4.
What can I do? Do I need to update the Kernel (not sure if I should do that, as I’m running PLESK and stuff… and I had some bad problems when upgrading kernel or distro…)

Thanks for any help :slight_smile:

After enabling Collabora for certain user groups, it broke. Try disabling the NC Collabora App and de-install it from the Apps menu. Then install it again and enter the URL again. This made it work again for my installation. Also before that try to run: docker pull collabora/code && docker restart UUID-of-collabora-docker(docker ps shows it)

Hi ezra,

thanks for your suggestions. I tried that already yesterday, but did it again. Also I ran your suggested command to be sure I have the latest collabora/code installed. that is also true.
I also removed the complete docker image and everything…
I did not enable it for certain user groups. Didn’t see that option first :wink:
Oh and in my admin URL I did not put the :9980 port but no port (or 443). 9980 is not working. But without port/443 it runs good. as well the XML (in my case pulls up correct.

No idea what’s wrong here right now :frowning:

Your problem was described above a couple of times, usually it is due to missing AUFS support in the Kernel.

You can check for your Kernel like this: Issue installing Collabora following official guide

If your Kernel doesn’t support AUFS, I’m afraid you either have to update it or find another solution (which probably requires some Docker knowledge).

Hi accolon,
thanks for the suggestion…
I had the hope that this is only for Ubuntu. So I skipped that part first (updating Kernel… uuuh… danger ;)).

but well, I’m going to check that and will update the kernel if necesary.
thanks a lot.


Hi accolon,

I read into a few more things about AUFS. As the post you mentioned only mentions Ubuntu, I thought I’m checking a few things:

  • first of all: Debian does not support the kernel 4.x yet (at least not official, as they’re gonna integrate it in Debian 9 coming stable in february (hopefully) next year.
  • the grep command for my installed linux-kernel does not gives any output, BUT
  • checking if AUFS is supported and running with that documentation:

root@server /boot # grep aufs /proc/filesystems
nodev aufs
meaning, my system IS supporting AUFS correctly.

I got to /etc/default and edited the docker-config there, adding


and checked after starting up docker again

Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 8
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs

So that seems good I guess…

on the other hand I also found something like this while starting dockerd

WARN[0001] Your kernel does not support cgroup memory limit
WARN[0001] Your kernel does not support cgroup cfs period
WARN[0001] Your kernel does not support cgroup cfs quotas

So, before I try to update to a 4.x kernel on a unstable base: do I really need to update to an kernel, I maybe don’t need? As it looks for me, like AUFS is supported correctly…