About a month ago (to the day, as it so happens) I set up a Collabora server on the same machine as my Nextcloud so I could edit documents in my browser. At some point between then and now, something broke, and now I can’t get the Collabora web UI to last more than a few seconds before giving the message “Server has been shut down; please reload the page.”
It seems like a few other TrueNAS users have been having this issue, but since I have a specific error log, I thought I should come here with it. It’s
2025-07-08 23:04:23.136197+00:00wsd-00001-00033 2025-07-08 19:04:23.135959 -0400 [ websrv_poll ] ERR #30: Rejecting WebSocket upgrade with: origin [https://x.x.x.x:9980] expected [https://collabora.nas.mydomain.com] instead| net/WebSocketHandler.hpp:1039
Does anyone know how I can go about fixing this? I don’t think it’s an Nginx thing, since it happens even when I just directly connect to port 9980.
The core of the problem is that loolwsd will only accept a WebSocket‐upgrade whose Origin header exactly matches the “host” it was told to serve. In your case you’ve told it that its name (and certificate) is
https://collabora.nas.mydomain.com
but you are browsing it via
https://x.x.x.x:9980
so your browser sends
Origin: https://x.x.x.x:9980
and loolwsd rejects it:
“Rejecting WebSocket upgrade with: origin [https://x.x.x.x:9980]
expected [https://collabora.nas.mydomain.com] instead”
You have two realistic ways to fix this:
-
Browse over the “correct” name
Make sure you access your Collabora instance at the FQDN you configured.
For example, on your client machine add to /etc/hosts
x.x.x.x collabora.nas.mydomain.com
then point your browser at
https://collabora.nas.mydomain.com:9980
so that Origin = https://collabora.nas.mydomain.com and the WS upgrade will be allowed.
-
Whitelist your IP: add it to the allowed-origins in coolwsd.xml
If you really want to browse via the raw IP (not recommended for prod) you can tell loolwsd to also accept that Origin. In
/etc/coolwsd/coolwsd.xml
inside the <http> (and if you use an explicit <websocket> stanza, inside that too) add an <allow_domain> (or <origin>) entry for your IP:9980. For example, somewhere in the <http> section:
…
false
collabora.nas.mydomain.com
x.x.x.x:9980
And likewise in <websocket> if present:
…
false
collabora.nas.mydomain.com
x.x.x.x:9980
Then restart:
sudo systemctl restart coolwsd
Now Origin = https://x.x.x.x:9980 will be recognized as “allowed,” and your WebSocket handshake will succeed.
Ideally always use the FQDN you’ve configured (option 1). If you must test over the IP, add that IP:port into the <allow_domain> (allowed-origins) list (option 2), then restart coolwsd.
Is option 1 not what I’m already doing? I tested by connecting directly just to gather information for the post, but I do have an Nginx proxy host pointing at it (which I was negligent not to mention in the OP). It’s configured via the TrueNAS web UI, but I’ve copied the config to here, with the long blocks of whitespace shortened:
# ------------------------------------------------------------
# collabora.nas.mydomain.com
# ------------------------------------------------------------
map $scheme $hsts_header {
https "max-age=63072000;includeSubDomains; preload";
}
server {
set $forward_scheme https;
set $server "192.168.50.50";
set $port 9980;
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name collabora.nas.mydomain.com;
http2 on;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-cache.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /etc/letsencrypt/live/npm-10/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/npm-10/privkey.pem;
# Asset Caching
include conf.d/include/assets.conf;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /data/logs/proxy-host-10_access.log proxy;
error_log /data/logs/proxy-host-10_error.log warn;
location / {
# Access Rules: 1 total
allow 192.168.0.0/16;
deny all;
# Access checks must...
satisfy any;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
# Custom
include /data/nginx/custom/server_proxy[.]conf;
}
I tested it without that access restriction, and either way it leads to the same server shut-down error. So, to summarize:
- Navigating to
https://192.168.x.x:9980/browser/dist/admin/admin.html gives me the “Server has shut down” page, which I can brute force into not doing that for maybe 30 seconds if I retry a lot.
- Navigating to
https://collabora.nas.mydomain.com gives a 404 error with and without the access restriction. I’m not sure if this is expected behavior or if it’s supposed to redirect to a useful page from there.
- Navigating to
https://collabora.nas.mydomain.com/browser/dist/admin/admin.html gives the same result as the first bullet point.
I don’t quite recall where I got the information to add that webpage extension to the address, but it was probably cached in my browser from when the server did work.
Check the Collabora Container Logs
This is the most important step. The logs will almost certainly tell you why the service is crashing. Open a shell on your TrueNAS server and run:
# Find the name or ID of your collabora container
docker ps -a
# View the logs for the container
docker logs <name_or_id_of_collabora_container>
Look for any repeating error messages, especially ones that appear right before the service stops logging. Common errors relate to configuration, permissions, or network issues.
Also can you provide the version infromation ?
