0rca

Ok, thanks for your help so far anyway. Anybody else who can shed some light on this? I have read several other threads mentioning this behaviour but have yet to find a definitive answer why this is happeing, let alone a way to fix this. Or maybe I have to open a new thread for this.....

Jorge, may I ask you one more thing? I have assigned static IPs to each interface (eth0 - 10.0.0.40, eth1 - 10.2.0.40, eth2 - 10.3.0.40), each in a different vlan (as described above). Why is Unraid publishing additional MAC-adresses for each interface, each having the same IP as eth0. unifi is complaining that I have several devices with the same IP on the network. Why is it doing that and how can I prevent it from doing so?

So then most topics about the issue, the documentation and especially the inline-help are rather misleading, I think. A simple "Don't ever use macvlan and bridging ony any network interface together at the same time" should be written in big red letters everywhere, or am I wrong? Be that as it may, I will switch all dockers to eth2 and disable bridging alltogether and report back.

Afaict and if I interpreted everything correctly I do have disabled bridging as recommended. Bridging is disabled for eth0 and eth1 and on eth2 I am only using bridging (br2) for most of my dockers, the rest are using eth0. The instructions and recommendations regarding this are not very clear when it comes to multiple NICs, so it was my understanding this should work. The help tells me "Bridging is a feature which creates a virtual bridge and allows VMs and Docker containers to communicate directly with the physical Ethernet port" so I am assuming I need that bridge/br2 in order to connect those dockers to the physical network. And since I am using Unifi for all things network and Unifi and ipvlan don't work well together, I am trying not to use ipvlan. Please correct me, if I got anything of this wrong.

Yep? Sorry I don't get it. It was fixed, and following the instructions completely should prevent those crashes, shouldn't they? If so, why are they still happening for me? Did I implement anything wrong? As mentioned, I have spent a lot of time reading about this and adapting all of my network-related settings, but naturally I might have misunderstood or mixed up some things, so again, any pointers are most welcome.

Hi Jorge, thanks for the lightning fast answer. I assumed this was fixed with 6.12.4 and followed these instructions: https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces ?!?

Hi all, I have been using Unraid for two years now and have always been able to fix any issues by searching the forum or the web. I love the software, the versatility as well as the stability. But the latter has declined drastically since a few weeks. I have been wrecking my brain and tried many things, but can't pinpoint the problem and need your help. First things first: I'll attach the diagnostics file and the (redirected) syslog. The latter is quite big, since it was captured from the moment I tried to get to the bottom of things end of May. So those of you who can read syslogs (I cannot, I am a bit of a Linux noob tbh, more of a Windows pro) will see my various tries at "fixing" my issues. I only edited out the mover file operations. It all started either with the latest Unraid update, or with me trying to better separate my networks. I have only Unifi devices and set up 3 vlans, one untagged, one for all media purposes (vlan2 10.2.0.0/24) and one for IoT devices (vlan3 10.3.0.0/24). My Unraid box (awesome Qnap TS-873A-8G, can only recommend) has one 10GbE NIC and the two onboard 1GbE NICs. My goal was to run all file and streaming traffic through the 10GbE (10.0.0.40), most dockers on vlan2 and all VMs on vlan3. "All" meaning just one Home Assistant OS VM in the end. I hope the diagnostic shows my current settings - what I assumed to be correct after hours and hours of reading and changing network settings. Now to the issue itself: Every few days the machine "freezes", meaning it stops responding (no Web, no SSH, no Ping). The only way to get it back is to reset it (using a long press on the power button of the NAS). Naturally it starts a parity check each time (which takes more than two days) and after that I am looking at the logs to see what happened. Since the problem is relatively new and the hardware has not changed, I am still assuming this to be a software issue, so I have not yet started to swap out parts (insofar this is possible with this NAS), but naturally will do so, if your verdict points to hardware. Since I changed the vlans, I tried looking into the network side of things and switched to ipvlan and back to macvlan, but turned bridging and applied some other recommendations I found on the forum. But the Unraid kept freezing up. After some more changes, eliminating one Windows VM and reassigning all dockers to br2 instead of Bridge I thought it was stable, but the it froze again. Believing the HASS VM might be the culprit I deactivated VMs fo the time being, but yesterday it froze again. Except for deactivating Dockers too or swapping out hardware I don't know what else to try and am at my wits end. Can anyone be so kind and have a look at the attached logs and point me in the right direction? executor-diagnostics-20240626-1239.zip syslog-10.0.0.40.zip

