Failed to connect to Collabora Online

Hello. I’m completely new to both NextCloud and Collabora. I’m trying to set this up for the first time. I seem to have the NextCloud part down, but I’m having trouble with Collabora. When I click on a doc, it spins for about 10 seconds and then gives me “Failed to connect to Collabora Online. Please try again later or contact your server administrator.” Here’s a breakdown of what I’ve done.

Sorry for the spaces below, the forum is telling me I can’t post more than 4 links…

I’m running a single Ubuntu 18.04 server dedicated to this. I’ve installed NextCloud via snap and changed the listening ports to 8080 and 8443. This seems to be fine.

nextcloud.enable-https self-signed
snap set nextcloud ports.http=8080 ports.https=8443

Then I installed Collabora with Docker as per their instructions. This also appears to be running as far as I can tell. It’s listening on TCP 9980. This is what I did specifically:

docker run -t -d -p -e 'domain=nextcloud\\.example\\.net' --restart always --cap-add MKNOD collabora/code

I have DNS names set up for both, let’s say and Collabora is a CNAME for nextcloud and they resolve correctly.

At first I tried with no proxy before changing the snap ports. I set up Collabora Online to connect several different ways such as https :// and and https :// All had the same result. It spins opening a document and then times out with the aforementioned error.

Seeing all the talk of reverse proxies, I thought maybe this was really needed, so I changed the nextcloud listen ports and installed apache2 from apt. I enabled the apache2 modules as listed at https :// but used a different site config since I’m also passing nextcloud through it. Here is my full site config:

# NextCloud HTTP
<VirtualHost *:80>
        ProxyPreserveHost On
        ProxyPass / http ://
        ProxyPassReverse / http ://
        AllowEncodedSlashes NoDecode
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

<IfModule mod_ssl.c>
        # NextCloud HTTPS
        <VirtualHost *:443>
                ProxyPreserveHost On
                ProxyPass / https ://
                ProxyPassReverse / https ://
                AllowEncodedSlashes NoDecode
                SSLEngine On
                # SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                # SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
                SSLCertificateFile /etc/ssl/certs/
                SSLCertificateKeyFile /etc/ssl/private/
                SSLProxyEngine on
                SSLProxyVerify none
                SSLProxyCheckPeerCN off
                SSLProxyCheckPeerName off
                SSLProxyCheckPeerExpire off
                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined
        # Collabora HTTPS
        <VirtualHost *:443>
                ProxyPreserveHost On
                ProxyPass / https ://
                ProxyPassReverse / https ://
                AllowEncodedSlashes NoDecode
                SSLEngine On
                # SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                # SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
                SSLCertificateFile /etc/ssl/certs/
                SSLCertificateKeyFile /etc/ssl/private/
                SSLProxyEngine On
                SSLProxyVerify none
                SSLProxyCheckPeerCN off
                SSLProxyCheckPeerName off
                SSLProxyCheckPeerExpire off
                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

This also seems to be working, as far as I can tell. NextCloud and Collabora servers are using whatever self-signed SSL they came with. When I go to https :// I reach my nextcloud interface and see my Let’s Encrypt wildcard cert from Apache. When I go to https :// I get “OK” and that’s all, but according to some references I’ve seen to people pulling it with curl, that seems to be the expected response. I went to the Collabora Online config in NextCloud and set it to (removed port number so it defaults to 443).

But, at the end of all that, I’m still in the same spot. When I click on a doc, it spins for a few seconds and them times out. I ran tshark on port 9980, and I can see them talking. They go back and forth for about 650 packets, then pause, and then about another 650 packets when the connection errors out. It’s all SSL so I can’t really see what was said. Although one of the IPs in the conversation is which isn’t one of mine. I assume that’s a Docker NAT or something since it’s on the port 9980 end of the conversation? I’m new to Docker too.

I tried it again using the VirtualHost configuration as it is on https :// minus the names and certs. Same thing.

I’m not sure where to go from here since I’m new to these programs. Any help is much appreciated.

