Nextcloud AIO is ignoring host dns settings

Hello everyone,
Thank you for reading this.
I’m running into an issue where nextcloud a.i.o. is not using the dns setup of the host system.

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • Nextcloud Hub 10 (31.0.0) via a.i.o.
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 12 (running on proxmox_
  • Web server and version (e.g, Apache 2.4.25):
    • latest from a.i.o.
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • Nginx Proxy Manager (running on the same docker host)
  • PHP version (e.g, 8.3):
    • Managed by a.i.o.
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • After installing AIO and going trough the data migration
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No, just a straight port forward to mu reverse proxy

Summary of the issue you are facing:

Nextcloud a.i.o. seems to be ignoring my hosts dns settings.
I’ve set troughout my network an adguard home dns server as the primary resolver.
This adguard home instance (docker) points my nextcloud domain to the internal (192.###.###.###) adres.
My other dockerized applications use this without any issue.
However, my nextcloud containers seems to be ignoring it, and always resolving to my external IP. (45.###.###.###).

This makes it so that for example collabora does not work.
This example query is from the collabora container, though others have the same issue.

For me this looks like a.i.o. is ignoring my hosts dns settings, as other container on the same host do resolve it correctly.

I am however able to access nextcloud itself. So the containers are reachable. They just don’t use the correct dns settings.

Steps to replicate it (hint: details matter!):

  1. Install nextcloud a.i.o. using the following compose:
services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    network_mode: bridge
    ports:
      - 8080:8080
    environment:
      APACHE_PORT: 11000
      APACHE_IP_BINDING: 0.0.0.0
      APACHE_ADDITIONAL_NETWORK: nginxproxymanager_default
      NEXTCLOUD_DATADIR: /zfs/nextcloud/data
      NEXTCLOUD_MEMORY_LIMIT: 1024M
      SKIP_DOMAIN_VALIDATION: false

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer 
  1. Did a migration from a different host with separate nextcloud containers to this installation using the official migration steps.
  2. Run into this issue might have run into it before the migration. Did not check…

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

ConnectException
cURL error 28: Connection timed out after 5002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://<nextcloud>/hosting/discovery
Failed to fetch discovery: cURL error 28: Connection timed out after 5002 milliseconds (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://<nextcloud>/hosting/discovery

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

ERR ts=1741340815.4047894 logger=http.log.error msg=dial tcp 172.23.0.11:7867: connect: connection refused request={"remote_ip":"172.23.0.5","remote_port":"35660","client_ip":"192.168.2.17","proto":"HTTP/1.1","method":"GET","host":"<nextcloud>","uri":"/push/ws","headers":{"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Gpc":["1"],"X-Real-Ip":["192.168.2.17"],"Sec-Websocket-Version":["13"],"X-Forwarded-For":["192.168.2.17"],"Pragma":["no-cache"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36"],"Origin":["https://<nextcloud>"],"Accept-Language":["en-US,en;q=0.9"],"Cookie":["REDACTED"],"Connection":["Upgrade"],"Sec-Websocket-Key":["5cExs/KmW7TOfJPt7RnI/Q=="],"X-Forwarded-Scheme":["https"],"Upgrade":["websocket"],"Cache-Control":["no-cache"],"Sec-Websocket-Extensions":["permessage-deflate; client_max_window_bits"],"X-Forwarded-Proto":["https"]}} duration=0.000535397 status=502 err_id=k4b76pmi6 err_trace=reverseproxy.statusError (reverseproxy.go:1373)

I would love it if you could help.
I’ve already gone trough the usually linked github issue containing stating how to check issues with collabora and talk. Though nothing in there helped me.

Hi, you need to configure dns in the daemon.json. See Configuring DNS | dockerlabs

Thank you for the reply.
I’ve added the dns info to the deamon json.
Also, in other containers it seems to work properly.
So it seems to be something that is only a problem with the a.i.o. containers.

I’ve also removed the nextcloud aio master container and the docker network used for nextcloud aio.
It does still not seem to work…
A test container reports the expected values:

Even worse:
This is the output of /etc/resolv.conf in the collabora container.
In the commented ExtServers the expected nameservers are listed.

I’ve done some more experimenting.
Including putting my adguard home on a macvlan.
That didn’t help.
I also remove the 1.1.1.1 nameserver.
Now this did something.
Namely that the containers could not resolve the domain anymore.

So it seems that the container does respect the settings, however, it seems to be unable to use another container for dns resolving…

I’ve created a workaround by adding my firewalls unbound as a nameserver to the daemon.json that offloads it’s resolving to my adguard home container.
So, this works, it however is less then ideal.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.