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.