Document fails to load after successful WSS handshake (old version `Nextcloud Office 8.6.1` works perfectly)

[wingerdewing]

Environment information

• Nextcloud version: 31.0.4.1
• Richdocuments app version: 8.6.4 (Problem also observed briefly with 8.6.3 during testing)
• Collabora Docker image: collabora/code:latest (Image ID starting c9186... as of 2025-04-23, CODE version 24.04.13.3)
• Collabora Host OS: Debian 12 (bookworm), Kernel 6.1.0-33-amd64
• Reverse Proxy: Apache/2.4.62 (Debian) (on the same host as Docker)
• Database: MariaDB 10.11.11
• PHP version: 8.2.28 (cli) with OPcache
• Client OS/Browser: Linux / Firefox 137 & Chrome 135 (Problem occurs in both)

Important Version Information

When I am downgrading to Nextcloud Office 8.6.1 everything works without a problem!

Describe the bug

Setting up Collabora Online (via Docker) with Nextcloud behind an Apache reverse proxy fails when trying to open an office document (.odt, .docx, etc.).

1. The Nextcloud Admin Settings -> Office page correctly reports "Collabora Online Server is reachable." and displays the correct HTTPS URL for the Collabora server (https://office.mysite.com) after saving.
2. Direct curl requests from the Nextcloud server to the Collabora proxy URL (https://office.mysite.com/hosting/discovery and /hosting/capabilities) return valid responses (Status 200 OK, correct JSON/XML content).
3. When attempting to open an .odt document (newly created or existing):
   • The Nextcloud UI shows the loading indicator.
   • Browser Developer Tools (Network Tab) show a successful WebSocket handshake (Status 101 Switching Protocols) to wss://office.mysite.com/cool/.../ws.
   • The Collabora server sends the initial coolclient ... load url=... message via the established WebSocket.
   • No visible errors are reported in the Browser Console.
   • After a timeout, Nextcloud displays the error message: "Failed to load document. Nextcloud Office could not be loaded - please try again later".

Steps to reproduce

1. Set up Nextcloud 31.0.4.1 with Richdocuments 8.6.4.
2. Set up Collabora Online (collabora/code:latest) via Docker behind an Apache 2.4 reverse proxy on the same host, using the provided Apache config and Docker script (see Server details below).
3. Configure the Collabora server URL (https://office.mysite.com) in Nextcloud Admin -> Office settings and save. Verify that the connection check is successful and shows the correct HTTPS URL.
4. Go to the Nextcloud Files app.
5. Click on any .odt or .docx file.
6. Observe the loading screen within Nextcloud.
7. See the error "Failed to load document..." after a timeout.
8. Observe Browser Dev Tools: Network tab shows successful WSS handshake (101), Console tab shows only the final timeout error from Office.vue.
9. Observe Collabora Docker logs (with debug level): Shows successful CheckFileInfo followed by Error while invoking onFinished client callback: Access to file denied.

Expected behavior

The document should open within the Collabora Online editor embedded in Nextcloud after the WebSocket connection is established.

Actual behavior

The document fails to load with a generic error message in Nextcloud, despite a successful WebSocket handshake. Debug logs from Collabora reveal an internal error after successfully receiving file metadata from Nextcloud.

Configuration of the richdocuments app
(Output of ./occ config:list richdocuments)

{
    "apps": {
        "richdocuments": {
            "canonical_webroot": "",
            "disable_certificate_verification": "yes",
            "enabled": "yes",
            "external_apps": "",
            "installed_version": "8.6.4",
            "public_wopi_url": "https:\/\/office.mysite.com",
            "types": "prevent_group_restriction",
            "wopi_allowlist": "",
            "wopi_url": "https:\/\/office.mysite.com"
        }
    }
}

Relevant Configurations (Anonymized)

Apache VirtualHost (office.mysite.com.conf):

# ==============================================================================
# Apache VirtualHost für Collabora Online Reverse Proxy
# STAND: Reproduktion "Backend OK" (Final)
# ==============================================================================
<VirtualHost *:443>
    ServerName office.mysite.com # Anonymized

    # --- SSL Konfiguration ---
    SSLEngine On
    # Replace with your actual certificate paths
    SSLCertificateFile /path/to/your/certificate.pem
    SSLCertificateKeyFile /path/to/your/private.key

    # --- Proxy Grundeinstellungen ---
    ProxyTimeout 300
    AllowEncodedSlashes NoDecode
    SSLProxyEngine On
    ProxyPreserveHost On
    # ProxyAddHeaders On # Standard, Apache fügt X-Forwarded-* hinzu.

    # --- Logging ---
    ErrorLog ${APACHE_LOG_DIR}/office.mysite.com_error.log # Anonymized
    ServerSignature Off
    CustomLog ${APACHE_LOG_DIR}/office.mysite.com_access.log combined # Anonymized

    # --- Proxy Weiterleitungsregeln ---
    ProxyPass /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
    ProxyPassReverse /hosting/discovery http://127.0.0.1:9980/hosting/discovery

    ProxyPass /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
    ProxyPassReverse /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

    ProxyPassMatch "/cool/(.*)/ws$" ws://127.0.0.1:9980/cool/$1/ws nocanon

    ProxyPass /cool/adminws ws://127.0.0.1:9980/cool/adminws nocanon

    ProxyPass /cool http://127.0.0.1:9980/cool retry=0
    ProxyPassReverse /cool http://127.0.0.1:9980/cool

    ProxyPass /browser http://127.0.0.1:9980/browser retry=0
    ProxyPassReverse /browser http://127.0.0.1:9980/browser

    # --- Sicherheit ---
    ProxyRequests Off
    <Proxy *>
        Require all granted
    </Proxy>
    <Location />
        Require all granted
    </Location>

    # --- Header Manipulation ---
    RequestHeader set X-Forwarded-Proto "https"

    # --- Zusätzliche Sicherheitsheader ---
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

</VirtualHost>

1. Docker Image:
collabora/code:latest

2. Docker Run Command:

The container was launched using the following command:

docker run -d \
  --name collabora \
  -p 127.0.0.1:9980:9980 \
  -e "aliasgroup1=https://mysite\\.com" \
  -e "extra_params=--o:logging.level=none" \
  -e "systemplate_readonly=false" \
  --memory="3g" \
  --memory-swap="3g" \
  --restart always \
  --cap-add MKNOD \
  --add-host "office.mysite.com:172.17.0.1" \
  --add-host "mysite.com:172.17.0.1" \
  -e 'username=admin' \
  -e 'password=test' \
  -v "/opt/collabora/coolwsd/coolwsd.xml:/etc/coolwsd/coolwsd.xml:ro" \
  -v "/opt/collabora/cache:/opt/cool/cache" \
  collabora/code:latest

(Note: The admin password is a placeholder here)

3. coolwsd.xml Modifications:

The default /etc/coolwsd/coolwsd.xml from the image was modified using xmlstarlet before mounting it into the container. The following changes were applied:

• //net/proto: Set value to IPv4.
• //net/post_allow: A new <host> entry was added: <host desc="Own public server IP" allow="true">185.*****</host>.
• //logging/level: Set value to none.
• //logging/level_startup: Set value to none.
• //net/service_root: Set value to an empty string ("").
• //remote_font_config/url: Set value to https://mysite.com/nextcloud/index.php/apps/richdocuments/settings/fonts.json

Logs

Nextcloud log (data/nextcloud.log)

(Set loglevel => 0 in config.php first)

# PASTE RELEVANT NEXTCLOUD LOG OUTPUT HERE
# Especially look for errors related to richdocuments or WOPI around the time of opening the document.
# Check if there are any entries related to the failed call to /wopi/settings?type=systemconfig

Collabora log (docker logs collabora - with debug level)

(Captured when trying to open the document)

# PASTE ANONYMIZED COLLABORA DEBUG LOGS HERE
# Ensure logs show the successful CheckFileInfo followed by the "Access to file denied" error in the callback,
# ideally pointing to the request for /wopi/settings?type=systemconfig.
wsd-... [ websrv_poll ] DBG  #YY: WOPI::CheckFileInfo (XXXms): {"BaseFileName":"...", "UserCanWrite":true, ...}
wsd-... [ websrv_poll ] DBG  Getting settings from [https://mysite.com/.../wopi/settings?type=systemconfig...]
wsd-... [ websrv_poll ] DBG  #-1: starting asyncRequest: GET mysite.com:443 /nextcloud/.../wopi/settings?...
wsd-... [ websrv_poll ] ERR  #ZZ: Error while invoking onFinished client callback: Access to file denied| net/HttpRequest.hpp:1515
wsd-... [ docbroker_XXX ] WRN  getNewChild: No child available... Timed out...

Browser log (Console tab)

[INFO] viewer: Opening viewer for file ...
[getWopiUrl] https://mysite.com/nextcloud/index.php/apps/richdocuments/wopi/files/...
[viewer] Received post message App_LoadingStatus { Status: "Initialized" }
Document loading failed due to timeout: Please check for failing network requests richdocuments-viewer.js:2:1834298 # Or similar line number
    loadingTimeout Office.vue:XXX
    ... (VueJS trace) ...
```*(Add any other red errors seen in the console)*

</details>

**Additional Context:**

*   WebSocket connection (`wss://office.mysite.com/cool/.../ws`) establishes successfully (Status 101).
*   The initial `coolclient ... load url=...` message is sent via WebSocket.
*   The problem seems specific to the internal processing within Collabora *after* receiving a successful `CheckFileInfo` response, possibly related to accessing `/wopi/settings?type=systemconfig`, resulting in `Access to file denied`.

**Request:**

Could you please investigate why Collabora might encounter an internal "Access to file denied" after a successful `CheckFileInfo`, specifically when processing the response or querying `/wopi/settings?type=systemconfig` in this Apache reverse proxy setup with Nextcloud `31.0.4.1` and Richdocuments `8.6.4`? The configuration seems correct according to documentation and debug logs show necessary headers (`X-Forwarded-Proto`) are received, and the relevant server IP is listed in `post_allow`.

[wingerdewing]

The primary reason for attempting this Docker setup is the suboptimal performance experienced with the Collabora Online - Built-in CODE Server app. While the built-in server works functionally, the Docker solution is preferred for better performance and resource management.

However, despite confirming correct reverse proxy configuration (verified header forwarding, successful /hosting/discovery and /hosting/capabilities checks from the Nextcloud backend, successful WSS handshake from the browser) and resolving initial Docker permission and network issues, opening documents consistently fails.

The final blocking point appears to be an internal Access to file denied error logged by Collabora after it successfully receives the CheckFileInfo response from Nextcloud, preventing the document from being loaded by the child process (leading to the observed frontend timeout). This occurs even with the Nextcloud server's IP explicitly added to Collabora's post_allow list.

With 15+ years of Linux sysadmin experience, I've exhausted the usual troubleshooting paths for proxy and container setups.

Any insights, hints, or suggestions from the development team on what might be causing this internal access denial or how to further debug it would be greatly appreciated!

[wingerdewing]

I downgraded to Nextcloud Office 8.6.1 and now I can open ODT-files!

I stumbled about this tipp here: CollaboraOnline/online#11279 (comment)

But I am afraid, that this bug will be in future releases, too.

[wingerdewing]

I didn't mean to close the issue.

[wingerdewing]

Problem still remains with Nextcloud Office 8.6.5 and Collabora Online Development Edition 25.04.2.1 0968141f2c.

Office files, like ODT-files, can not be opend:
First it shows Failed to load Nextcloud Office - please try again later and after a while it switches to:
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

But my Proxy-Settings are pretty vanilla:

<VirtualHost *:443>
    ServerName office.<my-host>

    SSLEngine On
    SSLCertificateFile /etc/ssl/localcerts/letsencrypt/certs/letsencrypt-all_cert-and-chain.pem
    SSLCertificateKeyFile /etc/ssl/localcerts/letsencrypt/certs/letsencrypt-all_privKey.pem

    ProxyTimeout 300
    AllowEncodedSlashes NoDecode
    SSLProxyEngine On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off

    ProxyPreserveHost On

    ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
    ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery

    ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
    ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities

    ProxyPassMatch "/cool/(.*)/ws$" wss://127.0.0.1:9980/cool/$1/ws nocanon

    ProxyPass /cool/adminws wss://127.0.0.1:9980/cool/adminws

    ProxyPass /cool https://127.0.0.1:9980/cool
    ProxyPassReverse /cool https://127.0.0.1:9980/cool
    ProxyPass           /lool https://127.0.0.1:9980/cool
    ProxyPassReverse    /lool https://127.0.0.1:9980/cool

    ProxyPass /browser https://127.0.0.1:9980/browser retry=0
    ProxyPassReverse /browser https://127.0.0.1:9980/browser
</VirtualHost>

Docker:

docker run 
-t 
-d 
--name collabora 
-p 127.0.0.1:9980:9980 
-e domain=myhost\.de 
-e aliasgroup1=https://myhost\.de 
-e extra_params=--o:logging.level=none 
-e systemplate_readonly=false 
--memory=3g 
--memory-swap=3g 
--restart always
--cap-add MKNOD 
--add-host office.<my-host>.de:172.17.0.1 
--add-host <my-host>.de:172.17.0.1 
-v /opt/collabora/coolwsd/coolwsd.xml:/etc/coolwsd/coolwsd.xml:ro 
-v /opt/collabora/cache:/opt/cool/cache collabora/code:latest

When I downgrade to Nextcloud Office 8.6.1: EVERYTHING WORKS AGAIN.

Is there anyone out there using 8.6.4/8.6.5 with the collabora-docker-image and it's working? Please help me out here!

[wingerdewing]

I also disabled my firewall, I can not get it to work with 8.6.4/8.6.5. But 8.6.1 works instantly. I am getting crazy with this ...

[elzody]

I didn't actually find any Nextcloud logs in your post anywhere, so I can't speak to those. But seeing as versions after 8.6.1 do not work for you, it is definitely something related to the introduction of #4525. I am not able to reproduce the issue; I will have to do a bit more digging, but in the meantime if there are any entries at all in the data/nextcloud.log file that you think could help, please share them.

[wingerdewing]

@elzody, thank you so much for your reply!

I cleaned up the logfile and tried to only log everything, between the click on an ODT-file and the error-response (loglevel 0). See the attached logfile for the details.

I blanked out my real domain with "mysite" for privacy reasons.

blankedout.txt

[wingerdewing]

@elzody: still same problem with Nextcloud Office 8.7.1 and Collabora Online Development Edition 25.04.2.2 636e10a2b1.

When I click on an ODT-file: "Document loading failed - Failed to load Nextcloud Office - please try again later" and after a few moments "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" - exactly same problem.

I guess nobody looked at my last "blankedout.txt" logfile, but here is the new one with NC Office 8.7.1:

error-log-opening-odt-file.txt

When I downgrade to NC Office 8.6.1 everything works again. Wtf am I doing wrong?! Would really appreciate some help <3