Unable to reach Collabora Server (docker)

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • Nextcloud Hub 25 Autumn (32.0.6)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Linux 6.12.73+deb13-amd64 x86_64
  • Web server and version (e.g, Apache 2.4.25):
    • Package: apache2
      Version: 2.4.66-1~deb13u1
      Priority: optional
      Section: httpd
      Provides: httpd, httpd-cgi
      Pre-Depends: init-system-helpers (>= 1.54~)
  • Reverse proxy and version _(e.g. nginx 1.27.2)

Caddyfile:

(in my router, I have only port-forwarding for port 443 to the Debian server)

https://my.domain.be {
reverse_proxy 127.0.0.1:8080 {
header_up X-Forwarded-Ssl on
}

# Collabora Online
    handle_path /lool* {
            reverse_proxy http://127.0.0.1:9980
   }

   handle_path /browser* {
            reverse_proxy http://127.0.0.1:9980
   }

redir /.well-known/carddav /remote.php/dav/ 301
redir /.well-known/caldav /remote.php/dav/ 301
redir /.well-known/webfinger /index.php/.well-known/webfinger 301
redir /.well-known/nodeinfo /index.php/.well-known/nodeinfo 301

header {
	Strict-Transport-Security "max-age=15552000; includeSubDomains"
	X-Content-Type-Options "nosniff"
	X-Frame-Options "SAMEORIGIN"
	Referrer-Policy "no-referrer"
	X-XSS-Protection "1; mode=block"
}

