Nextcloud AIO deploy daemon config and talk recording only work with ip

[hlugt]

Hello, I am trying to switch to the AIO docker setup, but somehow the names of the docker proxy and the recording backend seem not to resolve correct.
I need to register a new AppAPI Deploy Daemon with the ip address instead of "nextcloud-aio-docker-socket-proxy", and also the Talk Recording Backend will only turn to ok when I put in the ip address instead of "nextcloud-aio-talk-recording"...
All other containers connect fine on their names.
The containers seem to work correct with the ip address, but is there not a small chance the internal address changes on a restart?
Is there something to be done, so the names can be used again?

[szaimen]

Hi, which docker version are you running? Can you post the output of sudo docker info here?

Also, can you check if the following makes it work?

1. Stop your containers from the AIO interface
2. Enable ipv6 in your docker daemon if not already done by following https://github.com/nextcloud/all-in-one/blob/main/docker-ipv6-support.md
3. After the docker daemon started correctly run sudo docker network disconnect nextcloud-aio nextcloud-aio-mastercontainer to disconnect the mastercontainer from the nextcloud-aio network.
4. now remove the nextcoud-aio network by running sudo docker network rm nextcloud-aio
5. Then run sudo docker network create --subnet="fd12:3456:789a:2::/64" --driver bridge --ipv6 nextcloud-aio in order to recreate the nextcloud-aio network
6. Finally run sudo docker network connect nextcloud-aio nextcloud-aio-mastercontainer to connect the mastercontainer to the network again.
7. At last, open the AIO interface and start your containers again

[hlugt]

Hi Simon,
Thanks for your reply. Ipv6 enabled and I followed the procedure on a fresh set. Unfortunately it makes no difference...

Docker info:

Client: Docker Engine - Community
Version: 26.1.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.14.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.27.0
Path: /usr/libexec/docker/cli-plugins/docker-compose

Server:
Containers: 16
Running: 14
Paused: 0
Stopped: 2
Images: 16
Server Version: 26.1.2
Storage Driver: overlay2
Backing Filesystem: zfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: e377cd56a71523140ca6ae87e30244719194a521
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.20-production+truenas
Operating System: Debian GNU/Linux 12 (bookworm)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.12GiB
Name: docker-nimbus
ID: a79a20b5-d5dd-450a-8928-2c3873efffcf
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

[hlugt]

Ok, I run AIO behind a Traefik Proxy, maybe that is of consequence. Also helps me solve the issue: I now have added the networkname to the hostname and now it resolves (ie nextcloud-aio-talk-recording.nextcloud-aio). Registered additional socket proxy, same thing with the hostname: added the network name to it.
That way changing ip-addresses will not cause issues.

[szaimen]

It is weird that the .nextcloud-aio ending is needed in your case as I cannot reproduce this on my test server (it works without this as well). However good that you found a solution!

[oturcot]

Hi,

I've been able to reproduce the reported issue.

I experienced the same problem as @hlugt. Like them, enabling IPv6 didn't resolve it. However, changing the container's name to the IP address or including the Docker network name (nextcloud-aio) temporarily fixes it.

I found that the issue was caused by a default search domain set in my Ubuntu 24.04 network configuration. After removing the default domain, communication via container names worked correctly. I removed the IPv6 fix after, and it continued to work without it.

I'm not sure whether a permanent fix should be implemented by you or the developer of AppAPI. However, one potential solution could be to always add the domain name, effectively overriding the server's search domain.

Best regards,
Olivier