Collabora 404 on /lool/.*/ws empty page

Hi there,

I tried to install Collabora Online on my Nextcloud (12.0.0) following the instructions here : https://nextcloud.com/collaboraonline.

At first I had an issue with docker similar to Collabora Docker capabilities problem, I switched to devicemapper as explained and it fixed this part of the bug.

Now when I click on an office file on my nextcloud, it opens and empty Collabora page, as shown in this screenshot:

No errors are displayed, but if I look at the console log I found that the exange with the office hosts ends with two 404 errors on the following address:
https://office.domain.fr/lool/https://nextcloud.domain.fr/index.php/apps/richdocuments/wopi/files/FILEID?access_token=TOKEN&access_token_ttl=0&permission=edit/ws

When I directly access this url on my browser I haven’t a 404 but:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /lool/https://nextcloud.domain.fr/index.php/apps/richdocuments/wopi/files/FILEID.

Reason: Error reading from remote server

[edit]
Nothing appears in the logs when I use nextcloud normally, however when I access directly to the faulty url, I got the following error on the docker’s log:

wsd-00026-00034 12:23:39.149842 [ websrv_poll ] ERR  #20 Exception while processing incoming request: [GET /lool/https://nextcloud.domain.fr/index.php/apps/richdocuments/wopi/files/58_o...]: Syntax error| wsd/LOOLWSD.cpp:1665<something_that_look_like_an_id>&access_token_ttl=0&permission=edit/ws HTTP/1.1

[/edit]

I tried to restart my docker using differents values from -e 'domain=...', including -e 'domain=nextcloud\\.domain\\.fr' with and without the double backlash, -e 'domain=.*\\.domain.fr', and some inexistant subdomains of my domain, it never changed the behavior …

Does someone have an idea of what might be occurring ?

If you run Ubuntu 16.04 then try the scripts from the VM: https://github.com/nextcloud/vm/blob/master/apps/collabora.sh

It’s a Debian Jessie, but i’ll take a look at this script see if I can understand the differences with what I have done …

So I noticed two differences between what I have done and the Ubuntu script:

  1. Its uses AUFS and not devicemapper
  2. It disables the richdocument app before starting the docker and re-enables it after

Thus I tried first to switch back to AUFS:

  1. stop docker systemctl stop docker

  2. Disable the richdocument app

  3. Switch to aufs: in /etc/default/docker set DOCKER_OPTS="--storage-driver=aufs" then systemctl restart docker

  4. Check that aufs is available:

    root@tetrix:/home/david# lsmod | grep aufs
    aufs                  199570  73
    root@tetrix:/home/david# apt-cache policy aufs-tools
    aufs-tools:
      Installed: 1:3.2+20130722-1.1
      Candidate: 1:3.2+20130722-1.1
      Version table:
     *** 1:3.2+20130722-1.1 0
            500 http://ftp.fr.debian.org/debian/ jessie/main amd64 Packages
            100 /var/lib/dpkg/status
    
  5. Restart the container

  6. Re-enable the richdocument app and set the wopi address as in the script

Results

  • On the browser:

    Proxy Error
    
    The proxy server received an invalid response from an upstream server.
    The proxy server could not handle the request POST /loleaflet/b2e736a3/loleaflet.html.
    
    Reason: Error reading from remote server
    
    Apache/2.4.10 (Debian) Server at office.domain.fr Port 443
    
  • On the container’s log:

      frk-00027-00027 13:21:42.147846 [ forkit ] FTL  Capability cap_sys_chroot is not set for the loolforkit program.| kit/ForKit.cpp:151
      frk-00027-00027 13:21:42.147876 [ forkit ] FTL  Capability cap_mknod is not set for the loolforkit program.| kit/ForKit.cpp:151
      frk-00027-00027 13:21:42.147898 [ forkit ] FTL  Capability cap_fowner is not set for the loolforkit program.| kit/ForKit.cpp:151
    
  • On Apache’s log:

      internal_ip - - [31/May/2017:15:22:14 +0200] "POST /loleaflet/b2e736a3/loleaflet.html?WOPISrc=https%3A%2F%2Fnextcloud.domain.fr%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F58_ocjktn2tfxdd&title=Comptes.ods&lang=fr&closebutton=1&revisionhistory=1 HTTP/1.1" 502 4444 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
    

Then I tried to switch back to device mapper and disable richdocument / start the container / enable richdocument, and I’m back at the same point …

did you solve the issue ?
I have the same issue with my server. I upgraded Nextcloud to the version 16.0.3 and the Collabora appliction too.
Now, Nextcloud display collabora empty page like in your screenshot and after some seconds fallback to the file manager displaying an connection error notification.
There is no error in the server log excpet 404 error in the access log.

I removed the docker collabora image and installed collabor from the debian package.
I still have the same issue.