Squid

Another thing to bear in mind is that with 6.10, parity checks are automatically throttled if access to the array is detected (this is a good thing)

That vid is running on OS 6.8.3 which pre-dates the introduction of the readmore

Your load average is absolutely insane (110) That number would be ok if you had a minimum of 100+ cores on your system, but on 40 cores the system is massively bogged down. Nothing really pops out on what's doing it, so reboot right now and close any other browsers / tabs open to the server

Are the icons for the containers showing "?" or the actual icons?

Mover adds in ".partial" during the move to solve various problems that users have on occasion This makes your filename too long. Right now, your source is 255 characters on the filename itself. This is the maximum length of any filename. I'd simplify your naming convention that you've got (presumably) sonarr naming the file to. It seems to be a tad much, having both the [S01E12] and the episode # 012 separate, along with all of the file info x264, audio etc in the filename itself when usually it only needs to be done in the associated .nfo file unless you want to see at a glance everything about the file.

It does when creating a share via the GUI. However there are numerous ways to not do it via the GUI (as you saw, the docker path), and that can't be caught. Hence the FCP tests

I have always seen this, on every server and every OS version/ For the first min it's slow and then gets up to speed. Doesn't bother me because it always picks up to the max and it's the average time and speed when it's done that's important.

Have you let the parity check run for a couple of minutes (The snip shows it ran for 7 seconds)? What you're seeing is basically normal and the speed should be more or less identical after it all levels out and calms down.

Simply Apps, Previous Apps and check stuff off. No renaming etc needs to be done.

Without know what command you actually used, it's hard to say what happened here. It's extremely unlikely that if the command was correct and structured to properly move from one UD disk to another UD disk that data loss would have occurred. OTOH, what ever command you used wound up putting it into RAM and it is now lost after rebooting.

How many parity drives did you have? Assign all the drives as data drives and start the array. The ones which come up as being unmountable were your parity drive(s). Assign the drives accordingly. If you had 2 parity drives, then flip a coin between which is which and run a non--correcting parity check. If there's tons of errors, then flip the assignments arround. If more drives come up as being unmountable than you had parity then don't do anything (especially, do NOT format) and repost diagnostics and wait for the file system experts to pipe in. While there may not be much you can do with regards to IT / IR firmware, this is basically why IR firmware isn't recommended to use for Unraid (or any software raid system like ZFS)

Everything says that it's full, except for the script (not sure why though). Rebooting is your only recourse, and then see if it happens again.

controlR may be a viable alternative

Plex doesn't appear at first glance to be running in those diagnostics. Are you sure that it's not starting and then immediately stopping (a reload of the docker tab would show that it's stopped in that case)

Yes

SATA connections are by design and definition terrible. It doesn't take much for them to lose connection (or have an intermittent connection). Probably when you replaced disk 11 you slightly jarred disk 9's connectors. Reseat them (and power), minimize the usage of any power splitters, and do not tie strap cabling trying to make things pretty

Which VM (there's 5 xml's in the diagnostics)

The docker run command will show you exactly why that error is coming up

I'd be absolutely shocked if LSIO bundled xmrig with any of their containers. It was because you opened the port over the internet to access the UI, at which point a script kiddie just gained access rather easily, especially if you have no passwords set. You should use a reverse proxy or something like Wireguard or the like if you need to access the UI's. Then there is security.

Delete the .txz from /config/plugins/snmp (or whatever the folder is) Reboot If the .txz does not re-appear in the folder after rebooting then the author now knows why its failing to reinstall on a reboot.

Doesn't really look like you deleted it. (BTW, no reason to ever really make a backup of it) Settings - Docker Set the service to be disabled Delete the image (check box) via the GUI Re-enable the service Apps - Previous Apps, check off what you want back installed and hit Install x Apps

Well, what do you expect when you pull out the flash drive in the middle of booting? The flash drive has to remain connected at all times. How is that an issue preventing you from using the OS?

Known issue Fixed next release

Yup. Its a valid configuration. You can assign all the SSDs to the array (and one as parity), but you lose trim support. Assigning them to a pool (or several pools) you'd use them either as a single drive, or BTRFS / ZFS (via plugin) to maintain redundancy and keep trim support