Unraid 7.1.4 - network interface keeps going down at 5am - More updates (11 July) and info and diagnostic zip attached - Help requested - General Support

July 1, 20251 yr

Unraid server keeps having issues with a network port.

I have two network interfaces ... eth0 is on the internal network (192.168.x.x), and eth1 is in the DMZ (between two routers, one to t WAN, and the other to the LAN (10.x.x.x). I host most of my docker containers on a specific interface, with fixed IP Addresses. I run no VMs.

On a regular (almost daily) basis, the eth1 goes down and cannot be restored - this is a new issue, as on 7.1.2 the interfaces were very reliable. I have changed internet provider,recently, but cannot see how this could cause the issue.

Occasionally the eth0 goes down as well, generally when there are issues on the network such as the router being shut down.

I try and click the "Port Up" Button in the network settings, but nothing seems to happen. In the below log, the interface appears to go down, be resored then a few seconds later, go down permanently.

Jul 1 12:55:48 raider webgui: Successful login user root from 192.168.1.150

Jul 1 13:01:25 raider monitor_nchan: Stop running nchan processes

Jul 2 04:40:01 raider root: Fix Common Problems Version 2025.05.29

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Cloudreve has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application MeTube has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Nginx-Proxy-Manager-Official has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application open-webui has an update available for it

Jul 2 04:40:10 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it

Jul 2 04:42:03 raider root: Fix Common Problems: Warning: The plugin folder.view.plg is not known to Community Applications and is possibly incompatible with your server

Jul 2 05:01:42 raider kernel: r8169 0000:02:00.0 eth1: Link is Down

Jul 2 05:01:42 raider kernel: br1: port 1(eth1) entered disabled state

Jul 2 05:01:45 raider ntpd[1875]: Deleting 2 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=209042 secs

Jul 2 05:01:48 raider kernel: r8169 0000:02:00.0 eth1: Link is Up - 1Gbps/Full - flow control off

Jul 2 05:01:48 raider kernel: br1: port 1(eth1) entered blocking state

Jul 2 05:01:48 raider kernel: br1: port 1(eth1) entered forwarding state

Jul 2 05:01:51 raider ntpd[1875]: Listen normally on 3 br1 10.1.2.1:123

Jul 2 05:01:51 raider ntpd[1875]: new interface(s) found: waking up resolver

Jul 2 05:01:58 raider kernel: r8169 0000:02:00.0 eth1: Link is Down

Jul 2 05:01:58 raider kernel: br1: port 1(eth1) entered disabled state

Jul 2 05:02:01 raider ntpd[1875]: Deleting 3 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=10 secs

Jul 2 07:03:28 raider webgui: Successful login user root from 192.168.1.150

What can I do to restore the network interface without rebooting
What can I do to prevent the network port from going down in the first case ?

Edited July 11, 2025Jul 11 by kentb

Quote

July 1, 20251 yr

Community Expert

??? are you using a usb ethernet device?

Jul 2 05:01:58 raider kernel: br1: port 1(eth1) entered disabled state

Jul 2 05:02:01 raider ntpd[1875]: Deleting 3 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=10 secs

I Don't understand how you have a pulg in play added Nic and then have a line to remove the bridge. Unless you are plugin in or removing a netowrk...

there are some commands yes I can only asume theses are captures of a docker compose or other docker setup. as

Jul 2 05:01:48 raider kernel: br1: port 1(eth1) entered blocking state

Jul 2 05:01:48 raider kernel: br1: port 1(eth1) entered forwarding state

Tells me that a docker atempted to make a bride adn use br1 interface...

ip link ifconfig up

ifconfig down ip a
many linux netowrk comands exist. but I woudl need a diag file. what your running and how you get into this state and what your overall goal is...

Also how many nics and your network setup and layout.

? modem > router > ?unraid?
unriad what eth interface and connection settings.

as your doing something that introduces a new interface to the sytem and removing th interface casuing this... terminal acces may be required depending on how your network is setup...

Edited July 1, 20251 yr by bmartino1

Quote

July 2, 20251 yr

Author

No, I have two onboard network ports.

192.168 --- Router --- 10.x --- Router ----- WAN

.....LAN | ........ | DMZ Internet

.........| ........ |

....eth0 +--Unraid--+ eth1

............Server

Docker containers are bridged to the DMZ (eth1, br1) or internal (eth0, br0)

(Edited to replace space with . as spaces are truncated - even in code blocks)

Edited July 2, 20251 yr by kentb

Quote

July 2, 20251 yr

Author

I rebooted. Fixed.

Port 123 is NTP - 10.1.2.1 is my Unraid box fixed IP on the DMZ.

Here's the results of the ip link command:

# ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000

link/ipip 0.0.0.0 brd 0.0.0.0

5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br0 state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br1 state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

9: br-2437bb60b432: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:b4:41:d3:5e brd ff:ff:ff:ff:ff:ff

10: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:75:55:bd:2f brd ff:ff:ff:ff:ff:ff

11: br-8f4313a3e239: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:6d:a3:fa:6a brd ff:ff:ff:ff:ff:ff

12: br-ae25bf0cd9b4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:

Quote

July 5, 20251 yr

Community Expert

ok so you may need a nic plugin driver...

Not sure how your getting into a state where the eth0 / br0 are up but your docker interfaces are down:

br-2437bb60b432: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:b4:41:d3:5e brd ff:ff:ff:ff:ff:ff

10: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:75:55:bd:2f brd ff:ff:ff:ff:ff:ff

11: br-8f4313a3e239: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:6d:a3:fa:6a brd ff:ff:ff:ff:ff:ff

12: br-ae25bf0cd9b4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

.,..

this tells me you hvae a broken docker network setup... Please post a diagnostic file. not enouth info to assist.

Quote

July 10, 2025Jul 10

Author

It happened again - same time, different day

OK ... it happened again 9 days later from above (twice now in 9 days, but only one I captured the log files for), at the exact same time ... so likely a cron or other job. I will paste the logs (showing a few days), and also what is in the cron (nothing at 5:00am).

DIAGNOSTICS ATTACHED

LOG

Jul 8 23:04:42 raider root: Fix Common Problems Version 2025.05.29

Jul 8 23:04:48 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it

Jul 8 23:04:48 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it

Jul 8 23:04:48 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it

Jul 8 23:04:48 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it

Jul 8 23:04:48 raider root: Fix Common Problems: Warning: Docker Application StirlingPDF has an update available for it

Jul 8 23:09:46 raider kernel: veth13131ac: renamed from eth0

Jul 8 23:09:46 raider kernel: eth0: renamed from veth843a2b1

Jul 8 23:11:30 raider kernel: vethe90d695: renamed from eth0

Jul 8 23:11:36 raider kernel: eth0: renamed from veth5b1ebd4

Jul 8 23:17:58 raider kernel: eth0: renamed from vetha49c6b5

Jul 8 23:18:50 raider kernel: veth999b4c6: renamed from eth0

Jul 8 23:47:18 raider kernel: eth0: renamed from veth3248418

Jul 9 00:08:17 raider kernel: veth3248418: renamed from eth0

Jul 9 00:23:20 raider kernel: eth0: renamed from veth2671799

Jul 9 00:23:51 raider kernel: veth2671799: renamed from eth0

Jul 9 00:33:47 raider kernel: eth0: renamed from vethcdf8729

Jul 9 00:34:17 raider kernel: vethcdf8729: renamed from eth0

Jul 9 00:41:05 raider kernel: docker0: port 1(veth29c3b66) entered blocking state

Jul 9 00:41:05 raider kernel: docker0: port 1(veth29c3b66) entered disabled state

Jul 9 00:41:05 raider kernel: veth29c3b66: entered allmulticast mode

Jul 9 00:41:05 raider kernel: veth29c3b66: entered promiscuous mode

Jul 9 00:41:05 raider kernel: eth0: renamed from veth11ee237

Jul 9 00:41:05 raider kernel: docker0: port 1(veth29c3b66) entered blocking state

Jul 9 00:41:05 raider kernel: docker0: port 1(veth29c3b66) entered forwarding state

Jul 9 01:03:01 raider monitor_nchan: Stop running nchan processes

Jul 9 04:40:01 raider root: Fix Common Problems Version 2025.05.29

Jul 9 04:40:09 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it

Jul 9 04:40:09 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it

Jul 9 04:40:09 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it

Jul 10 02:13:42 raider monitor_nchan: Stop running nchan processes

Jul 10 04:40:01 raider root: Fix Common Problems Version 2025.05.29

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Nginx-Proxy-Manager-Official has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application ollama has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it

Jul 10 04:40:10 raider root: Fix Common Problems: Warning: Docker Application StirlingPDF has an update available for it

Jul 10 09:39:59 raider webgui: Successful login user root from 192.168.1.150

Jul 10 18:23:15 raider monitor_nchan: Stop running nchan processes

Jul 10 20:08:31 raider monitor_nchan: Stop running nchan processes

Jul 11 04:40:01 raider root: Fix Common Problems Version 2025.05.29

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application Nginx-Proxy-Manager-Official has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application ollama has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it

Jul 11 04:40:09 raider root: Fix Common Problems: Warning: Docker Application StirlingPDF has an update available for it

Jul 11 05:01:03 raider kernel: r8169 0000:02:00.0 eth1: Link is Down

Jul 11 05:01:03 raider kernel: br1: port 1(eth1) entered disabled state

Jul 11 05:01:06 raider ntpd[1876]: Deleting 2 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=199242 secs

Jul 11 05:01:09 raider kernel: r8169 0000:02:00.0 eth1: Link is Up - 1Gbps/Full - flow control off

Jul 11 05:01:09 raider kernel: br1: port 1(eth1) entered blocking state

Jul 11 05:01:09 raider kernel: br1: port 1(eth1) entered forwarding state

Jul 11 05:01:11 raider ntpd[1876]: Listen normally on 3 br1 10.1.2.1:123

Jul 11 05:01:11 raider ntpd[1876]: new interface(s) found: waking up resolver

Jul 11 05:01:18 raider kernel: r8169 0000:02:00.0 eth1: Link is Down

Jul 11 05:01:18 raider kernel: br1: port 1(eth1) entered disabled state

Jul 11 05:01:21 raider ntpd[1876]: Deleting 3 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=10 secs

CRON

# If you don't want the output of a cron job mailed to you, you have to direct

# any output to /dev/null. We'll do this here since these jobs should run

# properly on a newly installed system. If a script fails, run-parts will

# mail a notice to root.

#

# Run the hourly, daily, weekly, and monthly cron jobs.

# Jobs that need different timing may be entered into the crontab as before,

# but most really don't need greater granularity than this. If the exact

# times of the hourly, daily, weekly, and monthly cron jobs do not suit your

# needs, feel free to adjust them.

#

# Run hourly cron jobs at 47 minutes after the hour:

47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null

#

# Run daily cron jobs at 4:40 every day:

40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null

#

# Run weekly cron jobs at 4:30 on the first day of the week:

30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

#

# Run monthly cron jobs at 4:20 on the first day of the month:

20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

NETWORK - ip link

root@raider:~# ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000

link/ipip 0.0.0.0 brd 0.0.0.0

5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br0 state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

6: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq master br1 state DOWN mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

8: br1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

9: br-2437bb60b432: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:29:16:e3:01 brd ff:ff:ff:ff:ff:ff

10: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default

link/ether 02:42:9e:a0:cc:12 brd ff:ff:ff:ff:ff:ff

11: br-8f4313a3e239: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:9f:c9:8d:06 brd ff:ff:ff:ff:ff:ff

12: br-ae25bf0cd9b4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default

link/ether 02:42:0a:c5:c3:53 brd ff:ff:ff:ff:ff:ff

35: veth29c3b66@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default

link/ether 9a:87:cc:0d:60:5a brd ff:ff:ff:ff:ff:ff link-netnsid 2

Other commands

root@raider:~# ifconfig up

up: error fetching interface information: Device not found

root@raider:~# ifconfig down

down: error fetching interface information: Device not found

root@raider:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

link/ipip 0.0.0.0 brd 0.0.0.0

5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br0 state UP group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

6: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq master br1 state DOWN group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff

inet 192.168.2.1/16 metric 1 scope global br0

valid_lft forever preferred_lft forever

8: br1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000

link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff

inet 10.1.2.1/8 metric 1 scope global br1

valid_lft forever preferred_lft forever

9: br-2437bb60b432: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

link/ether 02:42:29:16:e3:01 brd ff:ff:ff:ff:ff:ff

inet 172.19.0.1/16 brd 172.19.255.255 scope global br-2437bb60b432

valid_lft forever preferred_lft forever

10: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

link/ether 02:42:9e:a0:cc:12 brd ff:ff:ff:ff:ff:ff

inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

valid_lft forever preferred_lft forever

inet6 fe80::42:9eff:fea0:cc12/64 scope link proto kernel_ll

valid_lft forever preferred_lft forever

11: br-8f4313a3e239: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

link/ether 02:42:9f:c9:8d:06 brd ff:ff:ff:ff:ff:ff

inet 172.22.0.1/16 brd 172.22.255.255 scope global br-8f4313a3e239

valid_lft forever preferred_lft forever

12: br-ae25bf0cd9b4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

link/ether 02:42:0a:c5:c3:53 brd ff:ff:ff:ff:ff:ff

inet 172.18.0.1/16 brd 172.18.255.255 scope global br-ae25bf0cd9b4

valid_lft forever preferred_lft forever

35: veth29c3b66@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default

link/ether 9a:87:cc:0d:60:5a brd ff:ff:ff:ff:ff:ff link-netnsid 2

inet6 fe80::9887:ccff:fe0d:605a/64 scope link proto kernel_ll

valid_lft forever preferred_lft forever

raider-diagnostics-20250711-0931.zip

Quote

July 10, 2025Jul 10

Author

A command that brings the interface back up

ip link set eth1 up

root@raider:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master br1 state UP mode DEFAULT group default qlen 1000
    link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:e2:69:7a:45:43 brd ff:ff:ff:ff:ff:ff
8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:e2:69:7a:45:42 brd ff:ff:ff:ff:ff:ff
9: br-2437bb60b432: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:29:16:e3:01 brd ff:ff:ff:ff:ff:ff
10: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:9e:a0:cc:12 brd ff:ff:ff:ff:ff:ff
11: br-8f4313a3e239: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:9f:c9:8d:06 brd ff:ff:ff:ff:ff:ff
12: br-ae25bf0cd9b4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:0a:c5:c3:53 brd ff:ff:ff:ff:ff:ff
35: veth29c3b66@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 9a:87:cc:0d:60:5a brd ff:ff:ff:ff:ff:ff link-netnsid 2

And my docker containers now respond to the external internet via NPM

At least I do not have to reboot.

Quote

1

July 11, 2025Jul 11

Author

The only user scripts I have active is an rsync - hourly job .... here's the result of running the script manually ... absolutely nothing scheduled at 5am

root@raider:~# /usr/sbin/rclone bisync /mnt/remotes/SYN_raider/media /mnt/mira/media --verbose  --resync
2025/07/11 10:58:12 NOTICE: bisync is IN BETA. Don't use in production!
2025/07/11 10:58:12 INFO  : Setting --ignore-listing-checksum as neither --checksum nor --compare checksum are set.
2025/07/11 10:58:12 INFO  : Bisyncing with Comparison Settings: 
{
        "Modtime": true,
        "Size": true,
        "Checksum": false,
        "HashType1": 0,
        "HashType2": 0,
        "NoSlowHash": false,
        "SlowHashSyncOnly": false,
        "SlowHashDetected": true,
        "DownloadHash": false
}
2025/07/11 10:58:12 INFO  : Synching Path1 "/mnt/remotes/SYN_raider/media/" with Path2 "/mnt/mira/media/"
2025/07/11 10:58:12 INFO  : Copying Path2 files to Path1
2025/07/11 10:58:12 INFO  : - Path2    Resync is copying files to         - Path1
2025/07/11 10:58:27 INFO  : There was nothing to transfer
2025/07/11 10:58:29 INFO  : - Path1    Resync is copying files to         - Path2
2025/07/11 10:58:43 INFO  : There was nothing to transfer
2025/07/11 10:58:45 INFO  : Resync updating listings
2025/07/11 10:58:51 INFO  : Validating listings for Path1 "/mnt/remotes/SYN_raider/media/" vs Path2 "/mnt/mira/media/"
2025/07/11 10:58:52 INFO  : Bisync successful
2025/07/11 10:58:52 INFO  : 
Transferred:              0 B / 0 B, -, 0 B/s, ETA -
Checks:            283736 / 283736, 100%, Listed 573808
Elapsed time:        39.7s
root@raider:~#

Quote

July 12, 2025Jul 12

Community Expert

this tells me there is somethings network misconfigured and running that is bring the link down.

as this is correct if ip a / ifconf shows the link to be down and its indeed has a connection..

Reveing diag file. sorry lifes been a bit busy and in and out of the forum latley...

Glad this is working for you as it would be linux temrinal comands to bring down/up maybe even flush...

A command that brings the interface back up

ip link set eth1 up

Given that the network layout

192.168 --- Router --- 10.x --- Router ----- WAN

.....LAN | ........ | DMZ Internet

.........| ........ |

....eth0 +--Unraid--+ eth1

............Server

This could also be casued by a ip route / ip chagne / subnet changed with the unraid device getting a different IP when on the DMZ...

reviewing diag and will report back with findings if any.

Quote

July 13, 2025Jul 13

Author

Thank you @bmartino1 for helping, and hope life being busy is a good thing :). I have fixed ip addresses on both interfaces, and the routers at both ends are very stable. No other devices go down.

