Hi There,

I am in need of help because I am not getting anywhere. Currently I can access my server via its IP only via tailscale, which is not ideal.

I have a the System data and Appdata in a cache drive. In order to backup the data, I use the Appdata Backup plugin, which is configured to update the dockers afterwards. I notice that the network settings for my docker was a bit mess up, I think it has to do with some of the docker updates, but I am not 100% sure.

In order to troubleshoot, I stopped docker, restarted the server, the router, tried to flush ARP tables and did other things that found in the forum, in reddit, etc, but nothing did work. My knowledge here is limited, but I have the feeling that I have conflicting IPs from the docker and the server.

Another thing that I notice is that my pi-hole (outside unraid) became as well unreachable.

The Fix Common problems did not get me anywhere, it is suggesting to update tailscale but I dont want to do it until i fix the bigger issue.

As well, a month ago or so, I installed a second Ethernet card, because it could connect to my router at 2.5Gbps instead of the 1Gbps that the integrated Ethernet card offered. I have tried to connect to that one instead, but it neither worked.

I am attaching the diagnostics with the hope that someone can help me with this.

If I turn on docker, I can access to the different apps via the ip:port but again, only via tailscale. It seems that the torrents client, for instance, can even generate traffic.

I have tried to change some network settings, but the VM manager does not allow me to deactivate it (via GUI, i guess there is a way via terminal). Maybe if i need to change something there, someone could guide me how to force it (I dont have VMs anyways)

Thank you in advance or any insights you might have

unraid-diagnostics-20260915-2233.zip

Docker is currently disabled in your configuration, and no container networking modules are loaded, so a container IP conflict can't be causing this. You can set that theory aside.

The real problem is in the log from before your last reboot. Your server has two network ports: the onboard 1Gb port (eth0), which has no cable connected, and the new 2.5Gb card (eth1), which is carrying everything. In about 65 minutes, eth1 lost and regained its link 7 times, and your DHCP lease expired twice. Each time that happened, the server dropped its LAN address, deleted its default route, and fell back to a 169.254.x.x link-local address.

That is exactly why the IP stops working. Tailscale keeps working because it has its own address that doesn't depend on your DHCP lease, and it reconnects as soon as the link comes back.

Your newest diagnostic looks healthy because it was taken 12 minutes after a reboot. The fault is intermittent, but it will likley come back.

There are no driver errors, resets, or timeouts, and power management (ASPM) is already off. That points at the physical connection. I'd work through these one at a time:

1. Move the cable to the onboard 1Gb port and run on that for a day. If the drops stop, the 2.5G card, its cable, or its switch port is the culprit.

2. Replace the cable to the 2.5G card with a known-good Cat6.

3. Try a different port on the router/switch.

4. Temporarily force the card to 1Gb. 2.5G is much less tolerant of marginal cabling.

5. Re-seat the card in its slot.

Two other things worth doing:

- Enable SSH (Settings → Management Access). Right now it's off, so you have no backup way in when the LAN address disappears.

- Set a DHCP reservation or static IP. This won't stop the link dropping, but it stops the server losing its address entirely and shortens each outage.

Also worth noting: your bond lists eth0 eth1 eth2 eth3, but only two ports exist and only one has a cable. That's harmless, but it means the bond gives you no redundancy at all.

Connecting both ports to the switch would let it actually fail over.

One question I can't answer from your diagnostics: you mentioned your pi-hole also became unreachable. Your server's logs can only see its own port, not another device. Could you check:

- When the server's IP is unreachable, can a different device on your LAN reach it, or is it only your computer that can't?

- Are the server and the pi-hole plugged into the same switch? If they both drop at the same moment, the switch or its uplink is a better suspect than the server.

(The Fix Common Problems warning about updating Tailscale is unrelated, safe to ignore for now.)

29 minutes ago, JorgeB said:

1. Move the cable to the onboard 1Gb port and run on that for a day. If the drops stop, the 2.5G card, its cable, or its switch port is the culprit.

2. Replace the cable to the 2.5G card with a known-good Cat6.

3. Try a different port on the router/switch.

