Collabora/Nextcloud Office not working after Bookworm upgrade

Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 32.0.7
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 12 Bookworm
  • Web server and version (e.g, Apache 2.4.25):
    • Apache/2.4.66
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • apache2 2.4.66 (Debian)
  • PHP version (e.g, 8.3):
    • 8.3
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • NCP
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

After upgrading from Debian 11 (Bullseye) to Debian 12 (Bookworm) and Nextcloud 26 to 32, I can no longer open office documents. I’m running NextCloudPi 1.56 on a Raspberry Pi 4B (ARM64), NC 32.0.7, PHP 8.3, Debian 12 Bookworm.

Simply re-installing Nextcloud Office and Collabora didn’t help.

To be perfectly honest, I did try to properly purge some PHP versions in the past with the help of Claude AI. But I doubt that it should have had an affect on the Office Situation. Anyway, I asked Claude again to help me analyzing the root of the problem, so this is where my log outputs come from… Please tell me if there is utter bullsh*t in the analysis. I am still a coding noob.

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

  1. Open any office document (odt, ods, xlsx, docx, etc…) in the browser: hangs at “loading”
  2. I just realized that I can open documents in the Nextcloud Android App but I got a certificate error message first. After trusting the certificate, the office editor managed to load up fine.

What works:

Collabora process is running:

ps aux | grep -i "coolwsd\|AppImage" | grep -v grep

Output confirms coolwsd running on port 9983 and AppImage active.

Port 9983 responds correctly:

curl -k -s http://localhost:9983/hosting/capabilities

Returns full capabilities JSON including "productName":"Collabora Online Development Edition".

proxy.php responds when called directly:

curl -k -s https://nextcloudpi/apps/richdocumentscode_arm64/proxy.php

Returns: Socket proxy error: The param should be 'status' or 'req=...', but is: '' — meaning proxy.php is reachable.

What doesn’t work:

Nextcloud log shows cURL timeout errors:

sudo tail -20 /media/myCloudDrive/ncdata/nextcloud.log | grep -i "richdoc\|collabora\|wopi\|cool"
```
Output shows repeated errors:
```
cURL error 28: Operation timed out after 5001 milliseconds with 0 bytes received 
for https://nextcloudpi/apps/richdocumentscode_arm64/proxy.php?req=/hosting/capabilities

This issue persisted after upgrading from NC 32.0.6 to NC 32.0.7 and PHP 8.1 to PHP 8.3.

Key finding:

Apache configuration has no Collabora proxy entries:

sudo cat /etc/apache2/sites-enabled/001-nextcloud.conf | grep -i "cool\|collabora\|9983"
find /etc/apache2 -name "*.conf" | xargs grep -l "9983\|coolwsd\|collabora"

Both return nothing. The file /etc/apache2/sites-enabled/001-nextcloud.conf only contains notify_push proxy entries and states at the top it is auto-generated by NCP. The Collabora proxy entries appear to be missing after the upgrade.

WOPI URL configuration:

sudo -u www-data php /var/www/nextcloud/occ config:app:get richdocuments wopi_url

Returns: https://nextcloudpi/apps/richdocumentscode_arm64/proxy.php?req=

Question: What NCP command or procedure regenerates the Apache configuration including the Collabora proxy entries for the ARM64 built-in CODE server?

OK, I think it might have to do with the new richdocuments version (richdocumentscode_arm64 25.4.904) being stricter about certificates than the old one.

