Hey there, some hours after Unraid 7.2.1 came out, I already updated. That's probably where the problems started. First, I thought it was about Traefik, but then I realised I get tons of problems that even healthchecks are failing sometimes, and a Docker container cannot reach the localhost. I guess it would be an option to completely remove the Docker folder and let everything reinstall, but it takes a lot of time to select all the apps again... is there a faster way?

There are many networking problems. I run a WordPress instance, and I have many 500 errors. First, it said there is no contact to the DB, then to Redis. But it is not all the time. Sometimes it loads, and sometimes it does not. I had to disable Redis in WordPress because it could never connect, but the container runs and none of the configuration changed. The same Redis container works for other containers that need Redis.

You can see these random errors and restarts here. Out of nowhere, there is no connection, and it is in the container also some n8n flows failed or had a timeout. There is a general issue in my system that has nothing to do with exposed services. So it cannot be Traefik or Cloudflare.

The system itself runs smoothly without any problems. That is confusing me. I have another friend with a very fresh install of Unraid that also upgraded to 7.2.1, and he has no problems. I also found no entries about similar behaviour in the forum.

Let me know if there is any quick way to reinstall Docker with all apps without having to select everyone myself... (164 containers)

And thanks for any help!

unraid-server-diagnostics-20251121-2204.zip

Edited November 21, 2025Nov 21 by sasbro97
typo

Downgrade to the previous version if this is a production server to see if your containers can boot.

10 hours ago, sasbro97 said:

Hey there, some hours after Unraid 7.2.1 came out, I already updated.

Was this from 7.2.0 or an earlier release?

It was from 7.2.0. @JorgeB

20 hours ago, sasbro97 said:

select everyone myself... (164 containers)

In CA, previous docker, about 10ish docker will list per page, if you tick select all, then current page docker will pull again.

I know @Vr2Io but still I had to select them all manually because there are some old apps in between.

But for the record, it seems that the problem has been solved now. Needed massive time for all the container reinstalls and selecting auto restart for most of them was buggy as hell (as always...)

Not sure why the minor update caused this.

4 hours ago, sasbro97 said:

I know @Vr2Io but still I had to select them all manually because there are some old apps in between.

But for the record, it seems that the problem has been solved now. Needed massive time for all the container reinstalls and selecting auto restart for most of them was buggy as hell (as always...)

Not sure why the minor update caused this.

I am a light user, only have ~12 docker. I store docker in \tmp, so no such pain to pull all if reboot. So far no problem in every update.😁

17 hours ago, sasbro97 said:

It was from 7.2.0.

Nothing changed in 7.2.1 vs 7.2.0 that would affect Docker, I see that you are using a Docker folder; in my experience, those are prone to strange issues, I would recommend recreating it as a Docker image:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file

Then:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications

Also see below if you have any custom docker networks:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

I cannot believe this. It started again yesterday. Now it's only one container behaving like this. It started like this when I had this issue as well. After rebooting Unraid, it seems to work flawlessly for at least an hour, but in general, something is wrong because I can see that calls to the service need between 2000 and 30000ms, and sometimes even timeout.

In the container logs, I see:

[Mon Nov 24 19:11:25.604359 2025] [php:notice] [pid 87:tid 87] [client 172.19.0.29:56560] [stats.xyz.de] Error in Matomo: Could not connect to the database:  SQLSTATE[HY000] [2002] No route to host  This may be a temporary issue, try refreshing the page. Please contact your Matomo administrator if the problem persists.
172.19.0.29 - - [24/Nov/2025:19:11:20 +0100] "GET / HTTP/1.1" 500 2278 "-" "Uptime-Kuma/2.0.2"
172.19.0.29 - - [24/Nov/2025:19:11:52 +0100] "GET /matomo.php HTTP/1.1" 200 502 "-" "Uptime-Kuma/1.23.17"
127.0.0.1 - - [24/Nov/2025:19:11:53 +0100] "GET /matomo.php HTTP/1.1" 200 609 "-" "curl/8.14.1"
[Mon Nov 24 19:12:23.334519 2025] [php:notice] [pid 53:tid 53] [client 172.19.0.29:35966] [stats.xyz.de] Error in Matomo: Could not connect to the database:  SQLSTATE[HY000] [2002] No route to host  This may be a temporary issue, try refreshing the page. Please contact your Matomo administrator if the problem persists.
172.19.0.29 - - [24/Nov/2025:19:12:20 +0100] "GET / HTTP/1.1" 500 2278 "-" "Uptime-Kuma/2.0.2"
172.19.0.29 - - [24/Nov/2025:19:12:27 +0100] "GET /piwik.js HTTP/1.1" 200 22396 "https://xyz.de/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"
172.19.0.29 - - [24/Nov/2025:19:12:52 +0100] "GET /matomo.php HTTP/1.1" 200 502 "-" "Uptime-Kuma/1.23.17"
127.0.0.1 - - [24/Nov/2025:19:12:53 +0100] "GET /matomo.php HTTP/1.1" 200 609 "-" "curl/8.14.1"
[Mon Nov 24 19:13:23.302342 2025] [php:notice] [pid 87:tid 87] [client 172.19.0.29:55620] [stats.xyz.de] Error in Matomo: Could not connect to the database:  SQLSTATE[HY000] [2002] No route to host  This may be a temporary issue, try refreshing the page. Please contact your Matomo administrator if the problem persists.
172.19.0.29 - - [24/Nov/2025:19:13:20 +0100] "GET / HTTP/1.1" 500 2278 "-" "Uptime-Kuma/2.0.2"
172.19.0.29 - - [24/Nov/2025:19:13:38 +0100] "GET /piwik.js HTTP/1.1" 200 22396 "https://xyz.de/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"
172.19.0.29 - - [24/Nov/2025:19:13:52 +0100] "GET /matomo.php HTTP/1.1" 200 502 "-" "Uptime-Kuma/1.23.17"
127.0.0.1 - - [24/Nov/2025:19:13:53 +0100] "GET /matomo.php HTTP/1.1" 200 609 "-" "curl/8.14.1"