I tried deleting the docker container and image and reloading it. No change. I also tried deleting the Collabora Online app in NextCloud and reinstalling. Didn’t fix the problem, but it did introduce a new one. Now under both Personal and Administration settings, the menu item formerly known as Collabora Online is now simly “1”. The error messages after clicking on a document has now changed to: “Failed to connect to {productName}. Please try again later or contact your server administrator.” Seems it forgot its name…

I could really use some help with this if anyone has any ideas.

Is there a change when you make this “domain” a capital “DOMAIN”? I don’t use Docker version now, but when I tried on Docker version before, there were changes depending on the case of environment variables.


I have the same problem.
I used this manual

Here is my config:
Nextcloud: 15.0.7
Collabora online: 3.3.2
Apache: 2.4.25

<IfModule mod_ssl.c>
<VirtualHost *:443>
Protocols h2 h2c http/1.1
Options -Indexes

LogLevel debug
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
CustomLog ${APACHE_LOG_DIR}/o.mm13_443_access.log combined
ErrorLog ${APACHE_LOG_DIR}/o.mm13_443_error.log
Header always set Strict-Transport-Security "max-age=15768000; includeSubdomains; preload"

Include /etc/letsencrypt/options-ssl-apache.conf

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCACertificateFile /etc/letsencrypt/live/
SSLHonorCipherOrder     on

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# keep the host
ProxyPreserveHost On

# 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
ProxyPassMatch "/lool/(.*)/ws$" wss://$1/ws nocanon

# Admin Console websocket
ProxyPass   /lool/adminws wss://

# Download as, Fullscreen presentation and Image upload operations
ProxyPass           /lool
ProxyPassReverse    /lool

# Endpoint with information about availability of various features
ProxyPass           /hosting/capabilities retry=0
ProxyPassReverse    /hosting/capabilities


And Docker

Containers: 7
 Running: 1
 Paused: 0
 Stopped: 6
Images: 1
Server Version: 18.09.6
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
  Profile: default
Kernel Version: 4.9.0-9-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 9.769GiB
Name: web
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Experimental: false
Insecure Registries:
Live Restore Enabled: false
Product License: Community Engine

mmmm, are you also able to reach both of your services successfully? If you go to your FQDN for Nextcloud you get Nextcloud, and if you go to your FQDN for Collabora I think it’s supposed to say “OK”.

From your Apache config it looks like you might have your Nextcloud FQDN proxying to Collabora.

Hi KarlF12,

if you just try NC/LOOL you can get a quick setup if you search
“Quick tryout with ownCloud docker”

But this is only for the first view and do not work whithout extensive extension to setup.
If you wont to get a productive work environment there are many steps neccessary. If you want to do so i will try to help you.

FYI, i do a lot of work in the last weeks to set this but now its works like a charm and i never will miss it … :wink:

I have the same issue: i have nextcloud running in apache, installed the collabora docker and configured the apache reverse proxy for it. At first i tried it on the same domain but a different port, got the same loading and then failed to connect, then I got it on a second domain and thought it would fix it but it didn’t.

Ok, so I got rid of the snap and installed from the zip archive. Got it up and running, now on version 16.0.1. And I’m having the exact same problem with Collabora Online. The only difference I see is NextCloud now says “Failed to connect to Collabora Online Development Edition.” Not sure where the Development Edition came from? I’m using the same docker image as before.

Any ideas?

I tried rolling back the docker snap from the current stable version 18.06.1-ce to the previous stable 17.06.2-ce. Still does not work. I also tried running the Collabora docker using both the loopback and the actual local IP. Neither worked.

Having tried this with two major Nextcloud versions and two major Docker versions as well as various other configuration changes, I’m stumped at this point and have about given up on Collabora unless anyone knows anything else to try.

I found out today that there’s an option to start collabora/code in docker without SSL, so I did that an ran a capture with tshark to see what was going on. When clicking apply on the collabora settings page in nextcloud, it queries capabilities from collabora. Among the response is a part that says something about convert to png and says available is false. Yet when I try to open or create a document, nextcloud makes a bunch of HTTP POSTs for that convert to png link, and collabora keeps sending it HTTP 403’s. Result is the same with and without the apache proxy.

Since they’re talking back and forth, this is obviously a software bug, although it’s not clear to me on what side. In any case, I don’t know what to do with it.

