Hello!

I know this has been asked before but I've not found a discussion that correctly matches the symptoms of my issue. I've been running unraid with no issues for 2-3 years. I have a small Supermicro box with two physical disks and an NVM drive used for cache. I have 3-4 Docker containers (pihole, syncthing, unifi-protect-backup, and route53 dns updater). I also have a VM running HACS.

My server keeps coming unresponsive due to the parity check process and when I catch it and I'm able to log in I just see 100% (or close to) CPU utilisation across all the cores and a most of the CPU being chewed up by shfs processes. I have tried a few things including moving docker instances from /mnt/user to /mnt/cache where appropriate as well as reducing the number of applications running. Unfortunately I still seem to be getting this recurring issue and I can't figure out what changed or what I'm doing wrong. Here's an example htop from today during a parity check:

I've also attached my diagnostics dump.

I'd be grateful if anyone can suggest how to diagnose and resolve this issue!

viper-diagnostics.zip

Parity check should not have anything to do with shfs, other than possibly making i/o slower. Does it still happen if you disable rclone during the check?

I've tried shutting down syncthing which I presume is driving that but it's not made a huge difference. The instance of /usr/sbin/smartctl -A /dev/sdc is using a large amount of CPU and has been running for 90+ hours - is that normal?

Nope, try rebooting in safe mode and leaving all services disabled, then retest. If all looks OK, start re-enabling them one by one.

Thank you, will do. Stupid question but what would have instantiated that process?

It could be GUIm if you tried to look at a device's SMART attributes.

I'm not sure what that is. Can you explain a bit more about what I should be looking for?

Made a typo, I meant using the GUI to look at a SMART data:

If you didn't do that it could have been Unraid just getting the temps, for example, or a plugin.

Frustratingly, after ~24 hours in safe mode the server has once again become unresponsive and requiring a restart. Initially it looked fine and load was low but I suspect after restarting the array the parity check again caused it to crash.

What's the best way to further diagnose what's going on?

Enable the syslog server and post that after it happens again.

This is a very delayed response to this thread as I initially thought I'd resolved this but it's returned once again. Here's the tail of the logs immediately prior to the system becoming unresponsive during a parity check (I rebooted a few times and the same thing repeated). I had Docker enabled (3x containers) and 1x VM (HAOS).

parity-check-crash-sanitized.log

There are no timestamps, but assuming the snippet doesn't include the next boot, unfortunately, there's nothing relevant logged, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days and confirm it doesn't crash like that, if it doesn't start turning on the other services one by one, including the individual docker containers.