trurl

1) User shares are simply the top level folders on cache and array, the folder name is the same as the share name. Top level folders on different disks with the same folder name are part of the same share. Lots of different ways you might have created a folder for that share on a different disk. Any settings you make for a share only apply to new files, so if you restricted that share to only certain disks at some point, that wouldn't do anything about any files for the share that already existed on other disks. 2) You can just delete the folder for that share from disk1. Do you know any of the several ways to work directly with the disks?

SSDs in the array cannot be trimmed currently. Did you plan on having parity? If so more reasons to not have SSDs in the array. SSDs in the array would be slowed by parity updates, and it is possible that some SSD models could invalidate parity and so wouldn't really be suited for the parity array. Whether or not you have parity, you must have at least one data disk in the array. The so-called "cache pool" is not only for write-caching, and most people keep some things on the cache pool permanently for performance and so array disks won't have to spin, such as dockers and VMs. And current beta allows for multiple fast pools which you can name as you choose, so they won't even be called cache.

Corruption on disk2 and cache and docker image. Go to Settings - Docker, disable dockers then delete the docker image from that same page. Leave dockers disabled until you get your other problems fixed. Then let disk1 rebuild complete and post new diagnostics. Do you have any VMs?

The builtin WireGuard VPN is the simplest way to allow remote access to your server:

There is Help in the webUI. Clicking the Help (?) icon on the main menu bar will toggle help on/off for the entire webUI. Clicking on the label for a specific setting will toggle help for just that setting.

Nextcloud, etc. or possibly simply an FTP docker or plugin. There is also the builtin WireGuard VPN but that might provide more access than you want to give.

And of course, Unraid itself is a virtual host, so you can run VMs in Unraid.

Running Unraid as a VM is not supported, and most people on this forum can't help you with that. But there is a subforum here where people that are virtualizing Unraid help each other. https://forums.unraid.net/forum/46-virtualizing-unraid/

And generally, Unraid will not read/write as fast as any striped system. But many people have chosen Unraid precisely because it is NOT striped. Not striping means each disk can be read independently of any others on any Linux, you can mix differently sized disks in the array, and you can easily add disks without rebuilding the whole array.

Posting the same thing in multiple places makes it impossible to coordinate any responses, so we all wind up wasting time with duplicate responses.

I think based on the rest of your post that you don't really understand docker volume mapping. And the way you have specified paths in your post is ambiguous in one place and very likely wrong in the other. Start with posting your docker run for this container as explained at this very first link in the Docker FAQ:

Or perhaps you need to schedule mover for idle time.

Since you will be booting from a fresh install on another flash, Unraid won't know anything about your disks. But if you reboot from your original flash it will. Everything about your configuration is stored on flash in the config folder. Your original flash will still have that original config folder, the new flash won't. The point is simply to test if a fresh install exhibits the same problems. Or

Should be fine. Anything over 2GB will be more than enough

Yes, which is helpful if you have a slow connection, but just takes extra time to compress/decompress if your connection is already fast. Mostly would be used if transferring files over the internet.

-z does compression, which actually slows things down if you already have a fast connection.

df won't show any disk until disks are assigned, formatted, and the array started so the disk filesystems get mounted. The smart folder in those diagnostics also doesn't show them, which is why I asked if he could see them in the BIOS.

You can put the drives from 2 servers into one server and so only have one server but with all the data.

Mixing disk shares and user shares when moving or copying files can lead to data loss because linux doesn't understand that the source and destination could refer to the same file and so will try to overwrite what it needs to read, resulting in empty files. Mostly I recommend not sharing disks on the network. In fact, if you don't share a disk, it isn't really a disk share, it is just a disk. If you need to work directly with a disk, do it on the server with mc (Midnight Commander) or krusader. And don't work with disks and user shares at the same time. For some things like docker appdata, it can make sense to refer directly to a disk, usually cache. And there are other ways you can get in trouble when specifying disk paths. For example, accidentally creating a user share named the same as a disk, such as /mnt/disk2/disk1. This is a user share named disk1, not even on disk1, since user shares are simply the top level folders on cache and array. But over the network SMB will not show both disk1 and a user share named disk1, so better to not even have disk1 on the network to avoid this confusion.

What is the rsync command? Some options can slow things down.

According to your diagnostics in the first post, the drives were mounted, and had about 8.4TB of data on them. So from diagnostics it isn't obvious anything was corrupt or even lost. But diagnostics can't tell us much about many user actions. This is not at all how anything works in Unraid. Each disk is a separate filesystem. Each disk can be read by itself without any other disk. Each file exists completely on a single disk. And a hard reset is extremely unlikely to cause anything other than incomplete parity updates (and parity doesn't contain any of your data) or possibly incomplete file write if anything was being written at the time. I don't know what you may have done since you posted those diagnostics, but I think 8.4TB of files were still on your disks at that time. According to those diagnostics, those 8.4 TB of files would have been in these (anonymized) user shares: i----s on disk3 w-----a on disk1,2,3,4 And this is how much of each disk was used: Filesystem Size Used Avail Use% Mounted on /dev/md1 5.5T 4.5T 1014G 82% /mnt/disk1 /dev/md2 2.8T 1.4T 1.4T 50% /mnt/disk2 /dev/md3 2.8T 1.6T 1.2T 57% /mnt/disk3 /dev/md4 1.4T 1.1T 336G 77% /mnt/disk4 /dev/nvme0n1p1 1.9T 17M 1.9T 1% /mnt/cache

I recommend not using disk shares at all. Disk shares have several ways to give you problems, including data loss. Just turn off disk shares completely. You can restrict specific user shares to specific disks just as you want to do. Just use the "Include" setting for each user share. And you also get to use cache however you want for each share.

The answer to your question is NO. If you want Unraid to manage some files differently than other files, you put them in their own user share and configure the share appropriately. I recommend not caching anything during the initial data load. If your cache is as small as you say, I recommend not using it to cache user share writes and just save it for VMs and dockers. If you want further advice, post your diagnostics

Not much of this is correct. You can have a maximum of 2 parity disks. New Config will not be needed and should not be done. Replacing a parity disk is like replacing any other disk. A disk can only be replaced with a disk of the same or greater size, and no data disk can be larger than any parity disk. Shut down Replace disk with larger disk Reboot Assign new disk to same slot Start array to begin rebuilding You can replace and rebuild both parity at once, or do them one at a time and so maintain parity protection during the rebuild. You can reuse the old parity disks as you want. If you use one to replace a data disk, the procedure is the same as above. The parity calculation provides the data for the replaced disk, whether replacing parity or data. Or you can reuse a disk in a new slot. Unraid will clear the disk which will make it consistent with existing parity, then you can format it. Please ask for further advice if any of this is unclear, and we can get more specific.