Squid

/config/go on the flash

Certain combinations of CPUs / Motherboards / OS and/or a toaster that's either too light or too dark and never quite right will issue an MCE when initializing the CPU cores. This is what's happened to you and can be safely ignored.

You should post your diagnostics when this happens. Also, a complete memtest would be a good thing (ideally a few passes)

<Changes>....</Changes>

Try removing the entry as a test

DNS_SERVER1="192.168.0.100" What is this IP? Make sure that what ever it is is "whitelisting" any requests from the server... Side note, assuming you're using something like piHole to get rid of ads, there's zero reason to use it for the server, as there's no ads anywhere within it.

Definitely agree that management of a loopback image is easier. But, outside of the share requirements on a folder, (and that it can't be moved), there are a few pros for the folder. Not that I have any of the "issues" associated with an image, but the option is a good thing to have. And many of the cons for each approach (storing infomation within the image / folder thats not part of the container) affects each method equally.

Make sure your BIOS is up to date. Also to be aware of is that your processor was released in 2013 and may (or may not) actually have proper IOMMU support that works properly. But, TBH with only 8GB of RAM your ability to run any VMs with passthrough is going to be severely limited anyways.

Failing that, try this https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-713741

Chrome and other password managers will remember credentials for you. And nothing says it has to be a complex password

Setting up a password for root is now required for SSH access

You don't need a script to do that. Edit the application, and simply add that to the extra parameters (in advanced view)

Since you mentioned these 2, you probably have nextcloud set to use mariadb. Since you would do that within nextcloud by specifying the IP address of the server (along with the applicable port), its to be expected that the containers wouldn't work if the server's IP changed. Either adjust the settings within the container's UIs, or adjust your router to use the previous address pool as before (and assign static IPs to the server via the router)

False. BTRFS is the default file system for the cache drive because the system allows you to easily expand from a single cache drive to be a multiple device pool. If you're only running a single cache drive (and have no immediate plans to upgrade to a multi-device pool), XFS is the "recommended" filesystem by many users (including myself) The docker image required CoW because docker required it. Think of the image akin to mounting an ISO image on your Windows box. The image was always formatted as BTRFS, regardless of the underlying filesystem. IE: You can store that image file on XFS, BTRFS, ReiserFS, or via UD ZFS, NTFS etc. More or less true. As said, you've always been able to have an XFS cache drive and the image stored on it. The reason for the slightly different mounting options for an image is to reduce the unnecessary amount of writes to the docker.img file. There won't be a big difference (AFAIK) if you choose a docker image formatted as btrfs or XFS. But, as I understand it any write to a loopback (ie: image file) is always going to incur extra IO to the underlying filesystem by its very nature. Using a folder instead of an image completely removes those excess writes. You can choose to store the folder on either a BTRFS device or an XFS device. The system will consume the same amount of space on either, because docker via overlay2 will properly handle duplicated layers etc between containers when it's on an XFS device. BTRFS as the docker.img file does have some problems. If it fills up to 100%, the it doesn't recover very gracefully, and usually requires a delete of the image and then recreating it and reinstalling your containers (a quick and painless procedure) IMO, choosing a folder for the storage lowers my aggravation level in the forum because by it's nature, there is no real limit to the size that it takes (up to the size of the cache drive), so the recurring issues of "image filling up" for some users will disappear. (And as a side note, this is how the system was originally designed in the very early 6.0 betas) There are just a couple of caveats with the folder method which is detailed in the OP (my quoted text). Cache only share. Simply referencing /mnt/cache/someShare/someFolder/ within the GUI isn't good enough. Ideally within its own separate share (not necessary, but decreases the possibility of ever running new perms against the share) The limitations on this first revision of the GUI supporting folders, that doesn't make how you do it exactly intuitive. Will get improved by the next rev though. Get over the fact that you can't view or modify any of the files (not that you ever need to) within the folder via SMB. Just don't export it so that it doesn't drive your OCD nuts. There is also still some glitches in the GUI when you use the folder method. Notably, while you can stop the docker service, you cannot re-enable it via the GUI (Settings - docker). (You have to edit the docker.cfg file and reenable the service there, and then stop / start the array)

Let it go. Afterwards, run an extended SMART test on the drive. It's basically the same thing as a single pass pre-clear.

No. Diagnostics *might* help

The kicker that I've found though with x.265 isn't that the hardware can't decode it. It's that the hardware can't decode it if the bitrate is very high and it's x.265. (ie: Full 4K blu-ray mkv's that are 60-80GB)

To expand on my quoted text in the OP, this beta version brings forth more improvements to using a folder for the docker system instead of an image. The notable difference is that now the GUI supports setting a folder directly. The key to using this however is that while you can choose the appropriate share via the GUI's dropdown browser, you must enter in a unique (and non-existant) subfolder for the system to realize you want to create a folder image (and include a trailing slash). If you simply pick an already existing folder, the system will automatically assume that you want to create an image. Hopefully for the next release, this behaviour will be modified and/or made clearer within the docker GUI.

I am LSISAS2116: FWVersion(20.00.07.00), Not the expert here, but my understanding is that the maximum length for the cables (~33ft) is only valid if you're actually using SAS drives. If you're using SATA drives, it's more like 3.3ft HPA doesn't make the system incompatible with unRaid. It's simply where the BIOS decreases the maximum size of the hard drive to store a backup of the BIOS. Only a real issue if the BIOS decides to put it onto the parity drive. Doesn't affect anything if its on a data drive. And, if it's present then it's also easily removed.

Advanced view top right and the edit should appear.

I don't have an answer on that. Googling that error suggests that the issue only happened on really old versions of tar. I did just restore my appdata 2 weeks ago and didn't have any problems.

Post your diagnostics

6.9 beta 22 its integrated

One of the ACS override options in VM settings

I've seen it lots of times in diagnostics. I think at one time it was automatically created in the cfg file