CandleSir

I am not sure if this is the "best practices" method, but I had this exact same error with log spam and setting pcie_aspm=off fixed it for me. On the Main page, click on your boot device ("Internal Boot" or "Boot(Flash)", etc), then under the Boot Parameters tab in the Power Management section you can set that with a toggle. Then just reboot.

Rule of thumb is downstream devices first, then the switch ports. Also worth making a quick backup of your network.cfg: cp /boot/config/network.cfg /boot/config/network.cfg.bak and I reassigned the MAC addresses when I did mine so if you do that, backup network-rules.cfg as well. It is worth checking the docs as I had a couple other things I was doing as part of the process that are not required, but here is my experience: I reassigned my MAC addresses so my new dual SFP+ interfaces were eth0 and eth1, and my original single SFP+ was eth2. Enable bonding on eth0, adding eth1 as a member and pick your bonding mode. For LACP that is Mode 4 but the Unraid help blurb is very descriptive. Apply your changes and shutdown. Enable LACP on the switch ports and then boot Unraid back up. One thing worth mentioning: my original SFP+ (new eth2) stayed online as a normal bridge so I had a live connection the whole time while the bond came up. If you are bonding your only 2 ports it will be different so the order matters more for you. The link may drop after creating the bond on Unraid until the switch ports are configured and up.

I run 802.3ad (Mode 4/LACP) bonding on one of my servers and it works well in my experience. It does not create an aggregate 20Gbps bandwidth for single streams but it does allow for an extra 10Gbps of total bandwidth so that other clients can keep using services without bottle-necking each other. Just make sure you tackle the networking config changes in the right order so that you do not drop your network access. Its also worth noting that LACP helps by adding headroom, but does not actually control or throttle anything. If you are experiencing starved bandwidth on other services while your arr stack is active you would want some QoS rules on either the switch or router to rate-limit or lower the priority on that traffic.

On custom networks like br0.X, the container gets its own IP so these mappings are not recognized. Think about it like using Host networking. Try routing using the "container ports".

That is completely normal in my experience. My server that runs just a handful of containers usually shows around that on my cache activity, and my server that runs over 80 containers shows well over that in nearly constant activity. If you are worried about drive health, at 500KB/s constant writing, it would take nearly 30 years to wear out the endurance on a 600TBW rated drive—this is obviously not counting any times of heavy write activity and only the background noise you are seeing. If you just want to identify what is causing it, I would just echo Kilrah's suggestion of htop, specifically the i/o tab.

I could be wrong, but based on your ping to 192.168.1.5 being "Reply from 192.168.1.40", it seems like your PC has a stale ARP cache entry for 192.168.1.5 causing packets to go to Unraid instead of Pi Hole. You can try running arp -d 192.168.1.5 to clear it and then try the browser again by typing in the IP.

In your docker compose, you have immich_server's port mapped 7070:7070. The container port should be 2283. The mapping is "host:container" so you would want to change that to 7070:2283.

What helped me most was watching syslog for NIC-related messages when the drop happened, and checking interface counters over time with ethtool -S. You’d just want to adjust the interface name and filters for your Mellanox card.

I ran a 24 hour observation using an Intel X520-DA1 SFP+ NIC with a fiber connection and maintained stability with no network drops and no syslog activity (monitored syslog using tail -n 0 -F /var/log/syslog | egrep -i 'ixgbe|eth2|link is|reset|watchdog|NETDEV|pcie|aer|IOMMU|DMA|br0|dhcpcd|IOMMU|SFP|optical'). Even though I will be using the X520-DA1 as the permanent network interface, I am going to further explore the viability of both onboard NICs but as Unraid has been ruled out I will take that exploration elsewhere and mark this as solved. Thank you for the input and taking the time to read my post and offer suggestions.

I do not but that is good thinking. Thanks for the suggestion. In an attempt to further rule out (or confirm) hardware faults, I have someone bringing over a new SFP+ NIC and will be testing with that today.

Thanks for the clarification. That makes sense and I guess the fact it aligned perfectly with the upgrade is purely coincidence here. At least a version discrepancy is one possibility I can stop chasing. I did run 7.2.3 for about 36 hours when I first upgraded and noticed the problem but as I did not capture diagnostics as thoroughly as I am now, I will continue to try 7.2.3 for a longer observation window. That said, I have already ruled out the specific switch port and the cable. The cable is a short, ~3ft, known good and tested Cat6a that sustained this 10 Gbps configuration for ~8 months. I also tested the switch port with other devices, only one of which was a 10 Gbps link though, and it showed no errors or instability. After everything I have ruled out I have trouble committing to a "it must be hardware" approach, admittedly some of this is emotional difficulty as I dropped a pretty penny on this build, but I will continue to run and test on 7.2.3 for a longer observation window and will test a completely different switch if find the ability to do so. I understand that. In this case though, this is a confirmed good and tested ~3ft Cat6a cable. The link was fully stable at 10 Gbps for about 8 months with this exact configuration. No CRC errors or negotiation instability were ever present since the build and configuration were first powered on. Because of this stability, I do not believe the cable itself is the root cause here, although I do agree that 10 GbE copper can be an unforgiving beast in general. I am planning on a move to an SFP+ NIC with fiber for the long term. I just have not rushed this change as the system had been perfectly stable up until this current instability was first observed. For now I will keep trying to isolate the issue while staying on 7.2.3. Overnight severity update: I pulled ixgbe … eth0: NIC Link is Down events from /var/log/syslog.1 and /var/log/syslog covering Dec 26 13:51 → Dec 27 08:36 (198 total link drops). • Daytime / evening (Dec 26, 13:00–21:59): ~24 drops over ~9 hours (~2–3/hour) • Overnight (Dec 27, 00:00–08:36): ~174 drops over ~8.6 hours (~20/hour) This shows the clear order-of-magnitude increase in link instability overnight compared to daytime and I am still not sure what causes this increase each night. Thank you for the feedback and input.