# Content-Security-Policy voor Memories
header {
	Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; connect-src 'self'; font-src 'self'; base-uri 'self'; frame-ancestors 'self';"
	Referrer-Policy "no-referrer-when-downgrade"
}
@forbidden {
	path /data/*
}

@limited {
	remote_ip 0.0.0.0/0
	remote_ip ::/0
}

respond @forbidden 404

}

/srv/nextcloud/config/config.php

<?php
$CONFIG = array (
  'overwrite.cli.url' => 'https://my.domain.be',
  'forwarded_for_headers' => 
  array (
    0 => 'HTTP_X_FORWARDED_FOR',
    1 => 'HTTP_X_FORWARDED_PROTO',
  ),
  'instanceid' => 'xxxxxx',
  'passwordsalt' => 'xxxxxx',
  'secret' => 'xxxxxx',
  'trusted_domains' => 
  array (
    0 => '192.168.xx.xx:8080',
    1 => 'my.domain.be',
    2 => 'localhost',
  ),
  'overwritehost' => 'my.domain.be',
  'overwriteprotocol' => 'https',
  'overwritewebroot' => '',
  'overwritecondaddr' => '^127\\.0\\.0\\.1$',
  'trusted_proxies' => 
  array (
    0 => '192.168.xx.xx',
    1 => '127.0.0.1',
  ),
...

/etc/apache2/sites-available/nextcloud.conf:

<VirtualHost *:8080>
ServerName 192.168.178.53
DocumentRoot /srv/nextcloud
<Directory /srv/nextcloud>
    Require all granted
    AllowOverride All
    Options FollowSymLinks
</Directory>
ProxyPassMatch "^/(.*\.php(/.*)?)$" \
    "unix:/run/php/php8.3-fpm.sock|fcgi://localhost/srv/nextcloud/"
</VirtualHost>
  • PHP version (e.g, 8.3):
    • 8.3.30
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • from the start (after setting up the docker with collabora)
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

I’m running a collabora-server in Docker, I think all configuration files are setup correctly. In the NextCloud admin settings, Office, I have a “green light”. When I try to open an office document, after a few second I get:

Document laden mislukt

Kon Nextcloud Office niet laden - probeer het later opnieuw
(Loading document failed, couldn’t load NextCloud Office, try again later)

Steps to replicate it (hint: details matter!):

  1. Install collabora docker
  2. Open an office document

Log entries

Web Browser

Firefox, Chrome

Nextcloud admin panel

In green is stated that the collabora server is reachable

Collabora Online server is bereikbaar.

Collabora Online Development Edition 25.04.9.2 a9b866688f

URL die door de browser wordt gebruikt: https://my.domain.be
Nextcloud URL gebruikt door Collabora: https://my.domain.be (Determined from the browser URL)

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
    "system": {
        "overwrite.cli.url": "https:\/\/my.domain.be",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR",
            "HTTP_X_FORWARDED_PROTO"
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.xx.xx:8080",
            "my.domain.be",
            "localhost"
        ],
        "overwritehost": "my.domain.be",
        "overwriteprotocol": "https",
        "overwritewebroot": "",
        "overwritecondaddr": "^127\\.0\\.0\\.1$",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.6.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance_window_start": 1,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "default_phone_region": "BE",
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 1.5
        },
        "filelocking.enabled": true,
        "theme": "",
        "debug": true,
        "loglevel": 0,
        "allow_local_remote_servers": true,
        "simpleSignUpLink.shown": false,
        "enabledPreviewProviders": [
            "OC\\Preview\\BMP",
            "OC\\Preview\\GIF",
            "OC\\Preview\\JPEG",
            "OC\\Preview\\MarkDown",
            "OC\\Preview\\MP3",
            "OC\\Preview\\PNG",
            "OC\\Preview\\TXT",
            "OC\\Preview\\XBitmap",
            "OC\\Preview\\OpenDocument",
            "OC\\Preview\\Krita",
            "OC\\Preview\\WebP",
            "OC\\Preview\\Image",
            "OC\\Preview\\HEIC",
            "OC\\Preview\\TIFF",
            "OC\\Preview\\Movie"
        ],
        "app_install_overwrite": [],
        "memories.db.triggers.fcu": true,
        "memories.exiftool": "\/srv\/nextcloud\/apps\/memories\/bin-ext\/exiftool-amd64-glibc",
        "memories.vod.path": "\/srv\/nextcloud\/apps\/memories\/bin-ext\/go-vod-amd64",
        "memories.vod.ffmpeg": "\/usr\/bin\/ffmpeg",
        "memories.vod.ffprobe": "\/usr\/bin\/ffprobe",
        "memories.gis_type": 1,
        "mail_smtpauth": true,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "ssl",
        "ffmpeg.binaries": "\/usr\/bin\/ffmpeg",
        "ffprobe.binaries": "\/usr\/bin\/ffprobe",
        "maintenance": false
    }
}

Apps

The output of occ app:list (if possible).

Enabled:
  - activity: 5.0.0
  - appointments: 2.6.3
  - bruteforcesettings: 5.0.0
  - calendar: 6.2.1
  - circles: 32.0.0
  - cloud_federation_api: 1.16.0
  - contacts: 8.3.4
  - contactsinteraction: 1.13.1
  - dashboard: 7.12.0
  - dav: 1.34.2
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_downloadlimit: 5.0.0-dev.0
  - files_external: 1.24.1
  - files_pdfviewer: 5.0.0
  - files_sharing: 1.24.1
  - files_trashbin: 1.22.0
  - files_versions: 1.25.0
  - fileslibreofficeedit: 2.0.1
  - firstrunwizard: 5.0.0
  - forms: 5.2.4
  - integration_deepl: 2.1.0
  - logreader: 5.0.0
  - lookup_server_connector: 1.20.0
  - mail: 5.7.2
  - memories: 7.8.2
  - music: 3.0.0
  - nextcloud_announcements: 4.0.0
  - notes: 4.13.0
  - notifications: 5.0.0
  - oauth2: 1.20.0
  - password_policy: 4.0.0
  - photos: 5.0.0
  - previewgenerator: 5.13.0
  - privacy: 4.0.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - qownnotesapi: 26.2.2
  - recognize: 10.0.7
  - recommendations: 5.0.0
  - related_resources: 3.0.0
  - richdocuments: 9.0.3
  - serverinfo: 4.0.0
  - settings: 1.15.1
  - sharebymail: 1.22.0
  - support: 4.0.0
  - survey_client: 4.0.0
  - systemtags: 1.22.0
  - tables: 1.0.5
  - tasks: 0.17.1
  - text: 6.0.1
  - text_templates: 1.3.0
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - twofactor_nextcloud_notification: 6.0.0
  - twofactor_webauthn: 2.6.0
  - updatenotification: 1.22.0
  - user_status: 1.12.0
  - viewer: 5.0.0
  - weather_status: 1.12.0
  - webhook_listeners: 1.3.0
  - workflowengine: 2.14.0
Disabled:
  - admin_audit: 1.22.0
  - app_api: 32.0.0 (installed 32.0.0)
  - comments: 1.22.0 (installed 1.20.1)
  - encryption: 2.20.0
  - epubviewer: 1.9.2 (installed 1.9.2)
  - files_reminders: 1.5.0 (installed 1.3.0)
  - maps: 1.6.0 (installed 1.6.0)
  - suspicious_login: 10.0.0
  - twofactor_totp: 14.0.0
  - user_ldap: 1.23.0
sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       100.64.0.0/10             
443/tcp                    ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
22/tcp                     ALLOW       192.168.178.0/24          
445/tcp                    ALLOW       192.168.178.0/24          
139/tcp                    ALLOW       192.168.178.0/24          
8096/tcp                   ALLOW       192.168.178.0/24          
9090/tcp                   ALLOW       Anywhere                  
9980                       ALLOW       127.0.0.1                 
9980                       DENY        Anywhere                  
443/tcp (v6)               ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
9090/tcp (v6)              ALLOW       Anywhere (v6)             
9980 (v6)                  DENY        Anywhere (v6)

from your description I assume the connection from client to CODE is not allowed - please review the Collabora integration guide

Could you be a little more specific? There’s a lot on that page…

Do you mean “verify “Allow list for WOPI requests” entries. empty the list for testing then add IPs as needed”? Is that done with this:

# adopt to your system e.g. add sudo, www user etc..
occ config:app:set richdocuments wopi_url --value ${CODE_URL} 
occ richdocuments:activate-config

?

This:

common issues

  • don’t use localhost

    • this reserved hostname is always different depending on the point of view:

      • for client, this means “the service running on the client”

      • for Nextcloud it means “the service running on Nextcloud server”

      • for CODE it means “the service running on the CODE server”

  • don’t use internal names or IPs e.g. http://127.0.0.1, http://office:9980, http://192.168.0.7:80

  • don’t use plain http:// http://office:9980, http://cloud:80, http://cloud

    • this might allow communication from cloud to office and result in a green checkmark within Nextcloud Office settings. But communication from the client will fail.

    • technically it’s possible to run the whole stack without TLS but you should never expose your system on the internet without TLS.

Is that for de NextCloud-config file, the Caddyfile or where exactly?

I did that and discovered my Let’s Encrypt certificate was expired (my https-website was still reachable though). I fixed that and now the url is “activated," I restarted caddy and the docker, but still no luck. Can’t open office documents.

Removing 127.0.1.1 and 127.0.0.1 from etc/hosts didn’t help either.

EDIT:

sudo -u www-data php8.3 /srv/nextcloud/occ richdocuments:activate-config
✓ Reset callback url autodetect
Checking configuration
🛈 Configured WOPI URL: https://collabora.mydomain.be
🛈 Configured public WOPI URL: http://collabora.mydomain.be
🛈 Configured callback URL:

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.9.2

Collabora URL (used for Nextcloud to contact the Collabora server):
https:collabora.mydomain.be
Collabora public URL (used in the browser to open Collabora):
http:collabora.mydomain.be
Callback URL (used by Collabora to connect back to Nextcloud):
autodetected (will use the same URL as your user for browsing Nextcloud)

I’m going crazy!
I tried to set up a different domain for the collabora server (collabora.mydomain.com) which worked in the past on my Raspberry Pi, but no luck.

sudo -u www-data php8.3 /srv/nextcloud/occ config:app:get richdocuments wopi_url
Gives me the correct url and if I go there, I get “OK”.

Now I switched to the built-in server, I get the “green light” in the office admin setting, but STILL documents won’t open!

please read and understand the guide I provided!

Hi wwe, I read that guide and I don’t understand. That’s why I asked (see above).

So your answer is: if you don’t understand, then tough luck, but there it stops?

Because you can see I applied as much as I understand of the page you refer to: config:app:get richdocuments wopi_url and richdocuments:activate-config, looking at the /hosts file, etc.

It’s not like I’m not trying and only asking, in my opinion.

tldr; yes.

long answer: self-hosting requires knowledge and effort → 101: Self-hosting information for beginners.

If you don’t mind to read and understand a short guide which guides you to solve most of the problems likely it’s not a good solution for you.

@Taxicletter
where do you host your server?
how do you host your server?
your connection to the internet?
do you run ipv4 or ipv6 or both?
do you have bruteforce or something running?

I have a headless HP EliteDesk with Debian, NextCloud is installed directly, Collabora with a Docker. My server is connected with an UTP-cable to my router. I only forward 443 to Caddy in my router. Ufw allows 443, 80, 8080, etc. Crowdsec is active, but no bruteforce scenario’s.

I think I only run ipv4.

I had the same configuration on a Raspberry Pi before, and that worked. I used a separate url for collabora, which only gave a short warning when opening documents, because I couldn’t “whitelist” the collabora server.

i don’t know anything about that but are you sure that your (new?) setup doesn’t block your access to your collabora?

I don’t think so,
This: curl -v ``https://collabora.mydomain.be/hosting/discovery

Ends up in xml code, and:

Host collabora.mydomain.be:443 was resolved.

IPv6: (none)

IPv4: 212.233.33.193

Trying 212.233.33.193:443…

ALPN: curl offers h2,http/1.1

TLSv1.3 (OUT), TLS handshake, Client hello (1):

CAfile: /etc/ssl/certs/ca-certificates.crt

CApath: /etc/ssl/certs

TLSv1.3 (IN), TLS handshake, Server hello (2):

TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):

TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):

TLSv1.3 (IN), TLS handshake, Certificate (11):

TLSv1.3 (IN), TLS handshake, CERT verify (15):

TLSv1.3 (IN), TLS handshake, Finished (20):

TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):

TLSv1.3 (OUT), TLS handshake, Finished (20):

SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / id-ecPublicKey

ALPN: server accepted h2

Server certificate:

subject: CN=collabora.mydomain.be

start date: Mar  7 09:21:02 2026 GMT

expire date: Jun  5 09:21:01 2026 GMT

subjectAltName: host “collabora.mydomain.be” matched cert’s “collabora.mydomain.be”

issuer: C=US; O=Let’s Encrypt; CN=E7

SSL certificate verify ok.

Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384

Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption

Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption

Connected to collabora.mydomain.be (212.233.33.193) port 443

using HTTP/2

[HTTP/2] [1] OPENED stream for https://collabora.mydomain.be/hosting/discovery

[HTTP/2] [1] [:method: GET]

[HTTP/2] [1] [:scheme: https]

[HTTP/2] [1] [:authority: mydomain.be]

[HTTP/2] [1] [:path: /hosting/discovery]

[HTTP/2] [1] [user-agent: curl/8.14.1]

[HTTP/2] [1] [accept: /]

GET /hosting/discovery HTTP/2
Host: collabora.mydomain.be/
User-Agent: curl/8.14.1
Accept: /

TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

Request completely sent off
< HTTP/2 200
< alt-svc: h3=“:443”; ma=2592000
< content-type: text/xml
< date: Tue, 10 Mar 2026 20:51:02
< last-modified: Tue, 10 Mar 2026 20:51:02
< server:
< via: 1.1 Caddy
< x-content-type-options: nosniff
< content-length: 40560
<

In nextcloud this also looks correct to me:

sudo -u www-data php8.3 /srv/nextcloud/occ config:app:get richdocuments wopi_url
https://collabora.mydomain.be 

sudo -u www-data php8.3 /srv/nextcloud/occ config:app:get richdocuments public_wopi_url
https://collabora.mydomain.be

And this:

sudo -u www-data php8.3 /srv/nextcloud/occ richdocuments:activate-configs:activate-config
✓ Reset callback url autodetect
Checking configuration
🛈 Configured WOPI URL: https://collabora.mydomain.be
🛈 Configured public WOPI URL: https://collabora.mydomain.be
🛈 Configured callback URL:

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.9.2

Collabora URL (used for Nextcloud to contact the Collabora server):


Collabora public URL (used in the browser to open Collabora):


Callback URL (used by Collabora to connect back to Nextcloud):
autodetected (will use the same URL as your user for browsing Nextcloud)

Going to that website gives “ok”.

Okay, I feel you. It is really a pain in the a* to set up nextcloud and collabora in docker containers.
I am running a docker compose yml with nextcloud, notify-push, nextcloud-cron, mariadb, redis, collabora.
I use caddy in a stand-alone container as reverse proxy.
I use nextcloud image which comes with apache2 webserver. That is pretty important.
I use collabora as a standalone server, do not use integrated code server from nextcloud, you will regret.
My set-up is working, almost, so it is possible for you as well.

Ideas to fix your set-up:

From your latest message, I realize you did not set your wopi url, public wopi url and your callback url. You have to do this, at least the first two.
Your caddy container has to be able to communicate with your collabora and nextcloud in the docker network.
In nextcloud go to nextcloud office and scroll down to advanced settings(maybe it is called different) and fill in allow list for WOPI requests: In my case I only have my internal docker network: 172.17.0.0/16. Nothing else.

Your caddyfile does not look right:
try at least for your collabora.yourdomain.be:
collabora.yourdomain.be {

encode gzip
reverse_proxy http://collabora:9980

}
Caddy is very picky with indentation. I use http: not https: –> ask me why
I use collabora that is my container name. Yours might differ.

Of course you have to configure your collabora image correctly.

I guess I will be more specific about where and what to fill in, if there are really follow up questions.

1 Like

I finaly found the errors!

The Wopi allowlist was an URL instead of an IP address.

Caddy was sending an own CSP-header connect-src and frame-src which blocked Collabora while Nextcloud itself was generating a valid CSP.

I had to remove this line in Caddy:
Content-Security-Policy “default-src ‘self’; script-src ‘self’ ‘unsafe-inline’; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data: blob:; connect-src ‘self’; font-src ‘self’; base-uri ‘self’; frame-ancestors ‘self’;” Referrer-Policy “no-referrer-when-downgrade”

2 Likes

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.