slow document loading due to coolmount permission errors

[sponch]

I am experiencing issues with my Collabora Online instance. Opening documents form Nexccloud (same cloudron insance) takes a very long time, and the logs show that the system is failing to set up the document jails using bind-mounts.

Instead of the fast bind-mount method, it seems Collabora is falling back to a slow recursive copy of system files because of missing permissions.
This error appears every time a document is opened.

Cloudron: 9.0.17
Ubuntu 22.04.5 LTS Linux 5.15.0-168-generic
Collabora Online 25.04.9.2.1

here's my log:

1-00106 2026-03-01 12:55:08.502103 +0000 [ websrv_poll ] WRN FileServerRequestHandler: File not found: Invalid URI request (hash): [/browser/a9b866688f/images/lc_themedialog.svg].| wsd/FileServer.cpp:1227
Mar 01 13:55:08 172.18.0.1 - - [01/Mar/2026:12:55:08 +0000] "GET /browser/a9b866688f/images/lc_themedialog.svg HTTP/1.1" 404 153 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
Mar 01 13:55:10 GET /api/healthcheck 200 2.207 ms - 2
Mar 01 13:55:10 172.18.0.1 - - [01/Mar/2026:12:55:10 +0000] "GET /api/healthcheck HTTP/1.1" 200 2 "-" "Mozilla (CloudronHealth)"
Mar 01 13:55:10 172.18.0.1 - - [01/Mar/2026:12:55:10 +0000] "GET /cool/https%3A%2F%2FMYNEXTCLOUDURL%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F62042_ocf60zurd5bl%3Faccess_token%3D03uzwn1vNsR7bB0cFtbFecPXKDOzXETw%26access_token_ttl%3D0%26no_auth_header%3D/ws?WOPISrc=https%3A%2F%2MYNEXTCLOUD URL.de%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F62042_ocf60zurd5bl&compat=/ws HTTP/1.1" 101 469057 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
Mar 01 13:55:12 sh: 1: /usr/bin/coolmount: Operation not permitted
Mar 01 13:55:12 sh: 1: /usr/bin/coolmount: Operation not permitted
Mar 01 13:55:12 sh: 1: /usr/bin/coolmount: Operation not permitted
Mar 01 13:55:15 2026/03/01 12:55:15 [info] 32#32: *31117 client 172.18.0.1 closed keepalive connection
Mar 01 13:55:20 GET /api/healthcheck 200 1.714 ms - 2
Mar 01 13:55:20 172.18.0.1

[james]

Hello @sponch
I was able to reproduce this issue and also have an idea how to fix this.

[sponch]

Something we can do or must that be done on your side?

[nebulon]

I've tested with SYS_ADMIN cap and the mount error goes away, however I cannot notice any speedups due to that though, but it might depend on how fast the filesystem is. Have to think about how to give collabora such wide system access.

[nebulon]

@sponch can you check how fast your disk I/O is (you can see this in your Cloudron dashboard in Server view). It seems quite risky to give that app such system capabilities as if it has a bug it can easily bring down the server. Might be good to first get an understanding what the root cause for slowness in your case really is.

[sponch]

I/O Rate of the VPS is about 2GB/s DiskIO between 1MB to peaks of 120MB during the last 24h. We are just testing if it is a client thing on one of our staff's Mac, where the problem occured ("long opening times" as the warning can be seen on each client),.

[nebulon]

that is much faster than on my server where I don't really see any difference and it is quite fast actually. I suspect something else is the issue there then.

[nebulon]

@sponch maybe you can enable remote ssh support for us and send a mail with the Cloudron's ip to support@cloudron.io I can then locally apply the patch to give collabora all those system permissions and we can evaluate if that is the root issue in the first place.

FYI to test this one can add the following at https://git.cloudron.io/platform/box/-/blob/master/src/docker.js?ref_type=heads#L731 :

    containerOptions.HostConfig.CapAdd.push('SYS_ADMIN');
    containerOptions.HostConfig.CapAdd.push('SYS_CHROOT');
    containerOptions.HostConfig.CapAdd.push('FOWNER');
    containerOptions.HostConfig.CapAdd.push('CHOWN');

Then systemctl restart box for good measure and then reinstall collabora in the same domain, as it is anyways stateless