trurl

You have a problem with your memory. Try reseating it.

Post your Diagnostics too

The Console option gives you a bash command line inside the container, so that is all you need.,

Try booting from another USB port, preferably USB2.

Assuming you updated Unraid, it might be necessary to make a change to the schedule just to get the old bad schedule cleared.

Since that plugin installs a custom build of Unraid your report doesn't belong here. Try to reproduce on the actual Unraid release this report thread is about.

It would only be necessary to add if you were NOT logged in as root since normally root is the only user with access to the command line.

Still don't see anything. You aren't trying to overclock are you?

Diagnostics?

Diagnostics?

The disk isn't producing a SMART report in those diagnostics. How is it connected? Also, a lot of UPS disconnections happening in your syslog. Any idea why?

Why are you doing a parity check anyway? Most people just schedule a parity check to run once a month. Unraid parity is realtime so should always be correct. A parity check is just intended to be an occasional test that parity is still correct.

Parity check requires reading all the disks. Parity check and any other process trying to access those disks will be competing with each other, with the result that the disks often have to "thrash", moving the read/write heads and waiting for the disk to spin, as it seeks the sectors one process is using, then seeks the sectors the other process is using, then etc.

That problem is sort of the compliment of the other problem being mentioned earlier, mixing disks and user shares when moving/copying. If you move/copy from a user share to a disk, or from a disk to a user share, Linux doesn't realize that the source path and the destination path might actually be the same file. So it tries to overwrite the file it is trying to read.

Linux sees all user shares as being mounted at /mnt/user. So when you try to move from one user share to another, Linux will see they are on the same mount, and instead of copying from source to destination and then deleting from source, as it would if you were moving between disks, it will instead just rename to a different path. This is instantaneous but it stays on the same disk, not the result you wanted. You will have to do the move in 2 steps. Copy from source to destination. That will make another copy that follows the user share settings of the destination. Then delete it from the source.