Dissones4U

good, that's a start docker0 is simply the network interface that docker creates to access other dockers and your internet see here for description

I'm not sure I fully get your workflow, it seems like there may be some unnecessary moving going on. Here is my workflow for example: Download files from internet to share [Processing] which is set to cache prefer Aim Sonarr to read from [Processing] every minute, moving the processed files to share [TV] which is set to cache no If [TV] were set to cache yes then the files would be dependent on mover to move processed files to the array on a schedule Sonarr is set to delete source files so the share [Processing] stays empty Also note from the unRaid webui regarding cache settings: I'm not sure if having Sonarr running would lock the files or not...

My understanding is that memtest wont find errors with Error Correction Code memory. Multiple disks at once can be indicative of the controller but I'd expect all disks on the controller to error not just two. The diagnostics zip file doesn't show disks (1 and 3) in the SMART which means they were not connected at the time of the zip download. Disk 8 is helium and I'm not sure how to interpret the data provided in the SMART but Disk 9 clearly shows the faults you've described above. However, the Disk 9 faults were a long time ago based on the current power on hours being over 15k (the faults happened at <3k. Did you move the problematic disks 8 and 9 and then put 1 and 3 in their place? Looking at diagnostics.zip ==>system ==> vars.txt both disks 1 and 3 show 18 errors each so my guess is that whatever they're plugged into is the problem.

As always if anyone sees something wrong or misinterpreted please feel free to correct me, this is my best guess... There are lots of these (↑), related to Nvidia. If I'm not mistaken it means you've installed a modified version of unRaid and would need to seek support for that plugin here. Within that topic someone says they have the same error and then system gets unresponsive. There are lots of these too and according to this thread it can cause cause a locked console. This thread on the unRaid forum says it may be fixed by moving the offending controller. Between this PCIe error and the PCI Bus with Nvidia I think this is where I'd start (your log is completely spammed with these). One final thread about the PCIe error mentions Nvidia too.

24 hours is the typical recommendation

Unfortunately I don't have experience with this and there really isn't much information provided but here are some things for you to consider until someone else chimes in... Enable syslog server, the attached log is only a few minutes long and doesn't really show anything other than: All I could find on this error (↑) was that it may be related to emby? It is absolutely possible that hardware is failing but, I have to ask if something has changed recently, either hardware, software (new or updated), or you may have moved the rig and knocked something loose etc. If not, then, a piece of hardware is failing (possibly the NIC). This post suggests kernel crashing may be related to setting MTU greater than 1500 (Jumbo frames). I've always used the default 1500 and nothing more so I 'm not familiar with making changes to this setting. Again, if the setting has been that way for a year then I'd question if something else has changed recently. Things to try Start in safe mode, no dockers/vms/plugins etc Enable syslog server Pull diagnostics frequently until crash and upload the most recent If your RAM is not ECC then run memtest for 24 hours and add the results along with your diagnostics You may want to consider tailing the log as well, this lets you get a screen shot of things that are not able to be written to the log before it crashes Attach your monitor and keyboard, using the command line enter This will show the last 30 lines, you can change -n or remove it (default is 10). To quit tail... Hopefully this will get you going in the right direction

Make a new post for your other issues, this one says [Possibly solved] in the title so people may not even look at it Post diagnostics with your new request for help Describe your scenario in detail, include recent changes to hardware, software, share settings etc You can do several things: Set share temporarily to cache = no For a large folder with multiple files (Episodic TV seasons) increase mover frequency We'd need to see settings for the share in question, I'm not sure why it would be writing into RAM as that will disappear on reboot

settings ==> global share settings (under system settings) ==> scroll down to cache settings = min free space (Array must be Stopped to change)

Make sure you're USB flash is on a USB2 port, USB3 is known to cause random crashing. I'll look at the diagnostics when I get the chance...

Can you connect a monitor, keyboard and mouse to darktower and boot into safe mode? Is it possible that the dynamix plugin needs to be updated? See here

In general snippets will not suffice, you should post your full diagnostic, include any hardware or software changes (including physically moving the box) within four weeks of the current issue starting. Also include any steps you've taken to troubleshoot your rig including running memtest or turning off and restarting each instance of the following one at a time: dockers vms plugins The thread below provides lots of information on where to start. Aside from that I've linked to the FAQ regarding Ryzen based servers. Have you read the FAQ - What can I do to keep my Ryzen based server from crashing/locking up with Unraid?

Maybe this is nothing but....

I've actually been meaning to ask about this, is the information in this link still accurate?

If I understand you correctly (honestly, the thread was tough to follow) : The 4TB disk in question is the only disk in the array throwing errors at this time The same 4TB disk seems to work perfectly when outside of the array You want to add it back into the array but it begins to error again Assuming that everything above is correct, there are only a few points of possible failure and they all sit between the disk and the mobo: Data and / or power cables Data port Power supply (possibly the breakout if not all disks involved) or you're splitting power from one point to too many disks If there is more than one disk involved, then the point of failure is tougher to troubleshoot: It could be the controller It could be RAM It could be the power supply It could be the CPU Only change one thing at a time between reboots and make sure that your syslog server is set up so that it is persistent.

I knew that was true for the raw read errors but I didn't realize that it applied to all of the attributes, mainly because I didn't understand why it held true for the read errors attribute. Anyway, understanding now that they use a multibit value for all of the attributes helps, thanks. I plugged those into google and they both converted to 0, seems counter-intuitive that they would appear to go up rather than appearing static, but now I know.