Running Nextcloud + Collabora on TrueNAS SCALE with Nginx Proxy Manager

I've been using TrueNAS SCALE since 2022. Watching it spin off from TrueNAS CORE has been quite a journey and a great technology investment. Hail ZFS! A NAS system combining the power of Docker containers brings so many possibilities. I've been using it to run my own DNS server for blocking ads; paperless-ngx for scanning documents into digital copies; the Kavita ebook reader that is always online; Audiobookshelf that helps with downloading podcasts through metube, … The beauty is that all the data is centralized in one place, always online and private.

Most of them are quite easy to set up — they are self-contained apps; since TrueNAS SCALE Electric Eel (24.10) they are basically managed Docker Compose YAML files. This all works fine if all you need is inside a single app. Well, not the case anymore for Nextcloud. Surprisingly there isn't a blog post about this at all.

%%{init: {"themeVariables": {"fontSize": "13px"}}}%%
flowchart TB
    B["Browser"]
    NC["Nextcloud<br/>WOPI host"]
    CO["Collabora<br/>WOPI client"]

    B -- "loads editor" --> CO
    B -- "opens / auth" --> NC
    NC -- "editor config + token" --> B
    CO -- "WOPI / loads file" --> NC

This is not the first attempt. An earlier setup (2024) ran Nextcloud and OnlyOffice in a single Docker Compose file following Thomas Wilde's blog. It worked for a while — routing between Nextcloud, Collabora, and OnlyOffice was fully connected, and it was fully compatible with my reverse proxy as well. The problem was that I now had to maintain their upgrades myself. Boy oh boy, did I underestimate the upgrade bugs 😱 such as this and this. The workaround was pinning the Nextcloud and Collabora images (nextcloud:31.0.9 and collabora/code:24.04.12.3.1) for months. Well, not the situation I was hoping for.

Speaking about traffic routing, the workaround was being able to manually specify DNS servers in docker-compose.yaml: pointing the containers at the LAN DNS servers (dns:) and pinning each other's public hostnames to the host IP (extra_hosts:), so traffic left the Docker network and came back through NPM. It avoided bundling an extra nginx proxy, but made container networking depend on hand-maintained DNS entries. The setup also carried overwriteprotocol=https and trusted_proxies in config.php, which is required in the new setup as well.

Domain Names:         nextcloud.example.com
Scheme:               http
Forward Hostname/IP:  <Nextcloud reachable address>
Forward Port:         <Nextcloud published port>

Domain Names:         collabora.example.com
Scheme:               http
Forward Hostname/IP:  <Collabora reachable address>
Forward Port:         9980

The obvious next step was a shared Docker network: docker network create nextcloud, have both containers join it, and let Nextcloud talk to Collabora directly at http://collabora:9980. TrueNAS Apps actually support this — App containers can be attached to a predefined Docker network straight from the App configuration, no manual docker network connect required.

I did not continue down this path for one reason: NPM. The reverse proxy would have to be hacked into the same network as well, and its proxy hosts rewritten to forward to the container aliases — nextcloud.example.com and collabora.example.com resolving to container names instead of published host ports. That puts the LAN DNS records, the container DNS, and the proxy aliases in three places that all have to agree, for what should be a single routing decision. Since both services are already reachable by hostname through NPM, there was no compelling reason to introduce that coupling.

The new setup keeps the good idea — route everything through the reverse proxy by public hostname — and drops the rest: the office stack moves into TrueNAS Apps so the platform owns the upgrades, and LAN DNS + NPM replaces the docker-DNS plumbing. The final architecture is intentionally simple:

%%{init: {"themeVariables": {"fontSize": "13px"}}}%%
flowchart TB
    WC["nextcloud.example.com"]
    CC["collabora.example.com"]
    NPM["<b>Nginx Proxy Manager</b><br/>192.168.100.10"]
    NC["Nextcloud<br/>container"]
    CO["Collabora<br/>CODE container"]

    WC -- HTTPS --> NPM
    CC -- HTTPS --> NPM
    NPM --> NC
    NPM --> CO

The key decision, inherited from the old setup and kept deliberately:

Nextcloud and Collabora do not need to share a Docker network.

