Since upgrading to 7.2.2, every few days I cannot reach any of the IP's on my local Unraid server. I can ping it, but cannot reach the webui, any shares, or docker web's. I'm hard rebooting at that point.

Looking at the logs, the messages below repeat just prior to becoming unreachable.

Dec 14 10:38:04 ATLANTIS rsyslogd: omfwd/udp: socket 1: sendto() error: Network is unreachable [v8.2102.0 try https://www.rsyslog.com/e/2354 ]
Dec 14 10:38:04 ATLANTIS rsyslogd: omfwd: socket 1: error 101 sending via udp: Network is unreachable [v8.2102.0 try https://www.rsyslog.com/e/2354 

I also see errors like the following every once in a while that I did not see prior.

kernel: celery[92673]: segfault at 2f998 ip 000000000063d967 sp 0000148eb5b052f0 error 6 in python3.13[23d967,420000+2fa000] likely on CPU 7 (core 7, socket 0)

Any ideas? Possibly a bad NIC? Diagnostics attached. Appreciate any help I can get. Thanks!

atlantis-diagnostics-20251216-1148.zip

28 minutes ago, joshallen said:

Looking at the logs, the messages below repeat just prior to becoming unreachable.

Dec 14 10:38:04

This is the start of the syslog, maybe the server rebooted on its own?

I don't believe so. That was just a cut and paste from the syslog of an error I thought pertinent

That's when the server last booted, check the server uptime to see if it's what you expect.

32 minutes ago, JorgeB said:

That's when the server last booted, check the server uptime to see if it's what you expect.

Uptime shows 2 days, 3 hours, 14 minutes

you can safely ignore the rsyslogd errors. They are confusing but normal.

They occur during boot phase if you have defined a remote host to store syslog on, but the network ist not yet up and running.

The messages cannot be transmitted, so it writes down this errors.

(rsyslog should be much brighter and know this and avoid the error messages)

14 minutes ago, MAM59 said:

you can safely ignore the rsyslogd errors. They are confusing but normal.

They occur during boot phase if you have defined a remote host to store syslog on, but the network ist not yet up and running.

The messages cannot be transmitted, so it writes down this errors.

(rsyslog should be much brighter and know this and avoid the error messages)

That makes sense for those errors. Syslog is indeed writing to a share.

Anything elsewhere that would explain the server going unreachable after a few days of running?

If I have to guess, I would say, you have a serious problem with your DHCP server

Dec 14 10:38:30 ATLANTIS dhcpcd-run-hooks: interface=br0, reason=IPV4LL, protocol=ipv4ll

Dec 14 10:38:30 ATLANTIS update_services: remove queued job 3

Dec 14 10:38:30 ATLANTIS update_services: queue new job 4, wait for 20s

Dec 14 10:38:30 ATLANTIS plugin-manager: executing inline script: /bin/bash '/tmp/inline6-dynamix.unraid.net.sh'

Dec 14 10:38:30 ATLANTIS plugin-manager: executing inline script: /bin/bash '/tmp/inline8-dynamix.unraid.net.sh'

Dec 14 10:38:31 ATLANTIS nmbd[2288]: [2025/12/14 10:38:31.345951, 0] ../../source3/libsmb/nmblib.c:929(send_udp)

Dec 14 10:38:31 ATLANTIS nmbd[2288]: Packet send failed to 169.254.255.255(137) ERRNO=Network is unreachable

Dec 14 10:38:31 ATLANTIS nmbd[2288]: [2025/12/14 10:38:31.346004, 0] ../../source3/nmbd/nmbd_packets.c:1639(retransmit_or_expire_response_records)

Dec 14 10:38:31 ATLANTIS nmbd[2288]: retransmit_or_expire_response_records: Failed to resend packet id 11467 to IP 169.XXX.XXX.255 on subnet 169.254.111.85

Dec 14 10:38:31 ATLANTIS nmbd[2288]: [2025/12/14 10:38:31.346029, 0] ../../source3/libsmb/nmblib.c:929(send_udp)

Dec 14 10:38:31 ATLANTIS nmbd[2288]: Packet send failed to 169.254.255.255(137) ERRNO=Network is unreachable

UNRAID does not get an address and other config, so it is on its own and reverts to the 169.254.x range (which means: I HAVE NO NET AT ALL!).

If this happens only SOMETIMES, it also could be the reason for your losses later on.

Maybe on 1st boot UNRAID is able to fetch the data from the DHCP server and runs fine for a while. Then, the lease runs out hours or days (depending on the DHCP server's settings) and needs to be renewed.

If the DHCP server is not reachable then, there will be an additional grace period in which UNRAID keeps on using the not-so-valid address.

But after this (and still no answer from the server), the address and config will be deleted and switched back to 169.254.X.

All these timeouts depend on the server's config, so I cannot guess how long it will take until you lose connection.

so, what you have to do is to check the DHCP server and see why it does not answer.

13 hours ago, joshallen said:

Uptime shows 2 days, 3 hours, 14 minutes

You're still missing my point, you posted a time code from when the server was booting, saying that was when you lost contact with it. That would only make sense if the server was rebooting at that time, by your hand or on its own, but let's forget that, those DHCP issues could be the problem.

17 hours ago, JorgeB said:

You're still missing my point, you posted a time code from when the server was booting, saying that was when you lost contact with it. That would only make sense if the server was rebooting at that time, by your hand or on its own, but let's forget that, those DHCP issues could be the problem.

I looked into the DHCP server, which is a Unifi UDM Pro SE. It has a fixed IP address set and nothing in the logs with an issue with the Unraid client device. No other devices on the network are exhibiting similar behavior.

I did notice the following errors in the Unraid logs (server is still reachable at this time):

Dec 17 13:45:41 ATLANTIS kernel: pcieport 0000:00:1c.0: AER: Correctable error message received from 0000:04:00.0
Dec 17 13:45:41 ATLANTIS kernel: atlantic 0000:04:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)
Dec 17 13:45:41 ATLANTIS kernel: atlantic 0000:04:00.0:   device [1d6a:07b1] error status/mask=00000001/0000a000

That PCI device is my 10G NIC. These errors are also periodic (daily, roughly). Is my NIC the issue here? I do not have the built in 1G port is not disabled at the BIOS.

Appreciate the help narrowing this down.

3 hours ago, joshallen said:

Is my NIC the issue here?

I remember an event where cheap cables+cheap atlantic let to line errors and line resets. you would then note some dropping connections, usually client transfers are interrupted and the clients complain.

But protocols like SMB do an automatic reconnect, so there is just a short delay and then transfers continue.

Anyway in this situation it also happens that link loss also ends up into a full jam of the card. If flow control has stopped transfer and the line crashes then, the partner does not always get informed and the "resume transfer" packet is lost. The other box then is sitting around waiting until the cows come home.

To see if this happens to you too do:

• wait until UNRAID is not reachable anymore

• Pull out the LAN Plug on UNRAID (or the switch side does not matter)

• Wait 5s

• Put in the LAN Cable again

If you then can reach UNRAID again, you are a victim of the described problem. Either fix cables with correct ones, (and make sure the cable length is <30m!) or get a better card (and go for real fiber, these things happen only with twisted pair cables)

Note: the cable stuff is tricky with 10G!!! There are still many many wrong cables on the market. For long times there was cable types CAT 6,7&8 available, but the plugs not. These cables were sold as "raw cable" (it is usually printed on them!), they DO NOT WORK! Read carefully!!!

Note: the cable problem might also be on "the other side" of the connection. So take a look at the clients too!

Edited December 18, 2025Dec 18 by MAM59

5 hours ago, joshallen said:

These errors are also periodic (daily, roughly). Is my NIC the issue here?

You can try this; it may help with those errors:

https://forums.unraid.net/topic/118286-nvme-drives-throwing-errors-filling-logs-instantly-how-to-resolve/?do=findComment&comment=1165009