Nextcloud can't connect to collabora but collabora runs

Hey guys,

I have a problem with integrating Collabora into Nextcloud. I can access Collabora itself (the admin interface without any problems.

My setup is as follows: I have a web server which handles all HTTP(S) traffic and handles as a reverse proxy for both Nextcloud and Collabora. Both those services are installed on separate KVMs and I run Collabora itself as docker container.

Nextcloud itself runs without any problems and I can do everything except using Collabora.

Nextcloud apache2 conf:

<VirtualHost *:80>
    ServerAdmin webmaster@wittmydomain
    Redirect /
    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/sites/nextcloud_http_error.log
    CustomLog ${APACHE_LOG_DIR}/sites/nextcloud_http_access.log combined env=!dontlog

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/
    SSLCertificateKeyFile /etc/letsencrypt/live/
    ProxyPreserveHost On
    ProxyPass /
    ProxyPassReverse /
    RewriteEngine On
    RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
    RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/sites/nextcloud_https_error.log
    CustomLog ${APACHE_LOG_DIR}/sites/nextcloud_https_access.log combined env=!dontlog

Collabora apache2 conf:

<VirtualHost *:80>
    DocumentRoot /var/www/empty
    Redirect /
    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/sites/collabora_http_error.log
    CustomLog ${APACHE_LOG_DIR}/sites/collabora_http_access.log combined env=!dontlog
<IfModule mod_ssl.c>
<VirtualHost *:443>
    DocumentRoot /var/www/empty
    SSLEngine on
    SSLProxyEngine on
    SSLProxyVerify None
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off
    ProxyPreserveHost On
    SSLCertificateFile /etc/letsencrypt/live/
    SSLCertificateKeyFile /etc/letsencrypt/live/

    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode

    # 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

    LogLevel warn
    ErrorLog ${APACHE_LOG_DIR}/sites/collabora_https_error.log
    CustomLog ${APACHE_LOG_DIR}/sites/collabora_https_access.log combined env=!dontlog

Collabora docker command:

docker run -t -d -p 9980:9980 -e 'domain=nextcloud\\.mydomain\\.com' -e "username=admin" -e "password=examplepassword" --restart always --cap-add MKNOD collabora/code

Any log messages from apache, nextcloud, collabora or your browser?

Hi – can I ask you a question – are you trying to access collabora going through two reverse proxies??? – What I mean is the connection route you are using – is (Nextcloud machine using apache) --> to (Collarbora machine running apache reverse proxy) -> to docker?

@User12345 You may have been hit by a problem that is plaguing others as well.

Which versions of NextCloud and Collabora are you running?

Please run the following two commands on the server running the Collabora container and post the response (sans your real domain/ips of course):

curl -k https://localhost:9980/hosting/capabilities
curl -k

The outputs should look like this:
{"convert-to":{"available":true},"hasMobileSupport":true,"hasTemplateSaveAs":true,"productName":"Collabora Online Development Edition"}

If the second command’s output has {“available”:false} in it, you should follow the thread I linked to above and wait for a solution. Frustrating as hell, but as of now I have no idea where exactly the issue lies.

Nothing at all. I tried to connect to another docker container running collabora on another domain which worked.

I run a single webserver with apache2 which acts as a reverse proxy for both Collabora and Nextcloud.


Ok can you post your section and the options you used when you start the docker container?

Why do you have two virtual host sections above? I don’t understand? Are Collabora and Nextcloud running on the same machine with same IP address or are they different?

The odd thing is that if I run that on localhost I get {“available”:false} but if I run it from another IP in the same network I get {“available”:true}. Running it against my public domain didn’t work but I guess that is because I don’t forward /hosting/discovery in my apache2 config if I’m not mistaken.

Running the command from a docker container on another domain that I can access without any problems on localhost also yields a {“available”:false}. While running it against the domain name returns the following:

<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL /hosting/capabilities was not found on this server.</p>
<address>Apache/2.4.25 (Debian) Server at Port 443</address>

I start the docker container the following way:

docker run -t -d -p 9980:9980 -e 'domain=nextcloud\\.mydomain\\.com' -e "username=admin" -e "password=examplepassword" --restart always --cap-add MKNOD collabora/code

My setup is as follows: I have a web server which handles all HTTP(S) traffic and handles as a reverse proxy for both Nextcloud and Collabora. Both those services are installed on separate KVMs and I run Collabora itself as docker container. All those KVMs are behind a NAT. The router simply redirects all HTTP(S) traffic to my web server which then splits up the traffic accordingly.

Accessing my Collabora instance from another domain ( is also impossible.

Yesterday I tried the alternative, OnlyOffice without any major luck. I am not able to access it with my Nextcloud server on but I can access it from without any problems and create, edit and save files.

Yea, but you have two reverse proxies right – Webserver / Nextcloud /Apache 1 on one machine – and Collabora Docker/Apache 2 on other machine right?

I know they are virtual machines (KVM) however I think of them as two separate “boxes”.

You’ve seen this page right? :

Why aren’t you passing variables for the SSL to docker? For example here is how I start my docker (just an example – but notice ssl.enable option)

sudo docker run --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -t -d -p 9980:9980 -e 'domain=nextcloud\\.example\\.com' --name="jax" -e "username=admin" -e "password=dockercol" -e "extra_params=--o:ssl.enable=true" --restart always --cap-add MKNOD collabora/code:latest

Also if Collabora is running on its own machine (separate than nextcloud) – you don’t technically need apache running on that machine). You can check this by doing the following:
I’m assuming a linux machine so something like this:
sudo ss -lntu

and if using ubuntu as the host double check firewall rules:
sudo ufw status

I have the main webserver on one machine which redirects all the traffic to Nextcloud / Collabora. Then I have an additional webserver(integrated in nextcloud-snap) on the machine that runs Nextcloud. I don’t have an additional webserver running on the machine that runs Collabora, instead I forward the traffic to the port that the docker container is using (9980). My main reason for not having a webserver on the machine is that I want all my custom configuration at a centralized place.

Honestly I didn’t pass variables for SSL to docker because I didn’t use any in my old, running setup and I haven’t seen them being used for the docker container by anyone.

The port itself is up and Collabora behind is (mostly) running since I’m able to connect to and click around and do stuff.

Yea but you have two reverse proxies in your setup – or two instances of apache right?

The problem with two reverse proxies (as I painfully spent days trying to figure this out – is it won’t proxy the ws or websockets – websockets can be proxied once (at least I think this is the case)) That means your first reverse proxy has to have everything setup to work from there. HTTP traffic can be proxied a lot – like through multiple hops – but not websocket traffic. Thats why you are able to access html pages…

You might still be able to use two reverse proxies (I say might because I haven’t tried it) – if you just handle the websocket traffic at the first proxy. Also you need to make a decision if you are going to terminate https traffic at the first proxy since if you do the wss lines become ws (websocket secure vs websocket). Thats why I’m bothering you about the SSL crap.

I’ve never used nextcloud-snap.

I still might not understand your setup totally I admit – but when I see you posting two virtual hosts files from two different apaches (at least I think thats what they are), I’m suspicious.

Nothing at all? You say it does not work so somewhere a different thing appears then you expect.
If nextcloud/apache or collabora do not show anything in their logs it might be that your browser refuses to request something. What do you see in your browser window and in the web console when you try to open a document?

I have only one apache that does reverse proxying in my setup. The websockets are only being proxied once - from my apache to the port that runs the docker container. The reverse proxy is however behind a NAT router. Maybe that causes the problem?

Ok … I think I understand a bit better (I think)

Do you have SSL certs that have and

I just want to make sure its not an SSL problem

Everything works with nextcloud right?
You’re entering into the nextcloud setup right?

Since you are not using encryption for collabora (which I still think you have to pass parameters to your docker that says ssl.enable=false and ssl.termination=true .
The Proxy Pass parameters would be http and ws — Here take a look at this page – Option #2 -

Yes I have SSL Certs for both subdomains and everything else works with Nextcloud (e.g sync, other apps etc.)

Doesn’t the Collabora container have it’s own self-signed certificates for SSL to make the connection via HTTP unnecessary ?

If I enter the following command I can still reach the container only via HTTPS and not via HTTP:

docker run -t -d -p 9980:9980 --name="collabora" --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1 -e "domain=nextcloud\\.mydomain\\.com" -e "username=admin" -e "password=mypassword" -e "extra_params=--o:ssl.enable=false" -e "extra_params=--o:ssl.termination=true" --restart always --cap-add MKNOD 'collabora/code:latest'

Ok – great – I dont know if the sysctl options are needed (I’m letting you know that since I found this on another post in these forums, but everything else looks good.

After the change did you change your virtual hosts file for collabora to reflect http and ws rather than https or ws?

And yes collabora generates dummy certificates if you pass the option ssl.enable = true however this is an easy change later. These certs they issue are kind of bogus since they apache config disables any validity check on them which kind of defeats the purpose of SSL anyway.

Make sure you restart apache after making the Virtual Hosts change. If things dont work see if you can debug by reaching that admin web page again, or use wget with the websocket option or post your virtual host file