Both services are reached through their normal public hostnames, and Collabora calls back to Nextcloud over the same DNS → NPM path that every other client uses:

https://nextcloud.example.com
https://collabora.example.com

On the LAN, the custom DNS server points both hostnames at NPM's physical address:

nextcloud.example.com    → 192.168.100.10
collabora.example.com    → 192.168.100.10

Containers live in a second DNS world: Docker's embedded resolver (nameserver 127.0.0.11 in /etc/resolv.conf) forwards to whatever upstreams the container was given, in this case the truenas. The check that matters is inside: the containers:

getent hosts nextcloud.example.com
getent hosts collabora.example.com

Both should resolve to NPM. As the TrueNAS docs put it:

By default, containers use the DNS settings from the host system. You can change the DNS policy and define separate nameservers and search domains.

(TrueNAS custom App screens) — which is exactly the knob that made the old setup's dns: entries necessary, and what makes this setup possible, (hopefully ixsystems never changes this, also I heard Truenas 26 offers customized per-app DNS nameserver configurations).

The configuration that makes the final architecture work, in the order I would apply it.

getent hosts nextcloud.example.com
getent hosts collabora.example.com

curl -vk https://nextcloud.example.com/status.php

curl -vk https://collabora.example.com/hosting/discovery

aliasgroup1=https://nextcloud.example.com:443

WOPI::CheckFileInfo returned 403 (Forbidden)

WOPI request denied from 172.20.1.1

php occ config:app:set richdocuments \
    wopi_allowlist \
    --value="172.20.0.0/16"
php occ config:app:get richdocuments wopi_allowlist

environment:
  - OVERWRITECLIURL=https://nextcloud.example.com
  - OVERWRITEPROTOCOL=https

NEXTCLOUD_TRUSTED_DOMAINS=${THE_DOMAIN}

Environment variable [NEXTCLOUD_TRUSTED_DOMAINS]
is already defined from the application developer.

'trusted_proxies' => [
    '192.168.100.10',
],

Failed to get settings json from
[http://nextcloud.example.com/index.php/apps/richdocuments/wopi/settings?...]
with status[Moved Permanently]

php occ config:system:get overwriteprotocol

php occ config:system:set overwriteprotocol --value=https

php occ config:app:get richdocuments wopi_allowlist

php occ config:app:set richdocuments \
    wopi_allowlist \
    --value="172.20.0.0/16"

getent hosts nextcloud.example.com
getent hosts collabora.example.com

curl -vk https://nextcloud.example.com/status.php

curl -vk https://collabora.example.com/hosting/discovery

docker info | grep -i dns

cat /etc/resolv.conf

docker inspect <container> \
    --format '{{json .HostConfig.Dns}}'

docker ps --format 'table {{.Names}}\t{{.Image}}'

Several things were initially tempting but turned out to be unnecessary or misleading:

1. A shared Docker network is not required. Nextcloud and Collabora can communicate through their normal HTTPS hostnames and NPM.
2. The physical LAN DNS record does not need to point into the Docker network. It can correctly point to NPM.
3. Read the log before touching anything else. The WOPI denial message states both the source address and the configured ranges verbatim.
4. aliasgroup1=https://... does not by itself guarantee that every URL generated by the Nextcloud/Collabora integration will use HTTPS.
5. TrueNAS App environment variables may already be owned by the App template. Don't duplicate variables such as NEXTCLOUD_TRUSTED_DOMAINS when the App already defines them.
6. NPM's HTTP→HTTPS redirect can break backend WOPI requests. If Collabora receives a URL beginning with http://, it may get a Moved Permanently response instead of the expected WOPI data.

• Setting up Nextcloud With Docker Compose — Thomas Wilde Tech
• CollaboraOnline/online#11280
• CollaboraOnline/online#11279
• ONLYOFFICE/Docker-DocumentServer#352 — Excessive processes and memory usage
• Nextcloud admin manual — Reverse proxy configuration (overwriteprotocol, trusted_proxies)
• nextcloud/richdocuments — the Nextcloud ↔ Collabora integration app
• Collabora Online (CODE) Docker image
• WOPI REST API reference
• Nginx Proxy Manager
• TrueNAS SCALE — custom App installation screens (DNS policy quote)