Could not establish connection to the Collabora Online server - Behind NAT Firewall

Hello all,

NextCloud v30.04, AIO installation, Docker

When accessing the page:
https://[ourserverpublicname]/settings/admin/richdocuments we see the following:
"Could not establish connection to the Collabora Online server
Failed to connect to the remote server: cURL error 28: Connection timed out after 5002 milliseconds (see libcurl - Error Codes) for https://[ourserverpublicname]/hosting/discovery"

The installation is behind a NAT firewall on an isolated DMZ, hairpin nat used for internal LAN users to access the system via [ourserverpublicname] and inbound external users are also routed to [ourserverpublicname], a public DNS name resolving to the external NAT IP of the server.

Port 9980 is not published from the nextcloud-aio-collabora container to the bridge network - the only containers publishing any ports at a container level are apache and nextcloud.

When we configure the Collabora server to http://nextcloud-aio-collabora:9980 in the NextCloud office admin settings (using the container name and collaborate port) we get the following:

Collabora Online server is reachable.

Collabora Online Development Edition 24.04.10.2 a…

URL used by the browser: https://[ourserverpublicname]
Nextcloud URL used by Collabora: https://[ourserverpublicname] (Determined from the browser URL)

We can then see the WOPI allow list which includes our external server IP address mapped to [ourserverpublicname].

With this configuration if a user goes to edit a file, like a sample .ODT file, we get “Document loading failed…Failed to load Nextcloud Office - please try again later”. Users cannot access NextCloud office.

The containers can all resolve the [ourserverpublicname] to the external IP of the installation. We can see that port 9980 is running on the collabora container and that the containers can communicate with each other on the bridge network (tested using curl, ps exec).

We see the following in the collabora logs:
2024-12-31T20:44:06.112546061Z wsd-00007-00029 2024-12-31 20:44:06.112415 +0000 [ websrv_poll ]
ERR #22: WOPI::CheckFileInfo failed for URI [https://[ourserverpublicname]/index.php/apps/richdocuments/wopi/files/[fileid]?access_token=xyz&access_token_ttl=0]: 0 (Unknown) . Headers: Body: | wsd/wopi/CheckFileInfo.cpp:98

2024-12-31T20:44:06.112550360Z wsd-00007-00029 2024-12-31 20:44:06.112429 +0000 [ websrv_poll ]
ERR #22: Invalid URI or access denied to [https://[ourserverpublicname]/index.php/apps/richdocuments/wopi/files/[fileid]?access_token=xyz&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:116

When we restart the containers the NextCloud Office configuration reverts to https://[ourserverpublicname] and the “Could not establish connection to the Collabora Online server…Failed to connect to the remote server: cURL error 28: Connection timed out after 5001 millisecond” error message returns.

It appears that collabora favors https://[ourserverpublicname] but there is nothing, other than an integration with NextCloud and Collabora at the back end, that would provide access via this URL.

This is a relatively straight forward setup with all of the AIO defaults running on Docker, running on Linux. There are no local Linux issues with DNS resolution and our host file has only localhost with no other entries, not even the local server name.

Any assistance appreciated.

Hi, can you follow How to debug problems with Collabora and/or Talk · nextcloud/all-in-one · Discussion #1358 · GitHub?

Hello,

I had, leading me to my post but here is the play-by-play!

This is a vanilla AIO installation, the only modification is adding a few apps but everything has been installed via the AIO script or the NextCloud admin interface. It appears the installation is having issues with the containers internal bridge network addressing and the NAT’d external IP/DNS.

Perhaps the behavior is different behind a reverse proxy, but the amount of time to get basic functionality working out of the box is, at this point, significant.

System:
Stock NC 30.0.4 AIO installation
Collabora installed as part of AIO, dedicated server
Docker on Ubuntu linux
All containers are on the AIO nextcloud network
All storage is local to the linux host/containers
Storage for files was relocated to sdb
Resolves to “ourhost.ourdomain.com” external DNS and IP
Using OpenID connect user backend for EntraID SSO

Fully documenting the How to debug problems with Collabora and/or Talk · nextcloud/all-in-one · Discussion #1358 process:

  1. yourdomain.com” is not in the hosts file in [linux host] /etc/hosts
  2. Not on synology
  3. Not behind cloudflare
  4. Not behind a reverse proxy
  5. https://yourdomain.com/settings/admin/richdocuments “WOPI requests” does not appear due to: “Could not establish connection to the Collabora Online server…Failed to connect to the remote server: cURL error 28: Connection timed out after 5002 milliseconds” error message
  6. If we input http://nextcloud-aio-collabora:9980 in “URL (and port) of Collabora Online-server” and select “save” we can see the “WOPI requests” and set the “Allow list” to include (or be only) 0.0.0.0/0 (this setting persists even after container restarts) - but this setting - http://nextcloud-aio-collabora:9980 - only lasts until the container is restarted.
  7. With logging set to 2, Collabora server set to http://nextcloud-aio-collabora:9980 and WOPI set to 0.0.0.0/0 I attempt to open an OPT document from “TestUser01”'s “Personal Files” (location does not matter, same occurs from groups, etc.). Error message: “Document loading failed…Failed to load Nextcloud Office - please try again later”
  8. Output from the nexcloud-aio-collabora log file:
    [ websrv_poll ] WRN #32: CheckTimeout: Timeout while requesting [GET “ourhost.ourdomain.com”/index.php/apps/richdocuments/wopi/files/[filenameID]?access_token=[accesstoken]&access_token_ttl=0] after 35581ms| net/HttpRequest.hpp:1714
    [ websrv_poll ] ERR #32: WOPI::CheckFileInfo failed for URI [https://“ourhost.ourdomain.com”/index.php/apps/richdocuments/wopi/files/[filenameID]?access_token=[accesstoken]&access_token_ttl=0]: 0 (Unknown) . Headers: Body: | wsd/wopi/CheckFileInfo.cpp:98
    [ websrv_poll ] ERR #32: Invalid URI or access denied to [https://“ourhost.ourdomain.com”/index.php/apps/richdocuments/wopi/files/[filenameID]?access_token=[accesstoken]&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:116

