Issue installing Collabora following official guide

127.0.0.1 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://127.0.0.1:9980/lool/$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>
   ServerName nextcloud.foo.com
   DocumentRoot /var/www/nextcloud
   RedirectPermanent / https://nextcloud.foo.com/
	ErrorLog logs/nextcloud/error_log
	TransferLog logs/nextcloud/access_log
</VirtualHost>

<VirtualHost *:80>
   ServerName collabora.foo.com
   DocumentRoot /var/www/collabora
   RedirectPermanent / https://collabora.foo.com/
	ErrorLog logs/collabora/error_log
	TransferLog logs/collabora/access_log
</VirtualHost>

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.
Test:
16.10
$ grep AUFS_X /boot/config-4.8.0-22-generic
CONFIG_AUFS_XATTR is not set

16.04:
grep AUFS_X /boot/config-4.4.0-42-generic
CONFIG_AUFS_XATTR=y

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: 10.10.0.90) behind an NGINX reversed proxy (IP: 10.10.0.80) in another LXD container. Subnet for LXD is 10.10.0.0/24

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

  • Started the collabora docker container (IP: 10.10.1.2) 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 10.10.0.0/16 -d -p tcp --dport 443 -j DNAT --to 10.10.0.80
    iptables -t nat -I POSTROUTING -s 10.10.0.0/16 -d 10.10.0.80 -p tcp --dport 443 -j SNAT --to

the public IP of the VPS stands for cloud.example.com and office.example.com 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:
Chris

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 https://office.matthaeus-augsburg.de/hosting/discovery) 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.

Chris

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: https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/
    shows:

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

DOCKER_OPTS="–storage-driver=aufs"

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…

Greetings,
Chris

Okay guys…
I switched from aufs to devicemapper as a driver…
and now… well… it works :wink:

Still having this Error

Well, this is embarrassing, we cannot connect to your document. Please try again.

somehow the behavior of apache feels strange to me when I test the reverse proxy page in my browser I’ll get a page which shouldn’t be there.

@Christoph_Geiser I had to upgrade my kernel on Debian Jessie 8.6 to 4.7. It then finally worked for me.

I tried almost everything needed before trying that, I think the only thing I changed after the kernel upgrade was disabling groups for the app.

Hm, I’m still not sure if I really want to update the kernel.
Using devicemapper as device driver (ans xfs as filesystem) works, but not sure if that is the best option…
Also: bigger excel lists (several sheets and more than 100 rows and about 20 columns) are quite slow. If I edit some stuff in the cells sometimes I need to hit save that the changes are visible.

dear sir could you explain how did you switch from auf to devicemapper
i think i haveto do same but i dont have any idea
thanks

I read through this topic and I think we should close this topic for several reasons:

  • the initial problem has been solved very quickly but people continued to post whatever problem they had with collabora and nextcloud.
  • a lot of these problems have also found their way in tutorial and documentation improvements
  • it is extremely difficult to keep track of individual problem if everything is mixed up (and for people having a similar problem to find out what finally solved this problem)

This does not mean that there are no problems or everything has been solved. For new problems open new topics. If you follow up an existing discussion, your problem and symptoms have to match the original post.

2 Likes