4. Temporarily force the card to 1Gb. 2.5G is much less tolerant of marginal cabling.

5. Re-seat the card in its slot.

Two other things worth doing:

- Enable SSH (Settings → Management Access). Right now it's off, so you have no backup way in when the LAN address disappears.

- Set a DHCP reservation or static IP. This won't stop the link dropping, but it stops the server losing its address entirely and shortens each outage.

Also worth noting: your bond lists eth0 eth1 eth2 eth3, but only two ports exist and only one has a cable. That's harmless, but it means the bond gives you no redundancy at all.

Connecting both ports to the switch would let it actually fail over.

One question I can't answer from your diagnostics: you mentioned your pi-hole also became unreachable. Your server's logs can only see its own port, not another device. Could you check:

- When the server's IP is unreachable, can a different device on your LAN reach it, or is it only your computer that can't?

- Are the server and the pi-hole plugged into the same switch? If they both drop at the same moment, the switch or its uplink is a better suspect than the server.

(The Fix Common Problems warning about updating Tailscale is unrelated, safe to ignore for now.)

Thank you so much for looking in to this and giving me some insights.

I moved the cable to the 1Gbps port and it did nothing different, but I will tried a new cable in a new port just to discard the isssue there.

How do I force the card to go 1Gb?

I have done some changes to simplify how I have the network set-up, so I am attaching new diagnostics. Good point regarding SSH, I have activated it. The IP i had it reserved via router, with the MAC address of the old port, recently changed to the new card.

Regarding reaching the IP of my server, I have tried with different clients and different OS without difference. I have ping the IP from the router directly, through the very simple diagnostics tools there, and then, it responds, both the server and the pihole. Thing is, besides opening ports in my router for the qbittorrent client, i didnt change anything or got a software update, but I think you have a good point, the issue might be there, as we have discarded the docker as the current issue, that the pi-hole has a similar issue invite to think that there might be the issue.

My network setting is a following

Internet modem from the ISP, then to it (ips 192.168.1.x)

• connected to WAN Port 10Gbps, with DMZ to the ISP to manage ports, Asus router, with unraid and pihole, and the whole WiFi with a another ASUS in Mesh mode. (ips 192.168.50.x) being unraid on 100 and the pihole on 175

• connected to a WAN port 1Gbps another router with IoT things and other stuff I wan to keep separated from my core network (ips 192.168.1.x)

unraid-diagnostics-20260916-0938.zip

ok, so for anyone having a similar issue, I had to hard-reset my router set-up, and then it started all working as expected.

Very weird, I have no idea what actually happened there, but it was not an issue with Unraid settings, even though the troubleshooting made me read documentation and rethink it.

1 hour ago, [email protected] said:

ok, so for anyone having a similar issue, I had to hard-reset my router set-up, and then it started all working as expected.

Very weird, I have no idea what actually happened there, but it was not an issue with Unraid settings, even though the troubleshooting made me read documentation and rethink it.

Years ago when the networking setup in Unraid was much simpler, when problems with symptoms like this appeared, rebooting the entire network-- router, switches, clients, and server --was a early part of the troubleshooting procedure. Each one of these devices contains a computer chip with memory running an OS (Usually Linux for the peripherals) and they can encounter anomalies that affect their performance. Today, it seems like this has become less of an issue (Or more people do the reboot before posting...) but it is still one thing to be tried before taking more drastic steps.

3 hours ago, Frank1940 said:

Years ago when the networking setup in Unraid was much simpler, when problems with symptoms like this appeared, rebooting the entire network-- router, switches, clients, and server --was a early part of the troubleshooting procedure. Each one of these devices contains a computer chip with memory running an OS (Usually Linux for the peripherals) and they can encounter anomalies that affect their performance. Today, it seems like this has become less of an issue (Or more people do the reboot before posting...) but it is still one thing to be tried before taking more drastic steps.

Rebooting did not solve the problem, obviusly that was one of the first steps to do, for all the devices involved. It was a factory reset. Anyways, from one side, more tools to diagnose problems and perform automatic setups do help, however the complexity of the net and subnets and the applications running on all those layers make it hard to find out where the problem is.