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


#1

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 ?


#2

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


#3

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 …


#4

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 …