trurl

That seems pretty drastic. And unnecessary. And if you don't know what has led to the current problems, probably pointless.

Are you sure you aren't filling it up?

The first post doesn't really seem like a feature request anyway, so done.

Don't put it on the internet. If you need remote access Wireguard VPN is builtin. Depends on each user shares settings for how it uses cache. Anything that is configured to stay on cache will get the speed of cache for writing or reading. Anything that is configured to get moved to the array will get cache speed for writing, and will only get cache speed for reading until it gets moved to the array.

The usual way a container would do this is a host path in the mappings that isn't actual mounted storage. Which dockers do your run?

Looks like there are multiple controllers on that motherboard. Do you have any spare ports?

Not possible. If there was a corrupt file, it would be confined to a single disk, and wouldn't affect anything else on that disk or others. Each disk is an independent filesystem and each file exists completely on a single disk. These are hardware problems. Are you sure you have good power to all disks? Do all SATA cables have enough slack so the connections don't have anything pulling on them? Are you bundling SATA cables in attempt to make things "neat"?

User shares are sometimes broken if array or cache disk is unmountable. It is just a symptom of one of the disks included in user shares being unmountable.

Problems writing disk5 and reading multiple disks. How are these connected?

Are you sure the original drive was mountable before you replaced it? If the original disk was unmountable, then if parity and all other disks were in sync, the rebuild would have resulted in the same unmountable contents. Or, if parity and all other disks were not in sync, then rebuild could become corrupt and unmountable. If we still had the original and it was mountable, then we would know something else was the cause of the corruption. Do you do regular parity checks? Do they always result in exactly zero sync errors (the only acceptable result for accurately doing rebuilds). Were there any errors shown in the Errors column during rebuild? Do any of your disks display SMART warnings on the Dashboard page? When rebuilding a disk, what you should see is a lot of writes to the rebuilding disk, and a lot of reads of all other array disks including parity. And zero in the Errors column for all disks.

Your docker.img is corrupt. You will have to delete and recreate it. Then Previous Apps on the Apps page will reinstall your dockers just as they were. Since you allocated 64G to docker.img, I wonder if you have had problems filling it up. 20G should be more than enough. I'm running 17 dockers and they take less than half of 20G. Making it larger won't fix anything, it will just make it take longer to fill. The usual cause of filling docker.img is apps writing to a path that isn't mapped. The most common mistake is specifying a path in an application that doesn't correspond to a container path in the mappings. Linux is case-sensitive, so /download and /Download are different paths, for example.

The easiest thing would be to format, but it might be instructive to try to repair the filesystem to see if you can get the files back. See this wiki: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Since you don't specifically mention it, I have to ask. Did you do this first? modprobe i915

Replacing the disk will rebuild the disk. It doesn't rebuild parity. Whatever was on the original disk should be what is on the replaced disk, but that depends on parity plus all the other disks emulating the original disk for the rebuild. The usual thing to do with unmountable is to repair the filesystem, but if you still have the original disk getting the files from there might be the simpler approach. Do you still have the original disk with all its data?

First thing. DO NOT FORMAT!!! I am reviewing diagnostics.

lost+found is where filesystem repair puts the data for files it can't figure out. Typically these will be difficult to use again, especially if there are a lot of them. The names of the files and the folders they belonged to is unknown.

This sounds like the avenues to pursue

Unraid has had a selection of btrfs raid configurations in the cache pool for some years now: Current beta also allows multiple pools.

Where things start to fall apart with USB connections and/or multidrive enclosures that only give one port for a bunch of disks, is when you have parity. If you are willing to do without parity you could play around with the other features.

Do you have an adblocker or anything that might be interfering?

I strongly recommend not having any user shares with special characters in the name. While not strictly forbidden, it wouldn't be surprising if something somewhere sometime breaks when trying to access {Media}. Move all the files from {Media} into Media and get rid of {Media}.

You could just wait and replace/rebuild that 2TB to the new larger drive. If you shrink the array you are still going to have to do some lengthy process. Either clear the disk while in the array (one shrink method) or rebuild parity without it (the other shrink method) or just wait and rebuild the disk to the new larger disk.

I have merged your threads. Don't post in multiple threads about the same thing, it makes it impossible to coordinate responses. If after a reasonable amount of time you feel your post hasn't gotten the attention it deserves, just "bump" the thread by making a new post in the same thread.

The 1st 3 disks are mounting, there must be something about the controller the others are using that is giving that result. Probably you need to flash that RAID controller to IT mode.

I didn't bother to look at your user share settings. I am guessing they are default because the fact that disk1 is so much larger than your other disks is enough to explain what you are seeing. The default Allocation Method is High-Water. It is the default for a good reason. High-Water is a compromise between using all disks (eventually) without constantly switching between disks just because one disk temporarily has more free space than another. There is Help in the webUI. You can toggle Help on/off for everything in the webUI by clicking the Help (?) button. You can also toggle Help for a specific setting by clicking on its label. Go to Shares - User Shares and click on one of your User Shares to get to its Settings page, then click on the Allocation Method label. Based on the disks you have installed, 12TB disk1 is chosen until it gets to 6TB remaining, then since it still has the most free, it is chosen until it gets to 3TB remaining. Then disk2 will be chosen until it gets to 2TB remaining, and so on. Currently, disk1 still has some way to go before another disk will be chosen. You can adjust the Disk Utilization Warning for specific disks by going to Main - Array Devices and clicking on the disk to get to its Settings page.