Hi KarlF12 & bertino,

do you try my recommendation with Quick setup? Do that work?

Do https://[FQDN-or-IP of your LOOL Server]/hosting/discovery on your config work?

Do you change the settings in the /etc/loolwsd/loolwsd.xml on your LOOL server, especially wopi storage and network settings?

What tell you the nextcloud log in data/nextcloud.log on your nc docker image?

Regards, Ralfi

NECESSARY LOOL configuration changes ABSTRACT /etc/loolwsd/loolwsd.xml

Section [logging]
Set log level to “debug” until everything works; Logging to file [file enable = “true”] makes sense

Section [net desc = “Network settings”]
host desc = “Host …”> [IP Address] …

It is essential to enter all IPv4 or IPv4 mapped IPv6 network addresses from which the LOOL host is to be accessed, and so on. also the public IPv4 address of the router or the Docker Gateway.

Section [ssl desc = “SSL settings”]

First value “Controls whether SSL encryption is enable …” set to “false” if you want to work without internal SSL in the LOOL VM (corresponds to the ENV variable “–o: ssl-enable = false” in the start syntax of the LOOL Docker containers). If Nextcloud accesses LOOL via https / ReverseProxy, this is not a security risk.

Section [Storage desc = “backend storage”]
Section, Allow / deny wopy storage
[host desc = “Nextcloud wopi host” allow = “true”> [FQDN of Nextcloud Instance]]

This value denotes the Nextcloud instance which accesses the services of the LOOL server as WOPI host. So for example the FQDN of the PC who Nextcloud is installed or the Internet FQDN. Corresponds to the ENV variable “domain =” F \ .Q \ .D \ .N "in the boot syntax of the LOOL Docker container

All other parameters can be taken over so far, no installation of additional software packages is necessary. As a result, a separate volume for /etc/lool / may be unnecessary.

I haven’t tried anything else with this recently, but to answer your question: I am not running Nextcloud in docker, nor do I have any plans to do so. I originally installed from snap and then found smbclient was not included in the snap. This was a deal breaker so I threw out the snap and installed from zip. It’s working fine on that end.

I have tried both Collabora and OnlyOffice following information found in a multitude of guides and tried a variety of configurations including with/without proxy and same/separate servers. There is zero possibility of a connection issue because I can do a packet capture and see them talking back and forth. None of it works.

I can see that Nextcloud is sending a bunch of commands to Collabora that Collabora doesn’t like (responds with HTTP 403). I have absolutely entered the Nextcloud server address correctly and have checked it many times and redone it many times. I would very much like to get it working, but I’m at a loss for what else I can do to troubleshoot it.

Hi KarlF12

i really understand your frusticated message, for me it take also a long time to set a really good working environment. But this is not caused by nc or lool, this is in fact really caused by many different ip-/network environments of the user or customer that makes it really difficult - or impossible - to write a universal working guide.

For me the look at the log files in my lool container (see above) AND the nextcloud instances with enhanced log level as described in the nextcloud docs brings me to my working configuration.

And as i say in another threads, first of all try this.

If this run (and its also run with nextcloud:latest and libreoffice-online:master) then if you like we can establish a bidirectional private help session with matrix / riot if you like.

Regards, Ralf

I tried this on my Nextcloud server (using a port other than 80) and the docker version of nextcloud connects with the collabora/code container. I tried it again, with and without SSL, with my production Nextcloud, and it does not work. So why does it work with the docker version of nextcloud but not the zip or snap versions? Ironically docker itself is running from a snap package.

I suppose I could try to migrate my Nextcloud installation to docker if that’s the only way I can get it to work… although I don’t look forward to the task.

Hi KarlF12,

the answer(s) of your questions are in the /etc/loolwsd/loolwsd.xml of the libreoffice-online / collabora-online docker image. You have to modify this file if you want to adapt it to your network config, esp. with your local docker production environment. Without mods its only work as described in the “Quick try” post.

Take a look at network and the backend storage section of the lool config file. IMHO the best way to set the config is an docker user container for /etc/loolwsd/ and also setting the debug log and debug log file modus in /etc/loolwsd/loolwsd.xml. Then you should. set your network environment specs in this file.

