trurl

Might also be useful to see if physical disk5 will mount as an Unassigned Device, but we can decide on that later. Hopefully someone else will chime in with some idea what to do about disk6, maybe its problems are preventing disk5 from being emulated accurately.

Better plan, check filesystem on emulated disk5 and on disk6, then rebuild disk5. Your plan won't work as stated, some details missing. For one thing, you can't move any data from the unmountable emulated disk5, it won't mount without repairing the filesystem. Whatever you do, you can't remove it from the array without New Config/Rebuild Parity. And why do you think you want to zero it outside the array? Zeroing it while still in the array might make sense so you can remove it with New Config without rebuilding parity. In any case, doesn't look like there is anything wrong with either disk, just connection problems. In fact, disk6 has disconnected and is now an Unassigned Device. Except, there is this with disk6 Jul 29 19:59:41 Tower kernel: unraidd1: attempt to access beyond end of device Jul 29 19:59:41 Tower kernel: sdj: rw=0, sector=3910720624, nr_sectors = 8 limit=0 Jul 29 19:59:41 Tower kernel: md: disk6 read error, sector=3910720560Not sure how to proceed with that. The disk that was assigned as Disk6 is now Unassigned Device sdl instead of sdj. What do you get from command line with this? fdisk -l /dev/sdl

In MAIN - Array Operation Stop the array. Check the box for Maintenance mode. Start the array.

Create a support thread and request it be moved to Plugin Support.

Go to this link in the documentation: https://docs.unraid.net/unraid-os/getting-started/what-is-unraid/ then expand the Software-defined NAS section, then expand the How Parity Works section below that.

Only array disks use the parity disk so cache or other pools has no bearing on parity. If you mean you will have 4 or fewer data disks assigned to the array, a single parity drive is sufficient. Single parity can be used with as many disks as you want to put in the array. Single parity allows a single disk to be rebuilt from all the other disks in the array. Dual parity allows 2 disks to be rebuilt at the same time from all the other disks in the array. Neither parity contains any of your data, it just allows the data from a missing disk to be calculated by reading parity plus all other disks. Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. If you don't allow a disk to go bad without knowing about it and taking care of it, then maybe consider dual parity if you have 8 or more data disks in the array. Be careful with connections when replacing disks, that is by far the most common cause of problems when rebuilding. As you can see from the output of that command, your ntfs cache does have 2 partitions. After you get everything off the nvme, click on it to get to its page so you can erase its partitions before reformatting it.

In fact, I would say dual parity doesn't really add any additional redundancy when there is only a single data disk. Also worth saying in case you have some misconceptions - parity is not a substitute for backups.

I personally wouldn't bother with all those small drives. They don't add significant capacity, and default highwater allocation won't choose them for writing until disk1 has used 10GB

Also would be useful to know if your ntfs drive has multiple partitions. What do you get from command line with this? lsblk

Not really your problem or even wrong, but why do you have dual parity when you only have a single data disk? Single parity should be enough for several data disks. Not clear there is anything wrong with user shares, but I don't recommend ntfs for assigned disks, even though they are allowed. Maybe that is causing some problem for user shares. See if you can move everything off cache and reformat it as one of the more "native" Unraid filesystems - xfs, btrfs, zfs. Nothing can move open files, so you will have to disable Docker and VM Manager in Settings before you can move their related shares - appdata, domains, system - off cache. And leave them disabled until you get cache reformatted and those shares moved back to cache.

I'll let someone with more btrfs raid expertise help with your problem, but I thought I would comment on this: Only use reliable drives in your server, not just whatever you happen to have. In order to reliably rebuild a drive, Unraid must be able to reliably read all other drives in the array. So, a drive that isn't reliable could potentially compromise your ability to recover a different drive. Also, I always say, each additional drive is an additional point of failure. Use as many drives as required for your current needed capacity, plus some spare space. Don't fill up you server with drives just because you can.

Start the array in normal (not maintenance) mode and post new diagnostics

https://forums.unraid.net/topic/79530-support-ich777-gameserver-dockers/

Check filesystem on emulated disks 1 and 5 from the webUI and post the output.

You should always make sure your plugins are updated before updating Unraid. Remove Community Apps and install the latest version.