Collabora Integration Issue With Nextcloud

Apps and Virtualization
1

Hi Everyone, I am having an issue trying to integrate Collabora with Nextcloud hoping to get some help. I went through the references below, along with other guides, but Collabora seem to still have issue connecting with Nextcloud. Any help would be appreciated.

Information:

  • TrueNAS Community: 25.04
  • Nextcloud App Version: 31.0.4
  • Nextcloud Version: 1.6.22
  • Collabora App Version: 25.04.1.1.1
  • Collabora Version: 1.2.25
  • Nginx Proxy Manager Version: 2.12.3

I followed the A full guide for installing Nextcloud on TrueNAS Scale with Collabora integration and outside access through Nginx Proxy Manager pretty much exactly with a few tweaks.

One other note is I also have OnlyOffice integrated with the same approach, but that seem to work fine. But not sure if both OnlyOffice and Collabora can exist in the same time? OnlyOffice is not using WebSocket on Nginx Proxy Manager.

Nextcloud Configuration:

  • Most configurations are default.
  • Host: nextcloud.domain.tld
  • WebUI Port: 30027 (default)
  • Certificate ID: nextcloud Certificate
    • This is a self-signed certificate created in TrueNAS for Nextcloud
    • This is created using EC instead of RSA (not sure if that matters)

Collabora Configuration:

  • Most configurations are default.
  • Server Name: collabora.domain.tld:443
  • WebUI Port: 9980 (default)
  • Certificate ID: collabora Certificate
    • This is a self-signed certificate created in TrueNAS for Collabora
    • This is created using EC instead of RSA (not sure if that matters)

Nginx Proxy Manager Nextcloud:

  • Domain Names: nextcloud.domain.tld
  • Scheme: https
  • Forward Hostname / IP: 10.0.0.201 (TrueNAS IP)
  • Forward Port: 30027
  • Cache Assets: off
  • Websocket Support: off
  • Block Common Exploits: on
  • SSL Certificate: nextcloud.domain.tld (Cloudflare Let’s Encrypt)
  • Force SSL: on
  • HSTS Enabled: on
  • HTTP/2 Support: off
  • HSTS Subdomains: off

Nginx Proxy Manager Collabora:

  • Domain Names: collabora.domain.tld
  • Scheme: https
  • Forward Hostname / IP: 10.0.0.201 (TrueNAS IP)
  • Forward Port: 9980
  • Cache Assets: off
  • Websocket Support: on
  • Block Common Exploits: on
  • SSL Certificate: collabora.domain.tld (Cloudflare Let’s Encrypt)
  • Force SSL: on
  • HSTS Enabled: on
  • HTTP/2 Support: off
  • HSTS Subdomains: off

So with the above configuration, Nextcloud Office indicated that Collabora Online server is reachable.

Collabora Online server is reachable.
Collabora Online Development Edition 25.04.1.1 f22c9fed45
URL used by the browser: https://collabora.domain.tld:443
Nextcloud URL used by Collabora: https://nextcloud.domain.tld (Determined from the browser URL)

But when I try to create a new document, I get the following error.

Document loading failed

Failed to establish socket connection or socket connection closed unexpectedly. The reverse proxy might be misconfigured, please contact the administrator. For more info on proxy configuration please checkout https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html

The collabora log gave this error

2025-05-03 18:25:41.086244+00:00wsd-00001-00020 2025-05-03 11:25:41.086187 -0700 [ websrv_poll ] ERR #31: Rejecting WebSocket upgrade with: origin [https://collabora.domain.tld] expected [https://collabora.domain.tld:443] instead| net/WebSocketHandler.hpp:1033

One thing I tried was setting the Collabora Server Name to 10.0.0.201 (TrueNAS IP). Nextcloud also shows Collabora Online server is reachable. But I am experiencing two different scenarios.

  1. If I access the Collabora Web UI at https://10.0.0.201:9980/browser/dist/admin/admin.html first, and login, then Nextcloud will load the document successfully.
  2. But if I go to a different computer, or even a private session where I have not logged into the Collabora Web UI, I am getting an error of Document loading failed, Failed to load Nextcloud Office - please try again later. I was monitoring the Collabora logs, but it did not output anything new. Nextcloud logs (below) did not seem to give any error? (The 10.0.0.101 is Nginx Proxy Manager IP).

