trurl

Do you know how?

Do you have Notifications setup to alert you by email or other agent as soon as a problem is detected?

1 too many. You must correct

Parity isn't required in the array, and in addition to the array, you can have one (or more with latest beta) pool(s) which support various btrfs raid configurations.

You shouldn't have to login to know you have a problem. Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss. On mobile now will look at Diagnostics later.

For future reference, please assume we want the complete zip. It has many things in it that can help make much more sense of things than just the syslog. I often don't even look at the syslog until I have looked at other things in diagnostics just to get some context of what I might be looking for in those hundreds of lines of syslog. And many things syslog doesn't even tell us that are in other parts of the diagnostics. Save everyone time if we don't even have to ask for it. For example, it was 4 hours after your initial question before we finally got the diagnostics.

It's not a requirement exactly, but it has been observed that USB3 disconnects are more likely than USB2 for some, and USB3 speed has no advantage in this application since it is just loading the OS into RAM at boot and not reading/writing much to flash after that.

Just do a correcting parity check and let it complete, then do a non-correcting parity check to verify there are no parity errors.

This means it is having a problem with Flash. Put it in your PC and let it checkdisk. While there make a backup. Try again, boot from a USB2 port.

How many sync errors is it reporting now? When you added the 12TB data disk did you let Unraid clear it, or did you use one of the preclear utilities on it? I am still wondering if your parity was valid since it seemed to be correcting a lot of parity errors later in the parity check.

These are connection problems not disk problems Diagnostics might give more information about the connection

Might as well wait until you make that change before further testing.

Not only appdata, but domains and system shares should also be on cache and set to stay on cache. You have these shares set to be moved from cache to the array. Not only is there a performance impact for dockers / VMs due to parity, but having these on the array will also keep disks spunup since these will always have open files.

Also Call Trace at the end of syslog. Since you are running Ryzen maybe something here is relevant to that:

This makes me wonder if you know that parity only needs to be as large as the largest single data disk. Parity is not a backup and contains no data, but it looks like you may have sized parity so it is as large as the total data storage. 8TB of that parity is currently wasted, but it does mean you can use 12TB data disks in the future. Once parity check hits 4TB it isn't doing anything at all except verifying the rest of parity disk is zeros. In fact other disks can spin down at that point unless something else is using them. Doesn't explain the slower progress at that point though. Syslog seems to indicate parity is being corrected, probably beyond the point where no other disks are involved and parity should be all zeros already. Are you sure you did the initial parity build when you added that parity disk? What else can you tell us about how you got to this point?

Doesn't look like any are currently hot. Parity has this: Power Cycle Min/Max Temperature: 23/63 Celsius Lifetime Min/Max Temperature: 4/71 Celsius Disk4 has this which seems unlikely: Power Cycle Min/Max Temperature: -127/127 Celsius Lifetime Min/Max Temperature: -127/127 Celsius and the fact that 127 is the largest 7-bit number also makes it suspect

From Diagnostics, system/lscpu Model name: AMD Ryzen 3 2200G with Radeon Vega Graphics Maybe something relevant here:

Diagnostics already includes syslog since last reboot so no need to post that separately. Since syslog is in RAM like the rest of the OS, Syslog Server lets you save syslogs elsewhere so they aren't lost on reboot. Without Syslog Server there is no information from before crash so that is what might help in the event of crash.

You should only allow access to your server with VPN. If you have put your server on the internet you are already being attacked.

I always recommend a parity check any time there has been any change to disk assignments, whether add, remove, or replace, just to verify everything is working as expected.

Seems like nothing you can do but hard reboot if it isn't responding to local keyboard and on the network. Post Diagnostics ZIP after reboot, it likely won't tell us anything about the crash, but it will give us a lot of other useful information. Also, setup Syslog Server so you can retrieve syslog after next crash:

Unraid is just reporting what the drives are reporting. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

SMART for disk8 looks OK. I always do an extended test in this situation too, then just reset the error count if everything is OK (Main - Array Operation - Clear Stats). When was your last parity check? Did it have exactly ZERO (the only acceptable result) sync errors?

In fact, except for syslog, the other 2 of your attachments don't provide any information at all. Diagnostics includes that syslog and a lot more as mentioned, so we always prefer the complete Diagnostic ZIP file. In some cases it might be useful to get older syslogs from setting up Syslog Server, but we can see about that later. The syslog you did attach is spammed with nvidia related entries. Do you have the same problems if you use the stock Unraid? Please attach the Diagnostics ZIP file to your NEXT post in this thread.