Also, all three times the network interface went down was around 5am - and it has only happened after the last update ... so most likely (though not guaranteed) to be a software issue.

Quote

July 13, 2025Jul 13

Community Expert

Some plugins to double-check

double-check the autotweak plugin settings and dynamix.s3.sleep plugin sllep setting.

As sleep may be trying to engage based on a default and misconfigured setting. as autotweak may be editing wol or other power states and is eth1 gets a werid magic pacet and unriad / soemthign told it to go to sleep this would explain the disconects....

Exampe wiht diag file as ethtool for eth1 support WOL but shoing some issues maintating adn secureing a connection...

Settings for eth1:

Supported ports: [ TP MII ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Supported pause frame use: Symmetric Receive-only

Supports auto-negotiation: Yes

Supported FEC modes: Not reported

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Full

Advertised pause frame use: Symmetric Receive-only

Advertised auto-negotiation: Yes

Advertised FEC modes: Not reported

Speed: Unknown!

Duplex: Unknown! (255)

Auto-negotiation: on

master-slave cfg: preferred slave

master-slave status: unknown

Port: Twisted Pair

PHYAD: 0

Transceiver: external

MDI-X: Unknown

Supports Wake-on: pumbg

Wake-on: d

Link detected: no

driver: r8169

version: 6.12.24-Unraid

firmware-version: rtl8168h-2_0.0.2 02/26/15

########################################

*(This could also be plugin realtek modprobe / driver related...)

I would have you also replace the cable from eth1 to the network as eth1 is not getting a full mdix packet that auto sets its speed / duplex curently it was reading as it is unknown...

Also Please install the reltek driver for unraid:

Be aware of Realtek r8169 driver quirks

Unraid’s Realtek r8169 driver is notorious for instability, especially under load or with certain chipsets. Users have seen frequent "Link is down" messages in syslog.

A longstanding community suggestion is to replace it with the vendor-provided r8168 driver, which many find more reliable...

Steps:

Install the Realtek driver plugin for Unraid (search CA for "Realtek").

also try to run
ifconfig eth1 down

ifconfig eth1 up

to fully bring the interface down then up...

Summary and suggested next steps:

Step	Category	Action
1	Physical	Replace cable, check switch port
2	Software	Install Realtek plugin (r8168 driver)
3	Settings	Disable power-saving in autotweak/s3 plugins
4	Configuration	Reassign NIC roles via Network Rules (You could chose eth1 and eth0 and revers to test...)
5	Hardware	Test with Intel-based NIC
6	Quick fix	Use CLI to reenable link without reboot

otherwise you may be forced to crown run the command via user script to sent teh eth ip link up commnad every hour...
https://crontab.guru/#0_4-8_*_*_*

“At minute 0 past every hour from 4 through 8.”

at 2025-07-14 04:00:00

0 4-8 * * *

Quote

July 13, 2025Jul 13

Community Expert

the most likely culprit is the cable.

But here are my finsings formt he syslog diag:

Based on a detailed scan of your syslog.txt and diagnostics, here are notable findings and recommendations beyond the eth1 dropouts:

At 05:01:18, eth1 (r8169 0000:02:00.0) drops its link:

eth1: Link is Down

br1: port 1(eth1) entered disabled state

It tries to come back up at 09:31:41, but fails multiple times

eth1: Link is Up - 1Gbps/Full - flow control off

br1: port 1(eth1) entered blocking state

br1: port 1(eth1) entered forwarding state

then drops again:

eth1: Link is Down

br1: port 1(eth1) entered disabled state

Analysis:

This shows recurring driver instability or hardware negotiation failure.
The Realtek r8169 driver is notoriously unreliable for 24/7 server workloads.

PCIe Power Management + Wake/Sleep Risk (autotweak + s3.sleep)

autotweak sets PCIe power management to auto for eth1:

autotweak: PCIe PM control set to 'auto' for device 0000:02:00.0

dynamix.s3.sleep plugin is also installed and enabled:

(I have had isseus wiht this one and don't recomend the use of the plugin!)

*Risk: If WOL or PCIe ASPM policies are toggling eth1 into a power-saving state at 5 AM, it could cause the NIC to lose link.

In Autotweak, change PCIe PM for eth1 to performance or off.
In S3 Sleep, disable or carefully configure wake/sleep schedules.

Test- fully disable WOL for eth1

ethtool -s eth1 wol d

issues noted at boot:

nvalid EEPROM Warning (eth0 Realtek)

r8169 0000:01:00.0: invalid VPD tag 0x00 (size 0); assume missing optional EEPROM

(Unraid driver plugin should fix this...)

no other known issues that I can tell via the log / diag

Quote

July 13, 2025Jul 13

Author

Thank you @bmartino1 !

I have removed the S3 tweak. Bye Bye. I have disabled ASPM in the Auto Tweak. I have installed the driver for the RTL r8168 and am rebooting now.

The network was very stable until I recently updated Unraid ... so I suspect it is a software issue - Hopefully a power saving tweak not playing nicely with the more recent kernel, or a driver incompatibility ... Again, thew timing of the network going down, and th enew issue starting after an unraid update makes me prefer to try software fixes first ...

I'll post again after the reboot, and a few days.

Thanks again for the fast, and comprehensive response and support. Have an awesome week.

Quote

1

July 13, 2025Jul 13

I just wanted to chime in as I am experiencing the same issue after upgrading to version 7.1.4, where my server would become unreachable basically daily. I don't have a keyboard/display hooked up to my server, but I could see it was online when it went unreachable, and I would reboot it and it would come up fine. I turned on syslog mirroring to my flash so I could check the syslog after these reboots, and found that I had the exact same syslog messages as seen here (r8169 error messages / link down).

I converted my docker configuration from macvlan to ipvlan as was suggested elsewhere, which did not resolve the issue. The server went unreachable again, and I received the same syslog message.

After the last reboot I went ahead and installed the realtek driver for r8168 from community apps, rebooted for the driver to take effect, and so far so good. I have not yet had another instance of it going unreachable.

Quote

2

July 13, 2025Jul 13

Author

@bmartino1 - See above for another Unraider's issues that seem to echo this one @nsutherland .

So, I noticed that Statping had down time for all of my externally facing docker containers. And at the same time (5:01am) the eth1 went down, but this time it went back p again instead of staying dead.

I suspect that the driver update, or the power management changes I made may have solved the issue with the link staying down ... but not what causes the link to go down at 5:01am on a regular basis.

Here's the log showing the eth1 going back up, instead of staying dead (again, than you for the tip to update driver and power management and delete S3 plugin).

Jul 14 04:40:01 raider root: Fix Common Problems Version 2025.05.29
Jul 14 05:01:58 raider kernel: r8168: eth1: link down
Jul 14 05:01:58 raider kernel: br1: port 1(eth1) entered disabled state
Jul 14 05:02:02 raider ntpd[2116]: Deleting 2 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=10594 secs
Jul 14 05:02:09 raider kernel: r8168: eth1: link up
Jul 14 05:02:09 raider kernel: br1: port 1(eth1) entered blocking state
Jul 14 05:02:09 raider kernel: br1: port 1(eth1) entered forwarding state
Jul 14 05:02:11 raider ntpd[2116]: Listen normally on 3 br1 10.1.2.1:123
Jul 14 05:02:11 raider ntpd[2116]: new interface(s) found: waking up resolver
Jul 14 05:02:14 raider kernel: r8168: eth1: link down
Jul 14 05:02:14 raider kernel: br1: port 1(eth1) entered disabled state
Jul 14 05:02:17 raider ntpd[2116]: Deleting 3 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=6 secs
Jul 14 05:02:30 raider kernel: r8168: eth1: link up
Jul 14 05:02:30 raider kernel: br1: port 1(eth1) entered blocking state
Jul 14 05:02:30 raider kernel: br1: port 1(eth1) entered forwarding state
Jul 14 05:02:32 raider ntpd[2116]: Listen normally on 4 br1 10.1.2.1:123
Jul 14 05:02:32 raider ntpd[2116]: new interface(s) found: waking up resolver

Quote

July 14, 2025Jul 14

Community Expert

clearly as this is a bug... either caused by malfunctioning hardware or dfault software configurations...

I still think this is power aspm related with werid power states...

the best way I can describe what the log is reporting here is:

...???... Something in the Linux kernel, be it a chip, the motherboard and its bios, is acting like a usb connection and is flagging the pci/onboard device as becoming disconnected then reconnected.

thus, the kernel/software reads that the physical device was removed from the system.
Then somehow the device becomes reattached.

NTP needs a clock count and set when devices happen as logging and to set a counter...

I can only assume a faulty pcie/irq connection...

Acting like I plugged a usb drive in, then immediately unpluged the device and plugged it back in.

Its the only thing I can assume from other testing that would cause this log message:

Jul 14 05:02:11 raider ntpd[2116]: new interface(s) found: waking up resolver

SO I would have to recommend checking another few arras and potential suggest a grub / kernel edit at this point.

as this could also be caused via cmos and system clock. or a not fully seated pci addon card. even a Acpi bug(windows secure boot BS and bios bugs for motherboards for windows only...)

SO my next checks would be double-check the physical hardware...

Open the case and make sure the devices are fully seated, even unplugging and putting it back in the pciie slot... Confirm all cables are fully connected...

?is the cmos battery diead/dieing on your motherboard?

power off the machine nad unplug the power supply. wait 5 min
- plugin the power back in and enter bios
  - ?did bios factory reset remvoing bios changes?
    - Then replace cmos battery on Mother board...

otherwise I would recomend some syslinux / unraid gruub boot edits...

I would recomend runnign with theses grub boot options..

Click Main Tab > click on Flash > Scroll down to Syslinux Configuration

Lets add these options...

acpi=force acpi_osi=Linux usbcore.autosuspend=-1 pci=noaer pcie_aspm=off r8168.aspm=0

Kernel /bzimage
append initrd=/bzroot acpi=force acpi_osi=Linux usbcore.autosuspend=-1 pci=noaer pcie_aspm=off r8168.aspm=0

*You must reboot to apply the grub settings...

https://www.gnu.org/software/grub/manual/grub/grub.html#Environment

Parameter	Main Purpose	Typical Use in Unraid Setup
`acpi=force`	Force ACPI, fix BIOS quirks	Power states, PCI detection issues
`acpi_osi=Linux`	BIOS compatibility	Ensures BIOS exposes correct features to Linux
`usbcore.autosuspend=-1`	Stable USB behavior	Prevents USB sleep/Power states... Stops USB powered dropouts, also useful in VM passthrough setups
`pci=noaer`	Silence harmless PCIe error spam	Cleaner logs, less overhead
`pcie_aspm=off`	Force full PCIe performance	Kernel level set aspm off instead of autotweak.... (autotweak will ahve a better time assiging power states based on settings...)also Helps avoid GPU/NVMe/USB controller passthrough instability

This will disable PCIe Active State Power Management, both for PCIe and the Realtek driver. Fixing Many NIC flapping issues are power-management related...

then there's making a modprobe.conf using unraid system drivers...

echo "options r8168 aspm=0" >> /etc/modprobe.d/r8168.conf

as we will need to make a file ont eh usb drive or use the web ui to make a modprobe for r8168

Review/change BIOS settings if onboard...

Check for:

"Global C-State Control" → set to Disabled (To test)
PCIe ASPM → Disabled
Onboard LAN Power Saving → Disabled

Due to bugs with ntpd and time I would recommend using only 1 ntp server if auto or turning that to manual....

settings > Date and time

then you could add an adational grub option to fix the device time and clock...

trace_clock=local

By default, the Linux kernel uses a global time source (like TSC, HPET, or ktime) for tracing events (e.g., with ftrace or perf). trace_clock=local switches that behavior:

It makes the ftrace and other trace events use the local CPU’s clock instead of a synchronized global clock.
This helps avoid issues on multi-CPU/core systems where the clock sources aren’t perfectly synchronized.

But this isn't irq, clock level issues as its ntpd forcing a time sync and set at new or reconnect of hardware...

without a full syslog to check other areas thats harder to pin down.

Quote

July 15, 2025Jul 15

Author

Wow - huge response from @bmartino1 - Thank you for your expertise. Let me address each one if I can...

Main thing is this happens at a set time on a random day (5:01am every three or so days). This suggests to me software, not hardware ... but I will go through your comments and try and enact them, or comment on them, as there are a lot of interesting and expert items here. I am in Australian time, so +10 GMT, so this is not a midnight thing + Offset.

I do not have any PCIE devices. The network devices are on the motherboard.
I have unplugged all USB Devices (I had a matter/Zigbee hub, and a BDTV device, now unplugged)
CMOS battery is new and seated well.
I have a weird Chinese motherboard that has an i5 12th gen laptop on a B760 motherboard. It has a custom BIOS and this may be the cause. It was cheap.
Again, this happens at 5:01am on random days, so likely software kicking off the error, unless the BIOS triggers something at 5:01am (I am +10 GMT so not 12:00am thing).
GRUB Edits - I have made th eedit.
I have run echo "options r8168 aspm=0" >> /etc/modprobe.d/r8168.conf
I have set 1 NTP server ... but kept automatic

Quote

July 15, 2025Jul 15

Author

Here's the log of the reboot:  I previously turned off power saving for network in autotweak based on your previous comments.




Jul 15 14:59:47 raider autotweak: Set performance preference to balance_power for CPU 7
Jul 15 14:59:47 raider autotweak: Set performance preference to balance_power for CPU 8
Jul 15 14:59:47 raider autotweak: Set performance preference to balance_power for CPU 9
Jul 15 14:59:47 raider autotweak: Set HWP Dynamic Boost to 1
Jul 15 14:59:47 raider autotweak: Set no_turbo to 0
Jul 15 14:59:47 raider autotweak: Failed to set ASPM policy
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:00.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:02.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:08.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:0a.0
Jul 15 14:59:47 raider autotweak: Skipping device 0000:00:14.0 with banned driver: xhci_hcd
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:14.2
Jul 15 14:59:47 raider autotweak: Skipping device 0000:00:16.0 with banned driver: mei_me
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:17.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1d.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1d.1
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1f.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1f.3
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1f.4
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:00:1f.5
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:01:00.0
Jul 15 14:59:47 raider autotweak: PCIe PM control set to 'auto' for device 0000:02:00.0
Jul 15 14:59:47 raider autotweak: Set SATA link power management to max_performance for host1
Jul 15 14:59:47 raider autotweak: Set SATA link power management to max_performance for host2
Jul 15 14:59:47 raider autotweak: Set r8125 ASPM to disable
Jul 15 14:59:47 raider autotweak: Set r8168 ASPM to disable
Jul 15 14:59:47 raider autotweak: Banned CPUs for network interface interrupt affinity: 0,5
Jul 15 14:59:47 raider autotweak: Usable CPUs for eth0: 8-11
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 125 and rx queue 0 of eth0 to CPU 8
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 126 and rx queue 1 of eth0 to CPU 9
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 127 and rx queue 2 of eth0 to CPU 10
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 128 and rx queue 3 of eth0 to CPU 11
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 142 and tx queue 0 of eth0 to CPU 8 9 
Jul 15 14:59:47 raider autotweak: Set CPU affinity of interrupt 144 and tx queue 1 of eth0 to CPU 10 11 
Jul 15 14:59:47 raider autotweak: Usable CPUs for eth1: 8-11
Jul 15 14:59:47 raider autotweak: Unknown rx queue configuration for interface eth1
Jul 15 14:59:47 raider autotweak: Maximum interface speed: 1000 Mb/s
Jul 15 14:59:47 raider autotweak: TCP parameters optimized
Jul 15 14:59:47 raider unassigned.devices: Mounting 'Auto Mount' Remote Shares...
Jul 15 14:59:47 raider unassigned.devices: Using Gateway '192.168.1.254' for Remote Shares.
Jul 15 14:59:47 raider kernel: eth0: renamed from veth3fa2c7c
Jul 15 14:59:47 raider unassigned.devices: Waiting 5 secs before mounting Remote Shares...
Jul 15 14:59:47 raider rc.docker: pihole: started successfully!
Jul 15 14:59:47 raider kernel: eth0: renamed from veth168e042
Jul 15 14:59:47 raider rc.docker: Nginx-Proxy-Manager-Official: started successfully!
Jul 15 14:59:47 raider kernel: eth0: renamed from vethefd1165
Jul 15 14:59:48 raider rc.docker: GoAccess-NPMLogs: started successfully!
Jul 15 14:59:48 raider kernel: eth0: renamed from veth85d59e2
Jul 15 14:59:48 raider rc.docker: PostgreSQL_Immich: started successfully!
Jul 15 14:59:48 raider kernel: eth0: renamed from veth80cf594
Jul 15 14:59:48 raider rc.docker: Jellyfin: started successfully!
Jul 15 14:59:48 raider kernel: eth0: renamed from veth2438b9c
Jul 15 14:59:48 raider rc.docker: DumbDo: started successfully!
Jul 15 14:59:48 raider kernel: eth0: renamed from vethe1ecaf2
Jul 15 14:59:48 raider rc.docker: ConvertX: started successfully!
Jul 15 14:59:49 raider kernel: eth0: renamed from vethc9e3721
Jul 15 14:59:49 raider rc.docker: Omnitools: started successfully!
Jul 15 14:59:49 raider kernel: eth0: renamed from vethdced8bb
Jul 15 14:59:49 raider rc.docker: web-check: started successfully!
Jul 15 14:59:49 raider kernel: eth0: renamed from vethfb5157a
Jul 15 14:59:49 raider rc.docker: Cloudreve: started successfully!
Jul 15 14:59:49 raider kernel: eth0: renamed from vethd73c2b0
Jul 15 14:59:50 raider rc.docker: it-tools: started successfully!
Jul 15 14:59:51 raider kernel: eth0: renamed from veth8974de9
Jul 15 14:59:51 raider rc.docker: navidrome: started successfully!
Jul 15 14:59:55 raider unassigned.devices: Mounting Remote Share '//SYN/raider'...
Jul 15 14:59:55 raider unassigned.devices: Mount SMB share '//SYN/raider' using SMB default protocol.
Jul 15 14:59:55 raider unassigned.devices: Mount SMB command: /sbin/mount -t 'cifs' -o rw,hard,relatime,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,retrans=3,actimeo=10,rsize=1048576,wsize=1048576,closetimeo=30,credentials='/tmp/unassigned.devices/credentials_SYN_raider' '//SYN/raider' '/mnt/remotes/SYN_raider'
Jul 15 14:59:56 raider reload_services: execute queued job 6
Jul 15 14:59:57 raider rc.nginx: Updating Nginx server daemon...
Jul 15 14:59:57 raider rc.nginx: Reloading Nginx server daemon...
Jul 15 14:59:57 raider rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration...
Jul 15 14:59:57 raider rc.nginx: /usr/sbin/nginx -t -c /etc/nginx/nginx.conf
Jul 15 14:59:57 raider rc.nginx: Reloading Nginx server daemon configuration...
Jul 15 14:59:59 raider kernel: Key type dns_resolver registered
Jul 15 14:59:59 raider kernel: Key type cifs.idmap registered
Jul 15 14:59:59 raider kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
Jul 15 14:59:59 raider kernel: CIFS: enabling forceuid mount option implicitly because uid= option is specified
Jul 15 14:59:59 raider kernel: CIFS: enabling forcegid mount option implicitly because gid= option is specified
Jul 15 14:59:59 raider kernel: CIFS: Attempting to mount //SYN/raider
Jul 15 14:59:59 raider unassigned.devices: Successfully mounted '//SYN/raider' on '/mnt/remotes/SYN_raider'.
Jul 15 14:59:59 raider unassigned.devices: Device '//SYN/raider' is not set to be shared.
Jul 15 15:00:00 raider kernel: eth0: renamed from veth84b2d63
Jul 15 15:00:00 raider rc.docker: MeTube: started successfully!
Jul 15 15:00:00 raider kernel: eth0: renamed from veth80b52a9
Jul 15 15:00:00 raider rc.docker: StirlingPDF: started successfully!
Jul 15 15:00:00 raider kernel: eth0: renamed from veth1636619
Jul 15 15:00:00 raider rc.docker: Statping-ng: started successfully!
Jul 15 15:00:00 raider rc.docker: Statping-ng: wait 60 seconds
Jul 15 15:00:32 raider webgui: Successful login user root from 192.168.1.150
Jul 15 15:00:50 raider ntpd[2079]: Soliciting pool server 150.107.75.115
Jul 15 15:00:50 raider ntpd[2079]: 150.107.75.115 local addr <null> -> 192.168.2.1
Jul 15 15:00:51 raider ntpd[2079]: Soliciting pool server 103.165.180.123
Jul 15 15:00:51 raider ntpd[2079]: 103.165.180.123 local addr <null> -> 192.168.2.1
Jul 15 15:00:52 raider ntpd[2079]: Soliciting pool server 162.159.200.123
Jul 15 15:00:52 raider ntpd[2079]: 162.159.200.123 local addr <null> -> 192.168.2.1
Jul 15 15:01:00 raider rc.docker: Containers started.

Quote

July 15, 2025Jul 15

Author

And please note that this ran fine for 6+ months before the latest version of unraid ... (and me adding some docker containers).

I have had issues with network and unraid previously - on an older i7

Quote

July 15, 2025Jul 15

Community Expert

Jul 15 14:59:47 raider autotweak: Failed to set ASPM policy

...

Jul 15 14:59:47 raider autotweak: Set r8125 ASPM to disable
Jul 15 14:59:47 raider autotweak: Set r8168 ASPM to disable

OK, this may be a docker realted issue as well. time will tell on that though...

what is the output of lspci -v what is the drive in use for the onboard nic? r8125 or r8168 or both 2 realtek nics onboard?AS This may be caused by autotweak plugin... as if it not able to write its config correctly. but this is expected if your using the grub option I mentioned. as We set it earlier at boot and now its in the kernel.Please post a diag file if it happens again.we can add a sysnotif user script thatt needs manual run to look for exact working in the syslog and sine it happens constantly around 5 AM ish we can also have it look at that as well something I ediet for my needs to help scan and look for key words in the logs... adapted from another script on the forum...

#!/bin/bash
# #####################################
# Name:        Syslog notify v1.4 (custom)
# Description: Creates Unraid notification on errors and writes eth1 drop log context to /tmp/notify.txt
# Author:      Based on Marc Gutt + Custom check of eth1 drop
# #####################################
# Settings
syslog_file=$(ls -t /var/log/syslog{.[0-9],} 2>/dev/null | head -n 1)
log_file="/tmp/syslog-notify-last-error-line-number.log"
notify_context="/tmp/notify.txt"
words="corrupt|error|fail|tainted"
ignore_lines=(
  'kernel: CIFS: VFS: \\*\* error -9 on ioctl to get interface list'
  'sshd[*]: Read error from remote host  port : Connection reset by peer'
  'sshd[*]: Read error from remote host  port : Connection timed out'
)
# Make script race-safe
if [[ -d "/tmp/${0//\//_}" ]] || ! mkdir "/tmp/${0//\//_}"; then echo "Script is already running!" && exit 1; fi; trap 'rmdir "/tmp/${0//\//_}"' EXIT;
# Get starting line
if [[ -f "$log_file" ]]; then
  line_number_start=$(cat "$log_file")
  [[ $line_number_start -gt $(grep -c ^ "$syslog_file") ]] && line_number_start=0
else
  line_number_start=$(grep -c ^ "$syslog_file")
  line_number_start=$((line_number_start-100))
  echo "$line_number_start" > "$log_file"
fi
# ---------------------------
# Section 1: eth1 Drop Scanner
# ---------------------------
context_lines=3
eth1_matches=$(tail -n +"$((line_number_start+1))" "$syslog_file" | grep -ni "r816[89].*eth1: Link is Down")
if [[ -n "$eth1_matches" ]]; then
  while read -r match; do
    line_num=$(echo "$match" | cut -d: -f1)
    matched_line=$(echo "$match" | cut -d: -f2-)
    absolute_line=$((line_num + line_number_start))
    {
      echo "=== eth1 DOWN Detected @ $(date) ==="
      sed -n "$((absolute_line - context_lines)),$((absolute_line + context_lines))p" "$syslog_file"
      echo ""
    } >> "$notify_context"
    # Update marker
    echo "$absolute_line" > "$log_file"
  done <<< "$eth1_matches"
fi
# ---------------------------
# Section 2: Generic Error Notifier
# ---------------------------
EOL=$'\n'
errors=""
while read -r line; do
  for ignore_line in "${ignore_lines[@]}"; do
    IFS=\* read -r one two three four <<< "$ignore_line"
    if [[ $line == "$one""$two"*"$three"*"$four" ]]; then
      continue 2
    fi
  done
  last_line="$line"
  errors="$errors$EOL$line"
done < <(tail -n +"$((line_number_start+1))" "$syslog_file" | grep -iP "($words)")
if [[ $errors ]]; then
  line_number_start=$(grep -nFx "$last_line" "$syslog_file" | cut -f 1 -d ":")
  echo "$line_number_start" > "$log_file"
  /usr/local/emhttp/webGui/scripts/notify -i "alert" -s "syslog $(echo "$errors" | grep -ioP "($words)" | tr '[:upper:]' '[:lower:]' | sort -u | xargs)" -d "${errors:1}"
else
  line_number_start=$(grep -c ^ "$syslog_file")
  echo "$line_number_start" > "$log_file"
fi
# ---------------------------
# Section 3: Log Size Check
# ---------------------------
log_size=$(df | grep -oP "[0-9]+(?=% /var/log)")
if [[ ! -f /tmp/syslog-notify.size ]] && [[ $log_size -gt 90 ]]; then
  touch /tmp/syslog-notify.size
  /usr/local/emhttp/webGui/scripts/notify -i "alert" -s "log utilizes more than 90%!" -d "$(du -h /var/log/* | sort -h | tail)"
elif [[ -f /tmp/syslog-notify.size ]]; then
  rm /tmp/syslog-notify.size
fi

this script when manual run will:

Script is self-contained and preserves original functionality.
No unnecessary notifications, just logs to /tmp/notify.txt when eth1/br1 flaps.
Easily view the log: cat /tmp/notify.txt or tail it live:
tail -f /tmp/notify.txt

a tmp file will be written into ram and gone at reboot... a file writes a log to: /tmp/notify.txt to help diag events when it happens again...

mut g sysnotif script of error.txt

Quote

July 15, 2025Jul 15

I'm facing the same issue, but my server, after upgrading to 7.1.4 from 7.1.3, started to totally kill my network around 3 AM, and it would recover only after 15-30 minutes.
After a week of trial and error, I narrowed it down to my unraid server.
It seems to be that when it downloads the docker images, it kills the ability of every single device on the network to reach the internet and each other, almost like if it creates a broadcast storm.

I was able to replicate the issue by manually updating a docker container:

In these screenshot I'm trying to ping from my Windows pc to another docker container (not the one being updated) and to the Cloudflare DNS, and as you can see, as soon as I start the container update, the internet ping becomes much slower and the other container stops to respond all together.

As soon as it ends, everything gets back to normal.

I uploaded the diagnostics file, but if there's no real fix as of right now, I'm thinking of rolling back to 7.1.3.

Just to add some context, I have a pfSense with 2 VLANs, and I'm using 2 Ubiquiti switches.

unraid-ws-diagnostics-20250715-1802.zip

Quote

July 15, 2025Jul 15

Community Expert

6 minutes ago, gguglielmi said:
I'm facing the same issue, but my server, after upgrading to 7.1.4 from 7.1.3, started to totally kill my network around 3 AM, and it would recover only after 15-30 minutes.
After a week of trial and error, I narrowed it down to my unraid server.
It seems to be that when it downloads the docker images, it kills the ability of every single device on the network to reach the internet and each other, almost like if it creates a broadcast storm.
I was able to replicate the issue by manually updating a docker container:
In these screenshot I'm trying to ping from my Windows pc to another docker container (not the one being updated) and to the Cloudflare DNS, and as you can see, as soon as I start the container update, the internet ping becomes much slower and the other container stops to respond all together.
As soon as it ends, everything gets back to normal.
I uploaded the diagnostics file, but if there's no real fix as of right now, I'm thinking of rolling back to 7.1.3.
Just to add some context, I have a pfSense with 2 VLANs, and I'm using 2 Ubiquiti switches.
unraid-ws-diagnostics-20250715-1802.zip

should be it own general support thread while simlar not the same.

your are refering to the script screen and TTYl unraid limt resource.

the same can be seen when applying a docker temapte and opeing a new tab and trying to connect to unraid and do another task.

Unraid is not a muti user target nor task driven system. the applying of the tempatel, dolowading of thte docekr adn other are all apart onf 1 big script taht will and must take some things offline to reestablish them otherwise while it will be onteh system it will not be nt eh web server emhttp that unraid is running.

you can open a web ttyl and docker pull mutiple in mutiple web ttyl and not get the same discoenct or unresobive ness. this is becae only docker adn pull was called and not the other in teh intended operation of unraid.

the OP issue here is a different netowrk issues that is partly due to docker and the br1 setup, along with misconfiguration of the sleep plugin / autotweak plugin with power causng a disconect on the device entering a sleep state.

@gguglielmi

Your issue is not the same.

Quote

July 16, 2025Jul 16

19 hours ago, bmartino1 said:
should be it own general support thread while simlar not the same.

your are refering to the script screen and TTYl unraid limt resource.

the same can be seen when applying a docker temapte and opeing a new tab and trying to connect to unraid and do another task.

Unraid is not a muti user target nor task driven system. the applying of the tempatel, dolowading of thte docekr adn other are all apart onf 1 big script taht will and must take some things offline to reestablish them otherwise while it will be onteh system it will not be nt eh web server emhttp that unraid is running.

you can open a web ttyl and docker pull mutiple in mutiple web ttyl and not get the same discoenct or unresobive ness. this is becae only docker adn pull was called and not the other in teh intended operation of unraid.

the OP issue here is a different netowrk issues that is partly due to docker and the br1 setup, along with misconfiguration of the sleep plugin / autotweak plugin with power causng a disconect on the device entering a sleep state.

@gguglielmi
Your issue is not the same.

I opened a dedicated support thread, thanks.

Quote

July 16, 2025Jul 16

I actually think there are 4 similar cases where 7.1.4 is having driver related issues with the network interface between my own machine and these 3 different user posts....

user 1 - https://forums.unraid.net/topic/191773-unarid-web-guihost-sevicesssh-freezes-but-dockerservices-still-running/
user 2 - https://forums.unraid.net/topic/192047-network-issue-after-714-update-from-713/
user 3 - this one

user 4 - me

Here is the AI output comparing the various diagnostic logs together

I'm extracting and analyzing the new Unraid diagnostics from this different user ("raider") now, focusing on network stability and comparing to your logs and the prior user.

I'll identify the root cause of the network issues and build a comparison table showing key log indicators and outcomes for you.

Give me a few moments.

I've completed a detailed review of the "raider" user's diagnostics and compared them with your logs and the previously analyzed user's logs.

Summary Table: Network-Related Issues Comparison

Aspect	Your Logs (7.1.4)	User 1 Logs (7.1.4)	User 2 ("raider") Logs (7.1.4)
NIC Model & Driver	Intel igb driver on Z790 motherboard	Intel igb driver, similar platform	Intel igb driver (same or similar)
NIC Link Flapping (Link Down/Up)	Yes, frequent link downs & ups	Yes, frequent link downs & ups	Yes, frequent link downs & ups
Web GUI / emhttp Issues	Multiple slow UI responses, emhttp restarts	Multiple UI freezes and restarts	Similar emhttp hangs, UI unresponsive
SSH Connectivity	Lost during network instability	Intermittent/Unavailable during freezes	Lost or unreliable during network issues
Docker Containers	Running normally during freezes	Running normally during freezes	Same pattern — containers unaffected
SMART / Disk Health	No disk errors	No disk errors	No disk errors
CPU/RAM / Hardware Errors	None detected	None detected	None detected
Power Saving Settings Impact	Suspected EEE / C-States issues	CMOS reset, C-States off, SVM on	No direct BIOS logs, but similar symptoms
Common Culprit	NIC driver instability (Intel igb)	NIC driver instability (Intel igb)	NIC driver instability (Intel igb)
Additional Notes	RAM disk usage conflicts possible (Tdarr)	Disk error also present but likely secondary	No disk errors, purely network issues

Culprit Across All Cases:

The common and root issue is repeated NIC link flapping caused by Intel igb network driver instability on similar hardware/chipsets running Unraid 7.1.4.

This instability leads to network loss causing the Unraid web GUI (emhttp) and SSH connections to become unresponsive or fail. The kernel remains operational, so Docker containers continue running normally.

Recommended Consolidated Actions:

Step	Details
Replace network cables	Use known good high-quality Ethernet cables
Switch ports test	Move server to a different switch port or directly connect
BIOS/Firmware update	Update motherboard BIOS and NIC firmware from vendor websites
Disable Energy Efficient Ethernet (EEE)	Disable in BIOS or using `ethtool` to reduce link flapping
Disable CPU Power Saving (C-States)	Disable or test impact in BIOS settings
Test alternate NIC hardware	Install a different network card to isolate hardware fault
Monitor logs actively	Use `ethtool`, `dmesg`, and `syslog` for NIC link status
Setup watchdog scripts	Automate restart of `emhttp` or NIC driver on UI/network failure

If you want, I can help you build scripts to automate monitoring and recovery or provide detailed instructions on BIOS settings and ethtool commands to tweak NIC parameters.

Would you like me to prepare that?

Quote

July 20, 2025Jul 20

Author

This seems to be an unraid SOFTWARE issue - consistently at 5:00am - 5:20am on a random day the eth1 goes down.

Updating the driver and disabling power management seems to have fixed th eissue that the unraid box becomes unresponsive to eth1 after this event, but it still goes down and has issues for docker containers.

Below is the log showing several good days, then another eth1 down event at 5:00am-ish

Jul 18 02:16:42 raider monitor_nchan: Stop running nchan processes
Jul 18 04:40:01 raider root: Fix Common Problems Version 2025.05.29
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Cloudreve has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application open-webui has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application pihole has an update available for it
Jul 18 04:40:10 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it
Jul 18 04:41:03 raider root: Fix Common Problems: Error: Invalid folder cache contained within /mnt
Jul 18 22:50:04 raider webgui: Successful login user root from 192.168.1.150
Jul 18 22:50:57 raider root: Fix Common Problems Version 2025.05.29
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application Cloudreve has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application open-webui has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application pihole has an update available for it
Jul 18 22:51:08 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it
Jul 18 22:52:04 raider root: Fix Common Problems: Error: Invalid folder cache contained within /mnt
Jul 19 02:45:31 raider monitor_nchan: Stop running nchan processes
Jul 19 04:40:01 raider root: Fix Common Problems Version 2025.05.29
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Cloudreve has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application open-webui has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application pihole has an update available for it
Jul 19 04:40:10 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it
Jul 20 04:00:31 raider root: /mnt/mira: 978 GiB (1050006622208 bytes) trimmed on /dev/sdb1, /dev/sdc1
Jul 20 04:40:02 raider root: Fix Common Problems Version 2025.05.29
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Appsmith has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application bookstack has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Cloudreve has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Metabase has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application MongoDB has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application netdata has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application Omnitools has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application open-webui has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application pihole has an update available for it
Jul 20 04:40:10 raider root: Fix Common Problems: Warning: Docker Application SearXNG has an update available for it
Jul 20 05:00:36 raider kernel: r8168: eth1: link down
Jul 20 05:00:36 raider kernel: br1: port 1(eth1) entered disabled state
Jul 20 05:00:40 raider ntpd[2079]: Deleting 4 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=259119 secs
Jul 20 05:00:45 raider kernel: r8168: eth1: link up
Jul 20 05:00:45 raider kernel: br1: port 1(eth1) entered blocking state
Jul 20 05:00:45 raider kernel: br1: port 1(eth1) entered forwarding state
Jul 20 05:00:47 raider ntpd[2079]: Listen normally on 5 br1 10.1.2.1:123
Jul 20 05:00:47 raider ntpd[2079]: new interface(s) found: waking up resolver
Jul 20 05:00:53 raider kernel: r8168: eth1: link down
Jul 20 05:00:53 raider kernel: br1: port 1(eth1) entered disabled state
Jul 20 05:00:56 raider ntpd[2079]: Deleting 5 br1, [10.1.2.1]:123, stats: received=0, sent=0, dropped=0, active_time=9 secs
Jul 20 05:01:08 raider kernel: r8168: eth1: link up
Jul 20 05:01:08 raider kernel: br1: port 1(eth1) entered blocking state
Jul 20 05:01:08 raider kernel: br1: port 1(eth1) entered forwarding state
Jul 20 05:01:10 raider ntpd[2079]: Listen normally on 6 br1 10.1.2.1:123
Jul 20 05:01:10 raider ntpd[2079]: new interface(s) found: waking up resolver
Jul 20 18:12:28 raider webgui: Successful login user root from 192.168.1.150

Quote

Unraid 7.1.4 - network interface keeps going down at 5am - More updates (11 July) and info and diagnostic zip attached - Help requested

Featured Replies

It happened again - same time, different day

LOG

CRON

NETWORK - ip link

Other commands

Summary and suggested next steps:

PCIe Power Management + Wake/Sleep Risk (autotweak + s3.sleep)

Review/change BIOS settings if onboard...

Summary Table: Network-Related Issues Comparison

Culprit Across All Cases:

Recommended Consolidated Actions:

Join the conversation

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)