Squid

Can you redact that file and post or PM to me?

Disable Int13h is the HBA's bios (if it's not specifically labelled as disabling boot, this the option you're looking for)

First thing to do is ensure that /data exists as a mapping on NzbGet (and sonarr / radarr). Then restart the containers and see what happens....

The current RC in private testing has 20.10.9

What is the "mainpool" you have? Is this a ZFS mount? Admittedly I don't really follow the ZFS threads, but it really should be mounted outside of /mnt (ideally it should go into /mnt/disks/...) Mounting a zfs pool within /mnt might explain some of the other weird errors that are appearing For the actual problem at hand, several users have reported that when they put the docker.img onto a zfs pool issues result. The fix in that case would be to instead of an image you use a docker folder (settings - docker) instead. This change will result in you having to re-install the apps via Previous Apps (5 second process)

Absolutely, because I could only stop a backup if a parity check is in operation prior to the beginning of it, and can't do anything once it starts and I'm not sure that postponing a backup is a wise thing to do.

if either of these files exist /tmp/ca.backup2/tempFiles/backupInProgress /tmp/ca.backup2/tempFiles/restoreInProgress

It should get cleared from the image on a restart

Most likely it's the Plex transcode directory. One of Plex's quirks / bugs / "features" is that it doesn't delete it's temporary transcode files until playback stops or it actually runs out of space. Basically if you're watching a movie, then the transcoding stays in place taking up space. Map /transcode to a folder outside of the image and make sure that Plex's settings say to use /transcode (I'm not a fan of transcoding to RAM because then you're taking away ram from the system that may impact the rest of your processes, unless you've got gobs and gobs of ram to spare)

Unraid is not designed to be directly facing the internet. Remote access if required should be done via a VPN (WireGuard) or a reverse Proxy (MyServers).

Can you post the docker run command?

It's not an issue of whether its supported or not, but whether or not it can detect the appropriate sensors (which it probably can't). Hence why the plugin has this note on it The various methods of forcing id's on a modprobe etc are quite outside of the author's control, and effectively impossible to know what to put into the command without performing the research on google and trial and error.

Remnant from when you used to run the PhAzE plugin. Delete that entire folder (plugins/plexmediaserver) on the flash drive. I'm not going to do a release on FCP to handle a plugin that hasn't existed for years

It looks like you've rebooted after seeing that, which means it can't be discerned where it was actually running from How is 4433 being run through? Is this via a VPN or a reverse proxy? Simply forwarding that port without the use of a VPN / reverse proxy (eg: the MyServers plugin) only leaves your system protected by a password

Just post back your investigation results.

By and large, CRC errors are caused by the connection to the drive (or the backplane) and is not a problem with any hardware itself per se. Reseat the cabling both ends, avoid tie-strapping the cables (cable management by definition is terrible for cross talk). Avoid at all costs power splitters as they are all terrible quality. Replace cabling as necessary

You should post your diagnostics and one of the btrfs gurus will be around to look at it in due time

NO Do the port forwards on the xfinity and don't do any DMZ (the extender does not create it's own isolated network).

The error is ultimately because you can't passthrough anything in an IOMMU group unless all devices are passed through (and you should also click the checkboxes to isolate them from the OS) The ACS override options are to try and get the device you're attempting to passthrough into it's own group where it won't interfere with other system devices At the end of the day, onboard sound / audio passthrough can be challenging because they don't "conform" to the same standards of add on card, and you may not be able to do it successfully.

Which ever gets you back to 6.9.2 Alternatively you can always download the zip file from the webpage (downloads) and extract all of the bz* files from the zip and replace them on the flash drive and reboot.

By and large the vast majority of crashes are hardware related. Never hurts to run a memtest from the boot menu for a few passes (boot into Legacy mode if you're currently using UEFI) Also, if you happen to be using Docker apps and assigning them a static IP Address, then you should probably upgrade to 6.10-rc2+ and set the network driver in Settings - Docker to be ipvlan instead of macvlan

It restores the OS and doesn't touch any config file at all. AFAIK there's no problems with the cache pools on a reversion from 6.10 to 6.9 Worst case scenario is that you reassign the pools. The only issue I can see is if you were using ipvlan instead of macvlan on docker containers as ipvlan doesn't exist on 6.9

You have mirror to flash enabled and looks like you're running into a size limitation. Disable mirror to flash in syslog settings (and delete the file on the flash) It really should only be enabled on an as-needed basis. Fix Common Problems should have been notifying you about that.

Tools - Update OS, restore previous version. Nothing has particularly changed