strike

It's because you're using docker folder instead of a vDisk. If you want to change to a vDisk image, you need to change that in Settings> Docker

No, I'm not saying that. I'm not using Pi-Hole myself right now, so I haven't tested it, but you're probably right in what you're saying. If you did the research, I'm taking your word for it :) It makes sense. But I still recommend installing it on a pi or something, especially if what you're saying is correct.

My server is also on 24/7, but I do take it down for updates and maintenance pretty regularly (at least every 2-3 months). And sometimes when you least expect it, it stays down for a while for whatever reason.

Usually, there's only one official template for a container image. But almost all templates are made by unraid community members. There are also a few app developers who use Unraid and create the templates themselves, but most official templates are created by Unraid members who have no affiliation with the author of the app. This is just to make them easily available in the app store. So there can be many templates for a container, but usually only one official. Like @tjb_altf4 said, Official just means that it's using the official image the author of the app made.

Usually, you'll find a support thread for a container on Unraid, but some template authors just link to the official support channel for the app. But in your case, you should post in the binhex thread already mentioned if it's an issue with outdated variables, as you said.

It gets stored in the docker.img file. I would delete the container and select to delete the image (the container image, not docker.img) as well, then reinstall with the correct volumes. If you already did this, then you're good.

UD should be able to format to NTFS now, I believe. Or just do it in windows.

You need to change the name of your current container first, then you can install the same container again. Or if that app has multiple authors, you can just choose a different author of the same app, so you don't need to rename your current container.

I have the Intel i915 SR-IOV and the Intel GPU Top plugins installed.

This patch is not for keeping the driver up to date, but to remove transcoding restrictions on consumer cards. Consumer graphics cards are locked at 2-3 transcoding streams (IIRC). With this patch, you can have unlimited transcoding streams. So if you need only 2-3, then sure, remove it. If you need more, keep it.

Try this new container: https://forums.unraid.net/topic/194313-support-containernetwork-autofix-cnaf-auto-fix-vpn-dependent-containers/

It looks like at least 4 of your shares are using split levet to split at the top directory. The way split level works is that it tries to keep files and folders together based on your split level, at all costs, even if there's no space left. So plit level setting trupms everything. So either relax your split level or install the disk space management plugin to let it automatically keep your disk space above a certain threshold, to always leave space for new files. So you can keep using the split level you want. It will move things to the disk with the most free space.

I would use SFTPGo, it has a webclient. That + a reverse proxy and/or tailscale will give you access from anywhere with a browser. You can set up how many shares and users you want. For the most secure access, use Tailscale. Which, of course, requires each user to install Tailscale. If that is not an option, just set up the reverse proxy, and they can access it with just a browser. SFTPGo has pretty nice security features on its own, which blocks unwanted access if you decide to make it public. You can create a white list, block after x amount of login attempts, etc.

Go to settings->Docker and delete the docker.img file.
If mover won't move the files off the cache drive, do it manually from the file manager in the web ui or use Midnight Commander (mc) in the terminal. I personally prefer mc. Overwrite any existing files.
When everything is moved, go to settings->Docker again and start the docker service, it will recreate the docke.img file. If you want it on the array you need to change the location first.
Go to Apps -> Previous Apps and reinstall all your containers.
But why do you want your docker containers running on the array anyway? Performance will suffer, it's highly recommended to have it on the cache drive.

Yes, the array will operate as normal when upgrading drives.
If you want you can upgrade both drives at the same time, BUT not recommended since you're unprotected if a drive fails during the rebuild. So upgrade one at the time. You'll have to do two rebuilds, but as mentioned the array is operational during the rebuild so there's really no downtime. It could be wise to minimize writes to the array tho, as writes to the array will slow down the rebuild. But if it were me I wouldn't care about it and just run the server as normal. It just takes a bit longer, but hey, who are we racing anyway?? :P You have extra protection in the second parity drive so no need to rush it.

And preclear won't help when upgrading parity drives, it only helps on data disks.

Yes, you just won't have any parity protection. You'll have to do tools->new config and reassign all the drives except the parity to remove it from the array.

I don't see what I'm missing. The script does that too.. This is from the hdparm manual:

-S Put the drive into idle (low-power) mode, and also set the standby (spindown) timeout for the drive. This timeout value is used by the drive to determine how long to wait (with no disk activity) before turning off the spindle motor to save power. Under such circumstances, the drive may take as long as 30 seconds to respond to a subsequent disk access, though most drives are much quicker. The encoding of the timeout value is somewhat peculiar. A value of zero means "timeouts are disabled": the device will not automatically enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

SO then you set the first script with a value 0 and in the unraid disk settings you set never spin down. and run it at 7am. Disks will not spin down until you run the second second script (at 1am? or something) with the correct value that (whatever value 15 min is, do the math yourself). 

I will just link this post by another user in another thread, so I don't have to write it all myself, as it was just about this  
 

You have a upper case A in "AgentDVR" in your webui, but in the mapped path you have lower case a. Linux is case sensitive so in essence they are two different paths. And the upper case path is not mapped to anything so it puts it in the docker image.

You can start the array as normal and the missing drive will be emulated and you will have access to all of the data. But if one more disk fails before you replace the missing disk you will lose all the data on that drive.
 
If you have backup you can just use your array as normal, if not and you have important files you can not lose, do a backup ASAP. 
 
 
 
 

Have you enabled "host access to custom networks" in the network settings? Or it could be in the docker settings. 
 
Sure, just hook up a monitor to the server and boot in gui mode. 

Nice. I can't think of any downside to doing it that way, if it works.

Exactly

Scrutiny will do that for you  It's not a plugin, but a docker container.

I think I figured it out. There must be something wrong with my cache pool. I deleted my docker image again and changed it's location to another ssd pool. 23 containers installed in under 20 min compared to 2 hours on my cache pool. I'll have to do some speedtest on my cache pool as all my appdata and downloads go there. Either it's the drives themself or my HBA. One of the pools is on my MB SATA connections I just don't remember which one. So it could be my HBA since the mover acted up as well. I ran the mover again manually earlier today and then it was fine. This was before I moved the dockerimage.

Install adminer

Then I assume you didn't run the docker safe permission tool? Docker containers usually have very specific permissions for each container. I honestly don't know how to fix that. You could try to disable the docker service, delete the docker image, recreate it then install all your apps again from previous apps section. Takes about 10-20 min depending on how many containers you have. If that don't work you can check if you can reset the permissions for each container. Some container have a permission file you can just delete and it will recreate it with the correct permission. If they don't have such file you probably need to check with the container author what the permissions should be. Or you may have to delete the appdata and set it up from scratch.

You can change it back by ssh into your server and run this command 
use_ssl no