Before, you only saw 200er status codes. How is it possible that it starts the connection to the database container? The database container is running, and I can see no issue. This issue is driving me insane. It must have something to do with Docker networking. The more time the server is running, the more containers will become slowly when calling them.

How can I debug this or find out what is going on? Syslogs do not really show any reason. Nothing is logged.

Still, these logs are concerning me:

Nov 24 17:41:30 UNRAID-Server sshd[2156]: Received signal 15; terminating.
Nov 24 17:41:30 UNRAID-Server sshd[39256]: Server listening on fd7a:115c:a1e0::3801:2f78 port 1997.
Nov 24 17:41:30 UNRAID-Server sshd[39256]: Server listening on 100.76.47.120 port 1997.
Nov 24 17:41:30 UNRAID-Server sshd[39256]: Server listening on fd31:e9c1:819e::53 port 1997.
Nov 24 17:41:30 UNRAID-Server sshd[39256]: Server listening on 192.168.178.29 port 1997.
Nov 24 17:41:32 UNRAID-Server avahi-daemon[39819]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Nov 24 17:41:32 UNRAID-Server avahi-daemon[39819]: *** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***

Edited November 24, 2025Nov 24 by sasbro97

Post new diags please

@JorgeB added.

Question: Would it be possible that a Docker Socket Proxy running as a Docker container is somehow the problem? I mean, it started after an update and worked before, but (for now) I changed Traefik back to use /var/run/docker.sock, and I don't see outages. It's still slow as hell, but no 500 error. But how could this affect Matomo's ability to connect to its database container?

unraid-server-diagnostics-20251124-1940.zip

Okay I'm done. Everything went down again Now I got serious problems with this mDNS warning as it seems:

Nov 24 20:23:27 UNRAID-Server kernel: e1000e 0000:00:1f.6 eth0: NIC Link is Down
Nov 24 20:23:27 UNRAID-Server kernel: bond0: (slave eth0): link status definitely down, disabling slave
Nov 24 20:23:27 UNRAID-Server kernel: e1000e 0000:00:1f.6 eth0: left promiscuous mode
Nov 24 20:23:27 UNRAID-Server kernel: e1000e 0000:00:1f.6 eth0: left allmulticast mode
Nov 24 20:23:27 UNRAID-Server kernel: bond0: now running without any active interface!
Nov 24 20:23:27 UNRAID-Server kernel: br0: port 1(bond0) entered disabled state
Nov 24 20:23:28 UNRAID-Server dhcpcd[1953]: br0: carrier lost
Nov 24 20:23:28 UNRAID-Server avahi-daemon[39819]: Withdrawing address record for 192.168.178.29 on br0.
Nov 24 20:23:28 UNRAID-Server avahi-daemon[39819]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.178.29.
Nov 24 20:23:28 UNRAID-Server dhcpcd[1953]: br0: deleting route to 192.168.178.0/24
Nov 24 20:23:28 UNRAID-Server avahi-daemon[39819]: Interface br0.IPv4 no longer relevant for mDNS.
Nov 24 20:23:28 UNRAID-Server dhcpcd[1953]: br0: deleting default route via 192.168.178.1
Nov 24 20:23:28 UNRAID-Server dhcpcd-run-hooks: interface=br0, reason=EXPIRE, protocol=dhcp
Nov 24 20:23:28 UNRAID-Server update_services: no queued job present
Nov 24 20:23:28 UNRAID-Server update_services: queue new job 20, wait for 20s
Nov 24 20:23:30 UNRAID-Server kernel: e1000e 0000:00:1f.6 eth0: Failed to enable ULP
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: Deleting 1 br0, [192.168.178.29]:123, stats: received=220, sent=220, dropped=0, active_time=9919 secs
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: 216.239.35.12 local addr 192.168.178.29 -> <null>
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: 216.239.35.8 local addr 192.168.178.29 -> <null>
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: 216.239.35.4 local addr 192.168.178.29 -> <null>
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: 216.239.35.0 local addr 192.168.178.29 -> <null>
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: Deleting 3 br0, [fd31:e9c1:819e::53]:123, stats: received=0, sent=0, dropped=0, active_time=9919 secs
Nov 24 20:23:31 UNRAID-Server ntpd[2204]: Deleting 4 br0, [fe80::ca7f:54ff:fe50:de29%5]:123, stats: received=0, sent=0, dropped=0, active_time=9919 secs
Nov 24 20:23:48 UNRAID-Server reload_services: execute queued job 20

This killed my access to the server even though it is running. AdGuardHome uses br0 and runs as a DNS server, so it breaks everything.

The whole logs are attached. Another horrible bug now is that I have clearly set auto-start for the invoiceninja-web container to false. Somehow, Unraid starts it at every reboot. I looked into cat /var/lib/docker/unraid-autostart and there isn't this container in the UI as well. Where does Unraid take this advice from to start it? I know the autostart has always been buggy, but that is so annoying...

I can see from the logs that yesterday the warning started:

Nov 23 19:49:37 UNRAID-Server avahi-daemon[58558]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Nov 23 19:49:37 UNRAID-Server avahi-daemon[58558]: *** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***

syslog-192.168.178.29.log

Edited November 24, 2025Nov 24 by sasbro97

I'm not seeing any Docker service related issues, as for the other issues you mention, advanced networking is not really my area; I recommend starting by simplifying it as much as possible and retesting.