The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.
If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.
Getting help
In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.
Before clicking submit: Please check if your query is already addressed via the following resources:
(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).
The Basics
Nextcloud Server version (e.g., 29.x.x):
33.0.3.2
Operating system and version (e.g., Ubuntu 24.04):
You correctly identified the scripts responsible. Here is what actually happens, based on the NCP source code.
On every boot, NCP runs /usr/local/bin/nextcloud-domain.sh. That script reads the current overwrite.cli.url from your config and passes it to the set-nc-domain function in library.sh. That function does the following:
Strips the protocol from the URL to extract just the hostname
Pings the hostname (ping -c1 -w1)
If the ping fails, it discards the hostname and falls back to $(hostname) — the container’s own hostname
if ! ping -c1 -w1 -q "${domain}" &>/dev/null; then
unset domain
fi
if [[ "${domain}" == "" ]] || is_an_ip "${domain}"; then
echo "warning: No domain found. Defaulting to '$(hostname)'"
domain="$(hostname)"
fi
This is why directly editing config.php does not help — NCP overwrites overwrite.cli.url on the next boot regardless of what you put there.
The actual cause of the reset is that your public domain is not reachable via ICMP from inside the LXC container. This is a common situation when Nextcloud sits behind a reverse proxy: the public domain resolves to an external IP that is not routable from inside the container (split-DNS / hairpin NAT), or the domain’s host simply does not respond to ping.
The fix is to make the domain pingable from inside the container. The simplest way is to add a hosts file entry inside the LXC container pointing your domain to the reverse proxy’s IP:
Replace 192.168.x.x with the IP of your nginx reverse proxy as seen from inside the LXC container. After that, NCP’s boot script will be able to ping the domain, set-nc-domain will accept it, and overwrite.cli.url will be set correctly and stay set.
This is a known fragility in NCP’s domain detection. A related issue with overwrite.cli.url being corrupted is tracked at https://github.com/nextcloud/nextcloudpi/issues/2099, though the root cause there is different (Redis unavailable during upgrade). The ping-based validation approach is what you are hitting here.
One more thing worth mentioning: the underlying issue — your domain not being reachable from inside the container — is a classic split-brain DNS situation that every self-hoster eventually runs into, especially when hosting behind NAT. If you are not yet familiar with the concept, I would strongly recommend reading through this guide from our 101 series:
I consider this foundational knowledge for anyone hosting their own Nextcloud server. The /etc/hosts fix gets you going, but understanding split-brain DNS properly will save you from running into the same class of problem again in different forms.
@ernolf Thank you for responding so quickly! this fixed the issue! I also had to allow icmp in my firewall… . I already rewrite the domain in the internal DNS, but setting it also in the host file is a good redundancy!
. I already rewrite the domain in the internal DNS, but setting it also in the host file is a good redundancy!