gguglielmi

I came here to say the exact same thing. I can provide logs if needed.

Just to update everyone, I think I found the issue. Comparing my system, with a new installation on the same hardware made with the trial key, I noticed that the system routing table metrics were all over the place. Also, I was missing the default route for "shim-br0". I upgraded back to 7.1.4 and then deleted the network.cfg in "/boot/config/". I then rebuilt the network configuration after rebooting. Now the routing table is the same as the test system, and after 12 hours it still seems to be working as expected. I'll update this post if something new comes up.

Well, I'm the OP of this post. I'm not resurrecting a dead thread, I'm simply updating my thread. As I suggested more or less a month ago, I was going to test the 7.2.0 Beta to see if the issue persisted, and it does. But as you suggested, i also opened a bug report yesterday.

Tested 7.2.0 Beta 2 and the issue persists. I attached the diagnostics file, i faced the issue around 01:33 AM. Also during this time, i went from only bonded to a bonded + bridge network setup, but nothing changed. unraid-ws-diagnostics-20250908-0136.zip

After another week, 7.1.3 was rock stable. I updated my ASUS XG-C100F (Marvell AQC113) to a Intel XXV710-DA2 thinking that the card could be the issue, but after upgrading to 7.1.4 again, the issue came back. So i went back to 7.1.3 again. Let's hope that 7.2 fixes the issue. Maybe I'll try the beta.

I went back to 7.1.3 and it has ben rock stable. So my issue is definitely something different.

Maybe the AI fcked up. But i definitely don't have any IGB nic. I'm on 7.1.3 since 3 days, and as of right now everything is working. But even on 7.1.4 i didn't have this port flapping issue. What motherboard and switch are you using? Maybe it's an incompatibility on this side? I was thinking more about a hardware issue.

Well, as of right now, my 2 NICs are already using 2 different drivers. I have a 10Gbps PCIe ASUS XG-C100F (Marvell AQC113) and a 2.5Gbps Realtek (r8125) on the motherboard. Apparently it doesn't matter which one of those I'm using, I get the issue either way.

I agree with you, AI is more often than not wrong. But they definitely changed something about networking. From the 7.1.4 release notes: Networking Fix: Reverted: Improved automatic metric assignments Fix: Prevent the interface monitoring script from deleting the default route Fix: Ensure disabled default routes are not used

I don't have watchtower, but I saw that around that time, the community application looks for updates. But apparently the issue happens when the unRAID OS itself tries to download something from the web, as I was able to reproduce the issue by simply starting the VirtIO ISO download: Well, I spoke too soon. The issue came back after a short time. I tried to break the bond, as suggested by Gemini, but the issue persists. As of right now, I'm definitely rolling back to 7.1.3 ASAP. Something is really broken in 7.1.4, but apparently not for everyone. The thing that really worries me, is that no one from the unRAID team has responded to the threads yet. @CSeK @shinfo44 @kentb does anyone have tried to open a support ticket with unRAID? If not, I can maybe try to open it for all of us later today.

I opened a dedicated support thread, thanks.

Well, my happiness didn't last that long... After ca. 30 minutes, the system totally locked up. I had to force a system reset and right now is running a parity check. I enable the "Mirror syslog to flash" setting, so if it happens again, I can check the logs. On the bright side, the network issue still didn't come back, so at least this issue seems to be resolved.

I have an update, I submitted the logs to Gemini out of curiosity, and it suggested two things: disabling the bond setting up a user script to increase "inotify watch limit" using the command "sysctl -w fs.inotify.max_user_watches=1048576" Fist, I created the user script, but nothing changed, the issue was still there. After disabling the bond, I tried to download a docker image, and the issue seemed to be resolved. After this, just out of curiosity, I enabled back the bond and the issue wasn't there anymore! This is really a weird behaviour. I keep the issue under monitoring, and I will report back if it happens again.

Hello everyone, after upgrading to 7.1.4 from 7.1.3, my unraid server 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 was able to narrow it down to my unraid server, turning off other devices and basically leaving only firewall, switch and unraid. 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 (10.7.0.5) to another docker container 10.7.77.5 (not the one being updated, that has IP 10.7.77.10) 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. Also the docker image download is incredibly slow, it took multiple minutes to download only a handful of MBs. This started happening only after the 7.1.4 update. I've never seen anything similar before the update 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 box with 2 VLANs, and I'm using 2 Ubiquiti switches connected via SFP+ to my unraid server that is using an Asus xg-c100f bonded in active-passive mode with the motherboard r8125 chip. I did not try yet to break the bond, because of time issues. I tried to change the network configuration, changing from a dynamic IP to a static one, but the issue persists. I also tried to enable jumbo frames, but nothing changed. Thanks to anyone who can help. unraid-ws-diagnostics-20250715-1802.zip

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

So, what result did you get from your tests? Unfortunately, I didn't have any optimization ideas and in the end I wasn't able to get better performance from unraid. I'm living with the degraded performance. It would be nice if someone of the unraid developers could look into it.

Are there any news about when the support for a reverse proxy is coming? I guess that we can still make it work by matching the local TLD with the public domain, right? Thank you

Hello to everyone, In the last few days i started to do some testing, comparing vm performance by running Cinebench R15 between unRAID, XCP-NG and ESXi. I have 2 almost identical system, the first one (my main unraid server) has a Xeon E5-2698v3, 64 GB RDIMM, Asus x99 WS/IPMI and a Quadro P2000. This server has also 2x1TB SSD for cache and 4 HDD for the Array (28TB total with single parity). The second one (test server) has only a different CPU, a Xeon E5 2695v3 and no GPUs. On my main server i have a Win10 VM with 16 cpu assigned (8 cores + 8 matching HT) and a Quadro P2000 passed through. In cinebench i was normally getting 1000 points on the multicore test, and between 75 and 80 for the single core on this VM. I tried to replicate the same VM on my test server with a brand new unraid installation and i got almost the exact same score on multi, but a slightly higher score on single (between 100 and 110 points), i think that the higher single score is due to the fact that the test server was only running this VM and nothing else. When i booted up the same sized vm on XCP-NG and ESXi on my test server i was a little bit shocked, at the first try i got 1500 points on multi and 120-125 in single, in cinebench. I wasn't expecting this huge difference. Since then i tried some configuration of the CPU in unraid and i discovered that if i assign to the VM only "true" cores (i tried with 12) i get a higher score (1150 on multi, but the same on single). i got this result on both my main and my test server. I tried also to isolate the cpu cores, but the score got worse on multi, i was down to 850 points. I tried also to add the "emulatorpin cpuset" in the XML of the VM but the performance didn't change that much. Do you have any advice on what to try or what could be the cause of this difference in performance? Thank you in advance Gianluca

I got the same error like 6 months ago on an Asus x99 WS IPMI motherboard with a xeon E5-2698 v3 and 64Gb of ram. Memtest wasn't showing any error at all, but after some trial and error (aka several crashes) i found out that 2 sticks of ram were kind of buggy. After removing them, the system went back to normal. No more error during the last months. To identify the faulty DIMM i used a terminal command, to pair the BANK indicated in the MCE error and the serial number of the physical DIMM. If i remember correctly the command was "dmidecode -t 6", without quotations.