Hi everyone, I’m looking for help diagnosing a persistent and worsening network instability issue that began immediately after updating Unraid. This system was stable for months prior and no hardware changes were made. System OverviewUnraid versions tested: 7.2.3 (initially noticed issue) 7.2.2 (downgraded for testing) Currently back on 7.2.3 for further diagnostics Hardware: CPU: AMD EPYC 7452 Motherboard: ASRock ROMED8-2T NIC: Onboard Intel ixgbe 10GbE RJ45 Memory: 128 GB ECC Boot device: Samsung FIT Plus 64GB (reseated and booted successfully after 1 failed boot) Network: 10GbE RJ45 to Unifi switch (Pro HD 24 port) No bonding (single interface) VLANs configured via bridge (br0 / br0.70) DHCP with static reservation on UniFi (IP unchanged) Diagnostics attached: 7.2.2 diagnostics zip from multi-day run (*1248.zip) 7.2.3 diagnostics zip from after I returned to 7.2.3 today (*1443.zip) Problem SummaryAfter updating to Unraid 7.2.3, the server began experiencing frequent NIC link flaps: ixgbe eth0: NIC Link is Down Followed seconds later by: NIC Link is Up 10 Gbps Bridge ports cycling (br0 / br0.70 disabled → forwarding) DHCP lease teardown and rebind Temporary loss of connectivity (SSH, WebUI, services, Cloudflared tunnel drops) Each event lasts ~5–30 seconds but occurs repeatedly, sometimes every few minutes. ObservationsSystem was rock solid for months before this. No hardware changes, firmware updates, or BIOS changes were made prior to the issue. Only action taken before the issue started was updating Unraid OS. No other changes whatsoever from when the system was stable. The instability is much worse overnight, but has now begun occurring during the day as well. Unifi switch does not seem to reliably log corresponding port down/up events, even while Unraid clearly reports link loss. Testing & Troubleshooting PerformedUnraid 7.2.3 (initial run)Observed frequent NIC flapping. Live monitoring via: tail -n 0 -F /var/log/syslog | egrep -i 'ixgbe|eth0|link is|reset|watchdog|NETDEV|pcie|aer|IOMMU|DMA|br0|dhcpcd'Repeated logs of: Link down/up Bridge disable/enable DHCP route removal and re-addition Downgrade to 7.2.2Downgraded via Tools → Downgrade OS. Perceived improvement: system appeared stable during daytime hours. Overnight instability continued; returned shortly after shutting down PC, continued until I turned my PC back on in the morning and accessed files/SSH Continued monitoring showed same link flap behavior, just less frequent initially. Over time, instability began occurring during the day again. MTU ChangeOriginally running MTU 9000 (jumbo frames). Observed increasing rx_long_length_errors. Dropped MTU to 1500. Result: rx_long_length_errors stopped increasing Link flaps continued Other ChecksFlow control status checked (ethtool -a eth0 → RX/TX off) Offload features inspected No bonding configured Tried different switch ports previously No spare NIC available to swap Current StateSystem is now back on Unraid 7.2.3 Array starts successfully Network instability persists Monitoring still shows repeated: ixgbe eth0: NIC Link is Down Bridge cycling DHCP reset/rebind What I’m Hoping For Help WithI’m trying to understand what changed and how to restore stability without permanently disabling core functionality/abilities of the system. Specifically: Is this a known issue with ixgbe in recent Unraid releases? Are there known regressions involving: 10GbE RJ45 MTU handling Bridge + VLAN setups Are there kernel parameters, driver options, or Unraid settings I should test? Is there a recommended way to validate whether this is OS/driver behavior vs hardware without spare NICs? Am I missing something obvious? I’m happy to run targeted tests or provide additional logs if pointed in a specific direction. Thank you for taking the time to read this. AttachmentsDiagnostics zip (from 7.2.2 run, *1248.zip) Diagnostics zip (from current 7.2.3 run, *1443.zip) A couple other observations: When I reinstalled 7.2.3, the boot USB was not seen and boot failed, this was solved by simply re-seating the USB and trying again. I have another Unraid server on 7.2.3 that is not experiencing the same problems. That server is running completely different hardware though (Intel i5-13500, MSI Z-790 motherboard) cs-15-diagnostics-20251226-1248.zip cs-15-diagnostics-20251226-1443.zip