Also set the debug mode in your nextcloud config.php.

I looked at the loolwsd.xml file. Below are the unmodified network and storage sections.

<net desc="Network settings">
  <proto type="string" default="all" desc="Protocol to use IPv4, IPv6 or all for both">all</proto>
  <listen type="string" default="any" desc="Listen address that loolwsd binds to. Can be 'any' or 'loopback'.">any</listen>
  <service_root type="path" default="" desc="Prefix all the pages, websockets, etc. with this path."></service_root>
  <post_allow desc="Allow/deny client IP address for POST(REST)." allow="true">
    <host desc="The IPv4 private 192.168 block as plain IPv4 dotted decimal addresses.">192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
    <host desc="Ditto, but as IPv4-mapped IPv6 addresses">::ffff:192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
    <host desc="The IPv4 loopback (localhost) address.">127\.0\.0\.1</host>
    <host desc="Ditto, but as IPv4-mapped IPv6 address">::ffff:127\.0\.0\.1</host>
    <host desc="The IPv6 loopback (localhost) address.">::1</host>
  <frame_ancestors desc="Specify who is allowed to embed the LO Online iframe (loolwsd and WOPI host are always allowed). Separate multiple hosts by space."></frame_ancestors>

<storage desc="Backend storage">
    <filesystem allow="false" />
    <wopi desc="Allow/deny wopi storage. Mutually exclusive with webdav." allow="true">
        <host desc="Regex pattern of hostname to allow or deny." allow="true">localhost</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="true">10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="true">172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="true">172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="true">172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
        <host desc="Regex pattern of hostname to allow or deny." allow="false">192\.168\.1\.1</host>
        <max_file_size desc="Maximum document size in bytes to load. 0 for unlimited." type="uint">0</max_file_size>
    <webdav desc="Allow/deny webdav storage. Mutually exclusive with wopi." allow="false">
        <host desc="Hostname to allow" allow="false">localhost</host>

I used docker cp to get the file and again to put it back. It was throwing an error about the Nextcloud server IP being denied, so I added a line for it and was able to resolve that. Now I’m getting SSL errors.

wsd-00028-00038 2019-06-01 22:41:01.814680 [ websrv_poll ] ERR  Socket #23 SSL BIO error: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (0: Success)| ./net/SslSocket.hpp:281
wsd-00028-00038 2019-06-01 22:41:01.814788 [ websrv_poll ] ERR  Error while handling poll for socket #23 in websrv_poll: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca| ./net/Socket.hpp:570
wsd-00028-00038 2019-06-01 22:41:02.527529 [ websrv_poll ] ERR  Socket #21 SSL BIO error: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init (EAGAIN: Resource temporarily unavailable)| ./net/SslSocket.hpp:281
wsd-00028-00038 2019-06-01 22:41:02.527614 [ websrv_poll ] ERR  Error while handling poll for socket #21 in websrv_poll: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init| ./net/Socket.hpp:570
wsd-00028-00122 2019-06-01 22:41:45.710640 [ docbroker_00d ] WRN  Client session [0017] not found to forward message: o141 signaturestatus: 0| wsd/DocumentBroker.cpp:1798

According to the instructions at none of this editing and customizing should be necessary…

@KarlF12 if you can’t succeed and want to start over run one of the playbooks in a new installed ubuntu machine:

I distinctly don’t want to start over. I’ve already done that once moving from snap install to manual install after discovering smbclient can’t be used with the snap version, and had to fix all the devices and do a bunch of extra setup on the server that wasn’t necessary with the snap package.

I’m open to moving to docker if that will make life easier going forward, but I will want to migrate, not start over. It’s a good learning experience. I’ve found a guide on how to do this. I will have to learn some more about how to use docker and get comfortable with the way it stores the data. This was another thing I didn’t like about the snap package. Uninstalling the package apparently wipes all the user data too.

Since I have already installed mariadb on this server for the manual installation, it seems like I should be able to connect the docker nextcloud to my existing database and just migrate the user data into the container, or potentially even use the data folder as it sits. I’m still reading about this process. I’ve been using Ubuntu since version 8 but had never used docker before trying to set up collabora.