trurl

I guess too. New Diagnostics (or just syslog) might give some idea how much trouble that bad parity disk was causing during that. Did you notice if the ERROR count increased for parity on MAIN - Array Devices? Probably unlikely that ddrescue cloning parity to a good disk would give better results, but we can try if you want. Maybe. We don't know why it failed. It might be expensive to recover if it can be.

The slots dropdown is available for array or for any created pool, but only when the array is stopped, simply because you aren't allowed to change the number of slots in the array or a pool when the array is started. And why would you want to? You can't add a disk to a new slot when the array is started.

That is somewhat better, since now your diagnostics only shows the 34 user shares that actually exist currently instead of the 190 user shares that might have been created as some point. You need to figure out how you are creating all those user shares, fix it, decide what user shares you actually want, and try to consolidate all the data from all those separate shares into the few or several user shares you want. And I recommend not having a user share named 'cache', it appears you may still have that share.

I don't recommend putting SSD as parity or data in the array. SSDs in the array cannot be trimmed, and can only be written at parity speed. SSDs are better in pools outside the array. You definitely don't need 2 parity disks. 1 HDD parity should be good enough for several array data disks. You didn't answer this question:

I don't remember how that works on your version. Post a screenshot.

Something strange about the forum software. I quoted your post then asked for a screenshot, but the part of your post I quoted showed up as text I wrote, and my request for a screenshot showed up as a quote from you. I will try again in my next post.

Probably accidentally created a lot of shares by creating folders at the top level of disks or pools. Maybe used some host path directly on cache, such as /mnt/cache, since there is obviously some confusion going on there. And so some container is creating folders at the top level of cache, which would automatically be user shares. A really big mess, but I think we can simplify it somewhat by simply clicking the CLEAN UP button on the User Shares page. Then post new diagnostics.

You really need to start over with a new array, but we can still save that emulated NTFS data before your do. I don't see any disk being assigned as the new disk1 in syslog. It looks like you may have assigned or reassigned parity2, and it is the disk that was rebuilding. I don't see any disk that might be assigned as the new disk1 in your SMART reports either. Is that disk still attached? Is your parity disk SSD?

Was disk1 originally in a Windows system?

Why are you using NTFS for an array disk? Attach Diagnostics ZIP to your NEXT post in this thread.

don't see a cancel button anymore

No guarantee we can save any of disk2 even if we spend a few more days trying things. But I'm willing to try if you want. Whether or not you decide to move on without disk2, I have some more recommendations to help avoid these problems in the future. Setup Notifications to alert you by email or other agent as soon as a problem is detected. Don't allow one problem to become multiple problems and data loss. I suspect parity and disk2 had been giving you warnings for some time and you didn't notice. And, as mentioned, parity is not a substitute for backup. You must always have another copy of anything important and irreplaceable. You get to decide what qualifies. Parity can recover from a failed disk, but there are much more common ways to lose data that parity can't help with, including user error.

Cloning the bad parity disk with ddrescue would probably take a few days, before we could even try to see if it helped anything.

Probably not an explanation for some of your problems, but Aug 23 19:18:51 Tower root: Fix Common Problems: Error: Same share (media) exists in a different case Aug 23 19:18:51 Tower root: Fix Common Problems: Error: Same share (Media) exists in a different caseThis will definitely cause you some problems accessing the share via SMB since SMB is not case-sensitive and will only access files from one of these. Probably you have accidentally created one of these by specifying the wrong upper/lower case for a host path in one or more containers.

How is it progressing? If it hasn't completed, even partial output might give some indication whether it is worth pursuing. Emulation requires reading parity plus all other disks. And repairing the emulated disk would require writing parity. And as we know, parity is failing. Another approach might be to clone parity to the new disk with ddrescue, and try to emulate disk2 with a "good" parity disk. Of course, that disk might be good, but the parity rescued from a bad disk that might have been out-of-sync anyway means parity would likely be invalid, at least to some extent, maybe a lot. The final approach would be to forget about disk2 data and just use the new disk as parity in a New Config without disk2, and build parity. That would be the fastest and easiest way to move on, but without disk2 data, which we almost certainly can't completely recover anyway.

Are you saying you want to use a USB connected device as a mirror for nvme device? Doesn't sound like a good idea. Is your license still on USB? or TPM?

I neglected to mention that all of your other data disks appear to have all of their data. Filesystem Size Used Avail Use% Mounted on /dev/md1p1 11T 8.4T 2.6T 77% /mnt/disk1 /dev/md3p1 11T 11T 253G 98% /mnt/disk3 /dev/md4p1 11T 11T 152G 99% /mnt/disk4 /dev/md5p1 11T 11T 187G 99% /mnt/disk5 /dev/md6p1 11T 11T 160G 99% /mnt/disk6 /dev/md7p1 11T 11T 187G 99% /mnt/disk7 /dev/md8p1 11T 11T 182G 99% /mnt/disk8 /dev/md9p1 11T 9.7T 1.3T 89% /mnt/disk9 /dev/nvme0n1p1 1.9T 22G 1.8T 2% /mnt/cache

OK, now try again

Your other disks are XFS. I assume disk2 is also unless you know differently. Stop the array, click on disk2 to get to its page, change the filesystem type to xfs, start the array. Then post new diagnostics.

Not something we need to worry about right now, but your Unraid version is more than 2 years old. Why?

I recommend you go to Settings and Disable both Docker and VM Manager while we work through this. OK, emulated disk2 is unmountable. Not surprising. We will have to see if we can repair its filesystem. Check filesystem on emulated disk2 from the webUI. Post the output.

If you mean on the Plugins page, that is normal. CA is accessed from the Apps page. You can also make settings for it on the Settings page.

Attach Diagnostics ZIP to your NEXT post in this thread.

OK, not unexpected on both drives. Let's go ahead and get things configured so you can start the array with disk2 emulated, despite the bad parity disk. That will let us see the filesystems on the other drives, and will give some idea if disk2 emulation is worth pursuing. Follow these instructions carefully and exactly. Connect the new disk instead of the bad original disk2. It still won't let you start the array like that because it is the wrong disk, so we will have to New Config. Go to Tools - New Config - Retain All - Apply. Assign the new disk2 and make sure all other disks are assigned as before. VERY IMPORTANT. Check BOTH Parity Valid checkbox and Maintenance Mode checkbox, then Start the array. This will accept all disks as assigned into a new array, but won't mount any disks so no disks will be accessed. Stop the array, unassign new disk2, Start the array, this time without checking any boxes. This will disable and emulate the new disk2 from parity plus all other disks. Then, post diagnostics and we can take a look at how things are and decide how to proceed.