Kilrah

Meaning that it should be 192.168.1.0/24, not 192.168.1.2/24. But it probably fixes it in the background.

As mentioned it's the min free space that needs to be set properly on the shares so that it does, to about twice the max file size you might expect to write to them.

Go to Apps-> Previous Apps and remove things you don't want anymore.

Unless you installed the parity check tuning and configured it to allow resuming operations before you started the sync, if you reboot you'll have to start over. Yes, can do everything, just anything touching the array will be slow.

RAIDZ expansion isn't as straightforward as it sounds https://forums.truenas.com/t/raidz2-expansion-how-to-rewrite-data-for-full-capacity-recovery/52707

Where do you see that? 14.3T mentioned there is the raw storage that's currently in use, not the total available size.

This. Never recommended to pass the entirety of /mnt/user to any container anyway as it gives it the ability to wipe your entire server, only pass what you need, do multiple mounts if needed...

That doesn't look right. And no as mentioned the webui will not come up if your VPN connection fails.

Usual reason is your VPN creds/config need updating, need to choose a different endpoint or such.

Verify that this stick has the appropriate Pro.key file in the config folder and no other.

You don't, pools are a single filesystem comprised of all disks (original RAID-type setup), the UNraid array is what's special with each disk being a separate filesystem. From what I can see you were told a couple of weeks ago how to run btrfs commands to remove a disk from the pool.

Yeah, seems it's time to consider this drive dead

Bug tracking has been moved to another platform https://product.unraid.net/b/unraid-os-bugs

Current log shows one occurrence since last boot, all we can see. Seeing the log it seems to be running every 5 minutes if upload is below some threshold. That's way too frequent, restarting either they'll have to check everything when starting which will take a while and increasingly more with more torrents, then it takes a while to find peers and upload to actually ramp up. Might want to check every few hours, not 5 mins. And that's assuming you actually have stuff people want and download from you, if not you might be restarting the container and redoing the whole checking thing simply because there's not enough people who want your stuff for upload to be above the threshold you set. End of the log shows stuff being restarted every 5 mins because of some part of that.

No because the location might not include a ZFS filesystem at the time of creation but one could be added later and it should work. Reread previous post.

You can add a drive to the array at any time and decide it should be ZFS-formatted, and any share should be able to use it as it will by default. So the current status of not allowing any zfs-illegal share names anymore makes sense. OP's setup to have all those things as individual shares is a bit weird in the first place, most people would have a "media" share with those folders inside it, no problem then.

Looks like you have poorly configured checks that keep restarting the qbit and gluetun containers way too often probably for no good reason. Seems the 870 EVO SSD sometimes drops and has to be reset. Your system share has data on disk1 which FCP warns you about, If that's the Docker image/FS that'll slow things down.

As it says, your Docker image is full. Increase size/clean up unused stuff/figure out if something is badly configured and writing into it when it shouldn't.

Looks like CA has been stuck since a couple of days:

You should only need to use the Nvidia Drivers plugin and select the open driver.

No. If you enable reconstruct writes then parity isn't a slowdown as long as there is no other array activity. But using cache is Unraid's solution, you write there and then have it moved to array later when practical. You could also use mergerfs which works this way but obviously it has drawbacks too, there's a plugin for it.

ETA was December. As you can see... didn't work out, which is why there's no point trying to give estimates.

Likely your minimum free space settings on the share in question are set a bit too high. Can use something like Teracopy to queue all ops and then run them sequentially.

Are those copies going to cache or straight to array? What's the source? Parallel copies is never a good thing to do, especially if either the source or destination is an HDD it will always be way slower than doing them one after the other.

No, you click on the "cache" pool name. Array has to be stopped to set min free space on it. Mover tuning is a source of issues more often than not.