Coolwsd cannot verify the self-signed certificate of nextcloudpi when fetching the remote font config URL (https://nextcloudpi/apps/richdocuments/settings/fonts.json). This causes coolwsd to enter a broken state, returning 400 errors on document conversion requests.

coolwsd log: Failed to verify the certificate of [nextcloudpi]
coolwsd enforces HTTPS for font config — HTTP is rejected at startup
Collabora works fine on Android after manually trusting the cert
curl to port 9983 works fine directly

How should NCP configure the internal nextcloudpi hostname to use the Let’s Encrypt certificate so coolwsd can verify it?

You shouldn’t use “https://nextcloudpi” as address for Nextcloud in Collabora, because that address cannot have a valid Letsencrypt certificate (even the one you get for your public domain would fail for anything else).

Instead, use either http://localhost (no https) or https:// - the latter could come with a performance hit depending on your network setup.

2 Likes

It seems that coolwsd cannot verify the self-signed certificate of the internal nextcloudpi hostname when fetching the remote font config URL:

https://nextcloudpi/apps/richdocuments/settings/fonts.json

coolwsd log:

Failed to verify the certificate of [nextcloudpi]
Remote config server has response status code: 0 (Unknown)

coolwsd enforces HTTPS for the font config URL and rejects HTTP at startup:

Remote config url should only use HTTPS protocol

What I tried:

  • http://localhost as wopi_url → coolwsd rejects HTTP for font config

  • https://"myserverdomain.xxx.xx" as wopi_url → times out (NAT loopback issue, Pi can’t reach itself via external domain server-side)

  • disable_certificate_verification = yes → set but doesn’t affect coolwsd’s own certificate verification

What is the correct way to configure the internal hostname certificate so coolwsd can verify it, or alternatively how to configure the font config URL to avoid this certificate issue?

The coolwsd log confirms the issue: Collabora cannot verify the self-signed certificate that NextcloudPi uses internally. After the Bookworm upgrade, the Collabora/coolwsd service likely got updated to a version with stricter SSL verification defaults.

Two fixes depending on your setup:

Option 1 — Add the self-signed cert to Collabora’s trust store:

Copy your NextcloudPi’s self-signed certificate to Collabora’s CA directory:

sudo cp /etc/ssl/certs/ssl-cert-snakeoil.pem /usr/local/share/ca-certificates/nextcloudpi-selfsigned.crt
sudo update-ca-certificates
sudo systemctl restart coolwsd

If you are running Collabora in Docker, you need to mount the cert into the container and run update-ca-certificates inside it, or pass it via the extra_params environment variable.

Option 2 — Tell coolwsd to skip SSL verification for the internal connection:

Edit /etc/coolwsd/coolwsd.xml and find the <ssl> section. Set:

<ssl desc="SSL settings">
    <termination desc="Connection via proxy">true</termination>
    <enable desc="Controls...">false</enable>
</ssl>

Or more specifically, look for the <verification> setting within the storage SSL section and set it to false for internal connections only.

Option 1 is the cleaner approach since it keeps SSL verification working. Option 2 is a quick workaround if you cannot easily distribute the cert. After either change, the fonts.json fetch should succeed and documents should load again.

Thanks for the detailed response!

Option 1

I tried this:

sudo cp /etc/ssl/certs/ssl-cert-snakeoil.pem /usr/local/share/ca-certificates/nextcloudpi-selfsigned.crt
sudo update-ca-certificates

Then killed and restarted coolwsd. Unfortunately the certificate error persisted. I believe this is because Collabora runs as an AppImage which bundles its own CA certificates internally and does not use the system trust store at all?

Option 2

I could not find a standalone /etc/coolwsd/coolwsd.xml — the config file lives inside the AppImage mount at /tmp/.mount_CollabXXXXXX/etc/coolwsd/coolwsd.xml and gets recreated after each restart?

After reading the NCP Apache template at /usr/local/etc/ncp-templates/nextcloud.conf.sh, I found what I believe is the root cause:

The template only sets ServerName mydomain.xxx.xx for the VirtualHost using the Let’s Encrypt certificate. There is no ServerAlias nextcloudpi — so when coolwsd connects to https://nextcloudpi/apps/richdocuments/settings/fonts.json, Apache serves that request with the self-signed certificate instead of the Let’s Encrypt one, which coolwsd cannot verify.

What about this as a fix?

Adding ServerAlias nextcloudpi to the <VirtualHost _default_:443> block in the NCP template would cause Apache to serve the nextcloudpi hostname with the Let’s Encrypt certificate, which coolwsd can verify.

However since /usr/local/etc/ncp-templates/nextcloud.conf.sh is NCP-managed, I want to confirm:

Is modifying this template the correct approach?

Will it survive future NCP updates?

Is there a better NCP-supported way to add this ServerAlias?