Federated Cloud ID still shows /nextcloud suffix after NginxProxyManager reverse proxy setup

General Discussion
1

Hi all,

I have Nextcloud installed via dietpi-software on DietPi. As usual, DietPi installs it into its own subfolder, so locally it’s reachable at:

http://<dietpi-ip>/nextcloud

I’m using Nginx Proxy Manager (NPM, running in Docker on a separate/same host) as a reverse proxy to make it accessible externally under a clean subdomain:

https://nc.domain.net

The proxy host in NPM forwards to the internal DietPi address including the /nextcloud path, and the web UI itself works fine under nc.domain.net (login, files, etc. all load correctly).

The problem:
The Federated Cloud ID shown in Nextcloud’s personal settings still includes the internal subfolder, e.g.:

username@nc.domain.net/nextcloud

instead of the expected:

username@nc.domain.net

This breaks federated sharing with other Nextcloud/ownCloud instances, since the /nextcloud suffix is not part of the actual public URL.

What I’ve checked/tried so far:

  • The web interface itself works correctly under nc.domain.net (no visible /nextcloud in the browser).
  • trusted_domains in config.php includes nc.domain.net.
  • I have NOT yet set overwritewebroot, overwritehost, overwriteprotocol, or overwritecondaddr — unsure which combination is correct in this exact setup (DietPi’s Apache serving Nextcloud from /var/www/nextcloud, with NPM handling SSL termination and the subdomain mapping).

My questions:

  1. What is the correct config.php configuration (overwritewebroot, overwritehost, overwriteprotocol, trusted_proxies, overwritecondaddr) for a DietPi-managed Nextcloud install sitting behind NPM, given that DietPi’s automated update mechanism (dietpi-software) expects the /nextcloud subfolder to remain physically in place?
  2. Does occ maintenance:update:htaccess need to be run after changing these values, and will this survive a DietPi-triggered Nextcloud update, or does it need to be reapplied afterward?
  3. Are there any known NPM-side header settings (X-Forwarded-Proto, X-Forwarded-Host, etc.) that are required in addition to the config.php changes for the Federated Cloud ID to resolve correctly?
  4. Has anyone solved this exact scenario (DietPi + NPM + subfolder-to-subdomain mapping) without breaking local (non-proxied) access to <dietpi-ip>/nextcloud?

Setup details:

  • DietPi version: v10.6.2
  • Nextcloud version: 34.0.3
  • NPM version: v2.15.1
  • Infrastructure: Proxmox VE host running two separate VMs/LXCs — one for DietPi/Nextcloud, one for Nginx Proxy Manager. Both are on the same local network but communicate as separate hosts (not containers on the same Docker network).
  • Access method: NPM (separate VM/LXC) → forwards to DietPi VM’s internal IP on port 80/443 → Apache/Nextcloud

Any pointers to a working config.php + NPM configuration would be greatly appreciated. Thanks in advance!

2

There is an example config in the Nextcloud docs for your use case, to access it locally (via http) and externally via https.

If Nextcloud is reachable both directly (HTTP) and through a reverse proxy (HTTPS), or through multiple proxies serving different public domains, use overwritecondaddr to apply the overwrite parameters only when requests arrive from a specific proxy IP address.

I found also this statement in the NC forums

The Federated Cloud ID is derived from the overwrite.cli.url setting in your Nextcloud config.

So if I understand this correctly, you would need to set ( if DietPi = 192.168.1.20 and NPM = 192.168.1.30)

'trusted_domains' =>
[
    '192.168.1.20`',
    'nc.domain.net',
],

'trusted_proxies' =>
[
    '192.168.1.30',
],

'overwritehost' => 'nc.domain.net',
'overwriteprotocol' => 'https',
'overwritewebroot' => '/',
'overwrite.cli.url' => 'https://nc.domain.net',
'overwritecondaddr' => '^192\.168\.1\.30$',

What does overwritecondaddr do?
So if the request is comming from NPM IP host, protocol, webroot and cli URL is overwritten. But if you wanna also have correct cloud ID when accessed locally, you can not use overwritecondaddr (just don’t set it and it will overwrite always).
If you choose not to set it, you can still access it via dietpi-ip/nextcloud, but every link generated from nextcloud would be then based on nc.domain.net and not dietpi-ip/nextcloud. I hope this makes sense :slight_smile:

Restart apache and check:

ncc config:list system

Don’t mess with the headers and don’t do occ maintenance:update:htaccess (on dietpi its ncc btw, occ is for owncloud installations)