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.

Your 8TB parity disk (sn#ZCT0LHSD) went from Seek_Error_Rate 120587123 on Sun Mar 29 to ===> 133347312 on Thu Apr 9 Your 4TB disk (sn#WFN1DP18) went from Seek_Error_Rate 34284786 on Sun Mar 29 to ===> 41689377 on Thu Apr 9 If the disks work in another machine then replace your power and data cables, otherwise these numbers going up is not good and indicates a need to replace the disk Why are you trying to add a disk back into the array when you say that it has caused problems in the past?

Have you tried disabling one at a time: dynamix.system.autofan.plg dynamix.system.temp.plg - warning in log ==> (Unraid version too high, requires at most version 6.7.2) plugins/ipmi/freeipmi-1.5.7-x86_64-2.txz

I don't fully understand the checksum error even after googling it. I think that because it's a mirrored pool that files on one side are different from the files on the other. How would you know what to backup? Could he make the shares cache yes, run mover and then reinstall the cache and then make the shares cache prefer or would this lead to the same bad checksums. If he can do that, then here is a pretty good video for the process

Without knowing anything about your situation anything someone says is an absolute shot in the dark but to start I'd say make sure you're using USB2 and not USB3

I'm no expert but the only things that jump out at me are below, in short I suspect your cache but this is outside of my ability, hopefully someone else can better decipher it. I'm not sure but is it normal to have that much memory cached? This is probably not related but this communication error repeats throughout the syslog, likely a loose cable.... Below is where I think your troubles lie.... I suspect there is something wrong with your cache pool, looks like one device (sdd1) is missing or something, you also have a ton of your shares set to use cache and the floor was pretty high if I understand that right. Also, it looks like you may have your VMs on the array and not on the cache, which is also unusual. To reiterate, I suspect that between your cache and possibly the mover, (see warning about the deprecated plugin below) is where you should start troubleshooting. Maybe someone else will see something more definitive but hopefully this will give you an aha moment...

hopefully not, SMART looks fine JB ( ↓ ) is the resident expert on hardware, FS corruption, etc, below are a few threads where he's discussed how to handle this type of thing. I'm by no means an expert so do your due diligence but what I get from the first thread is that you should run xfs_repair without -n, and use -L if needed (you may end up with a lost and found of recovered files). Then verify that the emulated files are all intact before attempting to rebuild. Only rebuild to the same disk if you're positive the disk is good, which I believe it is. The next post "XFS File System Corruption - Safest way to Fix?" talks about using UFSExplorer to recover data from formatted XFS disks if necessary, also the OP discusses repairing the corruption outside of unRaid in Fedora where the xfs_repair is native. also mentioned in the next post... The last thread is probably less relevant but discusses possible causes such as bad ram... So you actually have the original disk intact, ultimately that could prove to be less corrupt make sure you don't clear it until this is all resolved.

There isn't much that is recommended against, the beauty of unRaid is that it is, for the most part, hardware agnostic: I know that Marvel controllers are to be steered clear of, it looks like you have 4 sata ports so keep this in mind if you buy a controller Don't plug your flash into USB 3, this board has 6 USB 2 ports and it looks like 8 USB 3, so make sure you're using the right one Ryzen may necessitate some work arounds ==> Read the FAQ - What can I do to keep my Ryzen based server from crashing/locking up with Unraid? You only have two memory channels, I'd put more than 8GB in, however it will do as long as you're not doing too much with VMs and Dockers I did a quick search on the forum and nothing jumped out at me other than this. Keep in mind, they are discussing gaming, but testdasi is speaking directly about your CPU Anyway, I don't see any major issues, here is a guy with a very similar build the thread is probably a good read because they are discussing variations very similar to your proposed setup.

Yes, I'd replace the power and data cables and then run an extended SMART test

Yeah, I was wondering if just rebuilding them wasn't easier 🤣 Glad everything worked out!

NOTE: I'm not confident that I fully comprehend how the file path for VMs are invoked. I suspect that if the current path says something like /mnt/user/isos and there was no cache, then we can add a cache, set the share(s) to cache prefer and the path known to the VM will still work because, while the disk path has changed, the share path has not. I don't fully grasp symlinks so anyone please correct me if this is wrong. Aside from the SSD, you can do what these guys are telling you with the new config process, if you follow trurl's advice your data will be completely intact, and will not need to be reloaded. However, parity will have to rebuild because you've removed the old data disk 2 (the SSD). EDIT: Actually the data may have to be reloaded if the original disks were striped? The only addition would be to backup your SSD first and then: Assign the SSD to the cache slot during the new config process (choose xfs for cache UNLESS you intend to create a multi-disk cache pool) Start the array and verify that you have the shares isos, domains, system, appdata and that they are set to cache prefer Now move the data files from the SSD backup folders into the corresponding cache folders: (isos, domains, system, appdata) If for some reason your original SSD folders were not named to the unRaid defaults (isos, domains, system, appdata) we'll need to fix that Once the data has been transferred, verify that your newly added cache drive looks like your backup of the SSD as it was. Ultimately, please make certain that everything is backed up before you begin. If any of you experts see an issue with my explanation, please feel free to correct me