Squid

/dev/sdb1 512M 436M 0 100% /mnt/cache Looks like the root of your problem is that the cache pool while it may be on a 120G drive thinks that it's a 512M device. @JorgeB is the one to wait for to advise.

What happens if you manually hit apply update on one of them?

Never watched it during a parity check to see where it winds up. But, when it is zero then it is done...

Can you reply back with your diagnostics

Mar 11 20:52:44 TowerShowers kernel: BTRFS info (device sdc1): bdev /dev/sdc1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 There's some corruption on one of the members of your cache pool. First thing to check would be to run a memtest for a couple of passes from the boot menu as most causes of corruption are memory related. After that, wait for @JorgeB the resident BTRFS guru to advise further

what do you mean by this? Transferring from another system to the server, or downloading something via SabNZBD?

rename the wireguard folder (in /config) on the flash drive to something else as a test

You need to post your diagnostics. Grab them AFTER both of those problems occur before you reboot

MCE's you need to post your diagnostics The edac message is informative and doesn't actually mean anything

I can't replicate that

Docker - Container Size will show you mostly where all the space it being taken up

You can also try running make_bootable on the flash drive via windows (run as administrator) What you need to backup and move to the new flash if necessary is the contents of /config

Assuming that the proxy.cfg file for CA is setup correctly, does changing the line instead to be $jsonPage = download_url("https://registry.hub.docker.com/v1/search?q=$filter&page=$pageNumber"); fix it?

Depends upon your point of view and boils down to semantics. The patch doesn't fix any bug or anything like that. It's restoring the behaviour that everyone is used to. It "corrects" how the user set up their template to ignore what docker now calls an error (fatal), by skipping over the offending path. On the other POV, it's hiding the template error by skipping over the offending path. As @itimpi states, if you don't want this plugin, then don't install it. But, every future release of the OS has this patch included anyways, so it's basically irrelevant anyways.

Because it's a very common error that users made in the past. And the result of that error is that everything would have been working perfectly forever, but under 6.12.8 simply updating the container that had the error the user made in the template would result in the container disappearing altogether (not simply stopping / or refusing to start) Far easier to simply have the patch (and all future versions of the OS) to "correct" the template error automatically so that effectively the operation of 6.12.8 and pre 6.12.8 are identical. This process is identical to the philosophy that the entire management of the App ecosystem on Unraid has. Certain errors that are commonly made by the maintainers of the templates themselves are automatically corrected (and flagged) so that the end-user has the least amount of problems. The alternative of not correcting what this patch is doing (and the aforementioned template errors by maintainers) would result in a support nightmare.

I leave everything spinning 24/7. Very slight increase in power consumption vs spinning them down, but like everything else in the world the path to longevity on anything is to never turn them off. I've got 10+ year old 3TB consumer grade drives still without any issues running. Very frequently accessed files I leave on nvme cache-pools. For backup / redundancy on them, its all done to a cloud server.

Feb 19 06:45:52 Saber kernel: mce: [Hardware Error]: Machine check events logged Feb 19 06:45:52 Saber kernel: [Hardware Error]: Deferred error, no action required. Feb 19 06:45:52 Saber kernel: [Hardware Error]: CPU:1 (19:21:0) MC17_STATUS[-|-|MiscV|-|PCC|-|CECC|Deferred|-|-]: 0x8b48504155000044 Feb 19 06:45:52 Saber kernel: [Hardware Error]: IPID: 0x0000000000000000 Feb 19 06:45:52 Saber kernel: [Hardware Error]: Bank 17 is reserved. Feb 19 06:45:52 Saber kernel: [Hardware Error]: cache level: RESV, tx: DATA It's being deferred right now (whatever that means). Probably safe to ignore. I'd reboot to see if it re-appears before you hit Ignore in FCP

That message is informative and a tad misleading. The module is being used.

How are they plugged in / connected?

Are you talking about DS_STORE files or something like Apple Doubletalk files?

As mentioned above, Most Free is terrible for cache enabled shares once multiple drives are basically equivalent in free space. This is mainly because of how Linux caches the writes. Since RAM is used as the buffer, and writes to drive 1 won't interfere with drive 2 then you'll wind up with multiple drives being written to simultaneously and with parity it takes a huge hit, whether not not reconstruct write is enabled in disk settings. High water is the ideal setting to use for all cache-enabled shares.

Does booting via safe mode in the bootmenu work for you?

5 Reallocated_Sector_Ct PO--CK 098 098 010 - 2272 2272 reallocated sectors is over my comfort level by a significant amount and should be replaced. Drill out the cover screws so you can get the cover off and you'll have some nice new wall art for your house.

You need to make the "Cache" share the reverse. Primary is Cache pool, secondary array and mover action move from pool to array. But, if you have trouble (system tells you its an invalid share name when editing the share), then you need to manually rename the folder at the command prompt - As far as I know, a share named "Cache" is technically not allowed since there's a cache pool named "cache"

Technically, you should actually run the memory at 2133MTs not 3200. 2133 is the actual speed of the memory https://www.gskill.com/specification/165/326/1562840073/F4-3600C16D-16GTZNC-Specification, and anything over that is an overclock and all overclocks introduce instability.