Squid

Your docker folder is in the system share. This share is set to be moved to the array, and the files now exist between the array (disk 1 and the cache pool). You really don't want this. Not only (if mover fully succeeds in moving everything to the array) is there a huge performance hit in running docker from the array, but in terms of when only some files can be moved (which is to be expected since docker always has files open and mover can't move in use files) it's probably going to play havoc with weird things happening. What I'd do. Stop docker service in Settings, Docker In advanced view, check off and delete the folder From Shares, system settings set the Use Pool setting to move from the Array to the Cache Pool (ie: use cache: prefer) From Main, Array Operations run Mover (Move Now) Settings, Docker -> re-enable the service Apps, Previous Apps -> check off what you want re-installed and hit the "install x apps"

Which containers? When editing them is the repository something akin to https://ghcr.io/ blah blah There's been some reports that ghcr (GitHub Container Repository) has been reporting incorrect SHA values on containers which does result in what you're seeing.

The entire GitHub repository has been deleted by SmartPhoneLover, so none of the templates are available and have been removed. Because of that, you're probably also not going to get any support / answers via this forum, especially from the maintainer

You don't need the "-e " in any of those variables. It's implied already since you're creating a variable and what you're do is creating a variable named "-e variablename" instead of "variablename" Unless you're running the container on its own dedicated IP address (network: br0) then the host port you've specified of 443 is already in use

Did you start the array with Parity 2 removed? If you did, then it's natural that it has to rebuild the contents of Parity 2 when you've re-added it.

Wouldn't have been the issue

To re-enable a drive that was disabled (eg if the drive dropped offline and reseating the cables is the probable solution) Stop the array. Unassign the disabled drive. Start the array. Stop the array. Reassign the drive. Start the array. A parity build will result and rebuild the contents of the drive.

What was the name of the share? (Diagnostics are anonymized so we can't really tell). But almost without fail loss of data is result of user error. (Inadvertently deleting the share contents or telling Sonarr to delete the contents)

It should. Most causes of this degradation would be Plugging the cable into a 100MB/s switch or a bad cable. Post your diagnostics if changing the cable doesn't help

Maybe the slots are disabled. Seems like the PCIe lanes are extremely limited https://forums.servethehome.com/index.php?threads/topton-nas-motherboard.37979/#post-354365

It should show up in Main as either disabled with the drive. Stopping the array should also show you the same things

Settings - Network settings. You will need to stop Docker and VMs (Settings - Docker and Settings VM Manager) to make changes

Is it disabled in the BIOS? You might need the dummy plug....

Can you repost your diagnostics after you start the array. And also ideally after plex crashes.

What is the name of the share? On the shares page do you happen to have a "music" and a "Music" share (same name only differing by case)? Post your diagnostics.

Its a call trace. First thing to do would be to run memtest from the boot menu for minimum of a couple of passes (If you boot via UEFI, then you will need to temporarily switch to legacy boot in the bios) After that, try seeing if another flash drive set up with the OS will boot

You should post your diagnostics.

Are you passing through a USB controller to a VM?

Primary support venue for those containers is via the Discord link. If you don't see it via the drop down on the docker tab when clicking it's icon, you can get it via Apps, Installed Containers from it's card

FWIW, you can attach diagnostics directly to the forum. Most people don't like hitting random websites to get them. But, can you try setting DNS servers of something other other than your gateway. EG: 208.67.222.222 and 208.67.220.220. (Settings - Network Settings)

Reboot or from a command prompt rm -rf /tmp/plugins/pluginPending But for the root of your issues, you need to post your diagnostics

Network issues? Bad Cabling?

That entire GitHub repository was deleted by the maintainer / author, so what you're seeing is correct and to be expected (and also why the apps are no longer within Apps). Use a different URL.

The only TinyMM within Apps is CLI only based upon the description. Also, what you may have had installed was unsupported and experimental and was removed from CA about 1.5 years ago

That's what you need to fix first. After this happens again, post your diagnostics