I hope it is ok to post in this thread, since it is the only one covering wildcard certs and I don't have to write down too much context. Our certificate is has a Subject as well as a Common Name of "*.domain.com" and the Subject Alternative Names are "*.domain.com domain.com". We are using the same cert on many servers and I can verify the above with SSLLabs. It is not recognized as valid in Unraid though - Certificate URL: Certificate not valid for tower.domain.com even though the cert itself is ok: Certificate issuer: C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA It is replaced again and again, whatever I try. Can someone help us out?

Just FYI, It happened again today, all disk showed errors and the HBA was gone. I caught it just in time, went to the basement and measured temps. On the HBA heatsink it showed close to 70 degrees Celsius, so the die temperature would be even higher. Not good. I've added some active cooling to the HBA and booted back up. This time Parity 1 and Disk 4 were disabled. I am now rebuilding, hoping that my cooling is now sufficient. I have two question, to better understand the situation: Is it normal, that two disks (1 parity and 1 data) are disabled, because in that specific moment, when the HBA crashes there's bound to always be one data drive with I/O and one parity or am I simply lucky that it is just two, but could easily be more? Theoretically, what would happen in the latter case? Assuming that only a few bytes might actually be wrong, would there be a way to restore the rest of the data or would I have to copy the data from each drives somewhere else to save it? Having been a raid user for decades, the whole Unraid concept is still new to me....

Thanks, will check all that.

Thanks Jorge. I'll do that. It could also be a failing HBA (HP Smart Array H240) though, right? I might get another one just in case, it's good to have a spare ready anyway.

Hi Jorge, thanks for helping me again. I rebooted and it came back up. Diags enclosed. deathstar-diagnostics-20220916-1846.zip

I am not sure if it is preferred to create a new topic or to post in this one for continuity purposes. But I need help again, this time for real. I had Unraid rebuild the array and after 12 hours everything was back to normal. Yay! This morning I did the update to 6.11.0-rc5 and rebooted (saving the diagnostics beforehand, just in case). Everything worked normally for while and then suddenly at 11:00 am I get read errors an ALL 16 disks. I was out-of-office, so I see this only now. Attached are both diagnostic files, the one from this morning after the update and before the reboot and one I did just now before taking the array off-line. I hope there's no reason for panic and would appreciate any help. Cheers, Michael deathstar-diagnostics-20220916-0912.zip deathstar-diagnostics-20220916-1813.zip

Damn, that was fast Thanks Jorge, I'll do that. I just had to check with you guys first, because this is the first rebuild for my on Unraid and I wanted to make sure. Thanks for the blazingly fast answer.

Hi all, two days ago at night, just before going to bed, I realized that my array was off-line and that one parity and one data disk had been disabled at the same time. I was tired and decided to look after everything the next morning and shut down the server. I know now that that was a mistake, because that way I deleted the syslog I have checked everything I could since then, but can only tell that both drives in question are fine and passed the SMART extended self-test. My question now is, what is the safest way to restore these drives. Do I unassign the data disk first and then rebuild it unto itself? Do I start with the parity, since it is the faster drive and the rebuild will be quicker? Or am I thinking wrong and my situation calls for a completely different approach? I'll attach the diagnostics and hope they are sufficient even though the relevant syslog is overwritten. Thanks in advance for any help. Cheers, Michael deathstar-diagnostics-20220914-0949.zip deathstar-smart-20220915-0944.zip