Note: There were no client access logs in nextcloud logging but we can see the initial WOPI settings (listen allowed clients) and configuration check (WOPI URL = “ourhost.ourdomain.com”, Public WOPI URL=“ourhost.ourdomain.com”, Configured callback URL is blank)
and we also see:
Failed to fetch discovery endpoint from https://“ourhost.ourdomain.com” etc. - but these are from before setting the URL and port to http://nextcloud-aio-collabora:9980, there are no entries after.

  1. We next access to container nextcloud-aio-nextcloud and execute “curl -vvv https://$NC_DOMAIN:443/hosting/discovery”:

19:27:18.340099 [0-x] == Info: [READ] client_reset, clear readers
19:27:18.392578 [0-0] == Info: Host “ourhost.ourdomain.com”:443 was resolved.
19:27:18.392748 [0-0] == Info: IPv6: (none)
19:27:18.392825 [0-0] == Info: IPv4: [External IP Address of “ourhost.ourdomain.com”]
19:27:18.392899 [0-0] == Info: [HTTPS-CONNECT] added
19:27:18.392978 [0-0] == Info: [HTTPS-CONNECT] connect, init
19:27:18.393050 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
19:27:18.393172 [0-0] == Info: Trying [External IP Address of “ourhost.ourdomain.com”]:443…
19:27:18.393404 [0-0] == Info: [HTTPS-CONNECT] connect → 0, done=0
19:27:18.393561 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset → 1 socks
19:27:19.394407 [0-0] == Info: [HTTPS-CONNECT] connect, check h21
19:27:19.394570 [0-0] == Info: [HTTPS-CONNECT] connect → 0, done=0
19:27:19.394740 [0-0] == Info: [HTTPS-CONNECT] adjust_pollset → 1 socks

Connect 0, Done 0 repeats until exited - can resolve the external DNS name and external IP but appears not to be able to access the external IP.

  1. Skipping the Talk portion of the post.

This is why it is not working and what you need to fix.

The question is how to fix it - what needs “fixing” in this installation.

This is an out of the box NextCloud AIO installation.

The system is not accepting the default system URL - https://“ourhost.ourdomain.com” - for “URL (and Port) of Collabora Online-server”. As the logs show the nextcloud container can resolve the IP and name of the server on the Internet - but HTTPS is being provided by the apache container - which it appears the nextcloud container is trying to access via the external IP.

The bridge network used for the containers is not exposed to the internet - and even when HTTPS traffic is allowed from the DMZ the process fails.

We can only access the WOPI list when we use “http://nextcloud-aio-collabora:9980” as the “URL (and Port) of Collabora Online-server” - then we get “Collabora Online server is reachable.” not at the URL and port entered (http://nextcloud-aio-collabora:9980) but both the “URL used by the browser” and “Nextcloud URL used by Collabora” are set to https://“ourhost.ourdomain.com” - the original non-working default Collabora “User your own server” URL.

We are not exposing the Collabora port on the Internet and the Collabora server is really a container on the nextcloud AIO created bridge network - which does not expose the Collabora port to the host (it’s not a published container port).

It appears that the assumption of the AIO installation is the communication between Nextcloud components is to occur on the bridge network - nextcloud-aio-nextcloud and nextcloud-aio-collabora can “see” each other, nextcloud can curl the collabora port - but this is not what appears to be occurring when the system is trying to access the external IP/DNS where there are no Collabora ports presented.

This installation - unmodified from the AIO installation other than changing the Collabora server URL and port to see the WOPI list - fails to function with 0.0.0.0, 0.0.0.0/0, external IP, loopback, etc. all set.

The apache container usually proxies the requests to the collabora server. So even if not publoshed publicly the containers still needs to be able to resolve ths configured domain locally.

Also see all-in-one/local-instance.md at main · nextcloud/all-in-one · GitHub

The containers are using the local system DNS.
The local system DNS is configured to use external DNS servers.

Any container can resolve the external DNS name of the installation including the Apache container.

Both Nextcloud and Apache can ping and they resolve to the external IP of “ourhost.ourdomain.com” no problem.

The Collabora server doesn’t have ping installed - but using other methods we’ve confirmed that it can resolve the external IP/DNS name without issue.

When I access:

https://“ourhost.ourdomain.com”/hosting/discovery from the management interface on our internal LAN using the URL containing the external DNS/IP I can see a file starting with “”.

https://“ourhost.ourdomain.com”/hosting/discovery from the Internet as a logged in user using the URL containing the external DNS/IP I can see a file starting with “”.

https://“ourhost.ourdomain.com”/hosting/discovery from the Internet from an in private session (no user logged in) using the URL containing the external DNS/IP I can see a file starting with “”. This is likely due to the 0.0.0.0 setting, which I’m not a fan of.

If only Apache is presenting HTTPS and the Collabora server port is only available on the bridge network and its name is never resolved to the external DNS name why would a connection proxied by the apache server be unable to connect to the collabora server on the bridge network - why would the external DNS name/IP address preempt that Apache proxy action as the Collabora server is never on the internet in an AIO installation?

Nextcloud and folks on the forum have repeatedly said that the AIO installation is based on certain assumptions and to not attempt to customize the installation - so how do we get this working?

I would recommend using caddy