How to pass --o:security.capabilities=false to collabora container in Nextcloud AIO


is there any way to pass the env parameter --o:security.capabilities=false to collabora container created by Nextcloud AIO?

Obviously I can do it manually but it gets overwritten after every update and collabora just does not work without this workaround in my setup (NAS with limited configuration options).

It is just getting tedious doing it after every update.


Hi, see GitHub - nextcloud/all-in-one: Nextcloud AIO stands for Nextcloud All In One and provides easy deployment and maintenance with most features included in this one Nextcloud instance.

Hi, this option passes --o:security.seccomp=false to collabora container, I have it already enabled, but this is not the one I am looking for.

Ah I see. Why do you need to disable the security capabilities?

TL,DR - it does not work without it, Nextcloud wont connect to collabora container

I cant grant the required capabilities ( cap_sys_chroot, cap_mknod, cap_fowner), they are not available with my docker setup - I guess the combination of limited options on NAS and the storage driver used (vfs). As my setup is more like playground/testbench for the deployment I am planning later on the different system where these constraints will most likely not be present, I cannot be bothered to deal with it when --o:security.capabilities=false on collabora container works just fine.

Did you already follow How to debug problems with Collabora and/or Talk · Discussion #1358 · nextcloud/all-in-one · GitHub?

I tried now, but it is not of much help since Nextcloud will not even connect to collabora container, so I do not have option to modify Allow list for WOPI requests

Even when I expose 9980 from the collabora container manually I get Connection timeout

For the second part

curl -vvv https://mydomain:443/hosting/discovery (domain name edited)

*   Trying
* Connected to mydomain.tld ( port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* 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_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=mydomain.tld
*  start date: Feb 18 19:55:40 2023 GMT
*  expire date: May 19 19:55:39 2023 GMT
*  subjectAltName: host "mydomain.tld" matched cert's "mydomain.tld"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* h2h3 [:method: GET]
* h2h3 [:path: /hosting/discovery]
* h2h3 [:scheme: https]
* h2h3 [:authority: mydomain.tld]
* h2h3 [user-agent: curl/7.83.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x7fec328aa1b0)
> GET /hosting/discovery HTTP/2
> Host: mydomain.tld
> user-agent: curl/7.83.1
> accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 502
< server: nginx/1.18.0
< date: Fri, 03 Mar 2023 19:18:33 GMT
< content-length: 0
* Connection #0 to host mydomain.tld left intact

Where does this come from? Is this the ip-address of the host running AIO?

Also can you check if How to fix sudden dns resolution issues after the AIO update to v4.4.1 or higher. · nextcloud/all-in-one · Discussion #2065 · GitHub helps? is an IP of reverse proxy on my local network.

Edit: Looking at the description of the issue you linked it should not apply since my Nextcloud instance was first created in Sep 2022

Is the reverse proxy config up-to-date with the one in

Yes as per my best knowledge, see below:

map $http_upgrade $connection_upgrade {
default upgrade;
‘’ close;

server {
listen 80;
listen [::]:80; # uncomment to use IPv6

if ($scheme = "http") {
    return 301 https://$host$request_uri;

listen 443 ssl http2;
listen [::]:443 ssl http2; # uncomment to use IPv6

server_name nextcloud.mydomain.tld;

location / {

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    client_max_body_size 0;

    # Websocket
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

ssl_certificate /etc/letsencrypt/live/mydomain.tld/fullchain.pem;   # managed by certbot on host machine
ssl_certificate_key /etc/letsencrypt/live/mydomain.tld/privkey.pem; # managed by certbot on host machine

ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;


Okay, so basically we are now back to fhe drawing board since everything seems to be correctly configured.

Can you fix this somehow maybe?

I dont see us fixing things in aio when docker does not work as expected…

I do not want you to fix anything actually :smiley: I know my docker setup is … well, lets say suboptimal. I am looking for a way for a known workaround to survive update process, that is all.

Fixing the issue would require to get a system with a “normal” kernel which is not an option since it is a Western Digital NAS and I am stuck with their firmware.

Yes I agree.

I see however due to the architecture of AIO you cannot add this change permanently except if we add this as yet another option which we already have too much of.

Can you maybe check if this app works for you?

Unfortunately, the app you linked crashes whole mastercontainer, so it is not an option either.

But again, I understand that mine is a niche case and it is not viable to attend to, especially because it is not a bug per se, but a limitation on host sytem.

1 Like