trurl

Just some advice about using the forum. Since you actually did make another post, this thread showed it had new content. If you had only edited the first post to add your diagnostics, I would not have known there was anything new to see. That is why I said

You can check the filesystem on any disk using the same method you used before. Other than that don't know what you mean by a "scan". There isn't any database of your files or anything like that, there are just folders and files.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. Diagnostics contains syslog, SMART for all attached disks, and additional information about your hardware and configuration.

If your current flash is working I suggest not replacing it with a "better" one. Better in what way? You can only get one replacement per year, why waste it? If it ain't broke don't fix it.

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?