2025-05-03 18:19:37.854393+00:00fdd0:0:0:3::3 (127.0.0.1) - - [03/May/2025:18:19:37 +0000] "GET /status.php HTTP/1.1" 200 1097 "-" "curl/7.88.1"
2025-05-03 18:19:42.817559+00:00172.16.6.3 (10.0.0.101) - - [03/May/2025:18:19:42 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 707 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
2025-05-03 18:19:45.814401+00:00fdd0:0:0:3::3 (10.0.0.101) - - [03/May/2025:18:19:45 +0000] "GET /apps/files/api/v1/views HTTP/1.1" 200 759 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:45.922284+00:00172.16.6.3 (10.0.0.101) - - [03/May/2025:18:19:45 +0000] "PROPFIND /remote.php/dav/files/yk/Alpha.odt HTTP/1.1" 207 1460 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:45.992023+00:00fdd0:0:0:3::3 (10.0.0.101) - - [03/May/2025:18:19:45 +0000] "GET /apps/files/api/v1/views HTTP/1.1" 200 759 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:46.021593+00:00172.16.6.3 (10.0.0.101) - - [03/May/2025:18:19:45 +0000] "PROPFIND /remote.php/dav/files/yk//Alpha.odt/ HTTP/1.1" 207 1453 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:46.028736+00:00fdd0:0:0:3::3 (10.0.0.101) - - [03/May/2025:18:19:45 +0000] "POST /apps/richdocuments/token HTTP/1.1" 200 1025 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:46.840039+00:00172.16.6.3 (10.0.0.101) - - [03/May/2025:18:19:46 +0000] "GET /index.php/apps/files/preview-service-worker.js HTTP/1.1" 200 6468 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"
2025-05-03 18:19:47.947510+00:00127.0.0.1 (-) - - [03/May/2025:18:19:47 +0000] "GET /status.php HTTP/1.1" 200 1097 "-" "curl/7.88.1"
2025-05-03 18:19:47.951836+00:00fdd0:0:0:3::3 (127.0.0.1) - - [03/May/2025:18:19:47 +0000] "GET /status.php HTTP/1.1" 200 1097 "-" "curl/7.88.1"
2025-05-03 18:19:57.029057+00:00172.16.6.3 (10.0.0.101) - - [03/May/2025:18:19:56 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 705 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0"
2025-05-03 18:19:58.034660+00:00127.0.0.1 (-) - - [03/May/2025:18:19:58 +0000] "GET /status.php HTTP/1.1" 200 1097 "-" "curl/7.88.1"

Reference

1 Like
2

Hey @YTK

Is there any reason you used custom certificates (nextcloud Certificate and collabora Certificate) instead of the ‘truenas_default’ Certificate?

I also see that you seem to be using two separate SSL certificates for outside access (nextcloud.domain.tld and collabora.domain.tld) instead of just one, wildcard certificate (*.domain.tld).

You might want to change those two things. I’m honestly not sure if that could be causing your problem, though.

Also, this error message is peculiar:

The message makes it sound as though https://collabora.domain.tld and https://collabora.domain.tld:443 are being interpreted as two different things, even though https://collabora.domain.tld (without :443) should evaluate to https://collabora.domain.tld:443.

In your Nextcloud settings, when you specified the Collabora URL (on the same page that says Collabora Online server is reachable), did you write https://collabora.domain.tld:443? If so, it might be worth trying to put just https://collabora.domain.tld (without the :443).

It might also be interesting to see what happens when you set the Server Name in the Collabora configuration to collabora.domain.tld instead of collabora.domain.tld:443.

I know that I said you should set the Server Name to collabora.domain.tld:443 in my guide, but that guide is almost two years old now, and they might have changed things around since then (putting collabora.domain.tld:443 as the Server Name was something I came up with, making me feel like it was kind of a “hacky” solution to begin with).

Typically, the Failed to establish socket connection or socket connection closed unexpectedly message gets thrown when you don’t have Websockets Support enabled for your Collabora reverse proxy, but you said you enabled Websockets Support, so I guess that’s not the problem.

Hope I’ve given you at least a few new things to try!

3

Hi @owl, thank you for the reply and information

Is there any reason you used custom certificates (nextcloud Certificate and collabora Certificate) instead of the ‘truenas_default’ Certificate?

I choose to use separate certificate for Nextcloud and Collabora is mainly for separation of concern. (From a security perspective, I think it make sense to have separate certificates for separate (sub)domain and application, in case one certificate get compromised?) But from a homelab perspective, you are correct, I could’ve use just the default certificate. (This goes for same for Nginx Proxy Manager, I probably could’ve used a single certificate). But Nextcloud and other applications seem to work fine with it? But I can try using just one certificate and see.

It might also be interesting to see what happens when you set the Server Name in the Collabora configuration to collabora.domain.tld instead of collabora.domain.tld:443.

I actually tried both https://collabora.domain.tld and https://collabora.domain.tld:443, both gave the same message of Failed to establish socket connection or socket connection when loading document.

I’ll test the suggestion you provided and some other parameters to see it they will help. Will update on progress.

4

So I created another instance on a separate test server I have, with Nextcloud and Collabora, using the same truenas_default certificate. But I seem to be getting the same error.

An interesting note, when I sent the Server Name on Collabora to collabora.domain.tld and collabora.domain.tld:443, and try to access the web interface at https://<ip_address>:9980/browser/dist/admin/admin.html or https://<domain_name>:9980/browser/dist/admin/admin.html, I get an error of Server has been shut down; please reload the page. and even reloading doesn’t help.

5

FYI @owl, so whatever the latest update (25.04.1.1.1) changed :crossed_fingers:t2:, apparently using your configuration from previous post (I didn’t even change anything) is working fine now? Hopefully it doesn’t break on next update. :sweat_smile:

Verified on both of my instance with same configuration, both works fine…

1 Like
6

@YTK

So weird, but I guess we’ll take what we can get! Hopefully, one day, setting all of this up will be so intuitive that it won’t necessitate such elaborate write-ups.

1 Like