trurl

FYI Diagnostics already includes SMART for all connected drives. No need to post them separately.

That last diagnostics was taken without the array started in normal (not maintenance) mode, so can't tell anything about filesystems since they aren't mounted. Start the array in normal mode and post new diagnostics

Some applications have a way to set umask in their user interface, NZBGet for example. Others may have a setting in one of their appdata files, transmission has a umask in setting.json.

Doesn't look like repair created any lost+found, so that's good. But your config/shares folder is a mess with a lot (162) of cfg files for shares that no longer exist. Probably you accidentally created a lot of shares at some time in the past. Go to User Shares page and click CLEAN UP at the bottom. Also, after you rebuild disk3, your system share has files on disk1. Nothing can move or delete open files, so you will have to go to Settings - Docker and disable it before you can move those to cache. And mover won't overwrite files so if they are duplicates you will have to delete them.

I don't personally run any of those apps. I did try Nextcloud a few years ago but found upgrading to be a little troublesome at the time, and I didn't really need it anyway. You can search on the Apps page for that and similar. And there are several backup apps also, but I just use an rsync script to backup some of my shares to my backup Unraid server occasionally. I don't normally have that backup server running except at that time. Sounds like Unraid 8 will be including a very nice backup capability:

Just thought I would clarify the terminology so nobody reading gets confused. You aren't rebuilding the parity disk, you are rebuilding disk2. Better to say you are rebuilding disk2, or maybe rebuilding from parity. Or maybe rebuilding the array, since the end result of rebuilding disk2 should be to have all of the array back in sync. But only disk2 will be rebuilt.

I recommend going to Settings - Docker and disabling Docker until everything is working again.

Emulated disk2 is mounted now, and repair didn't create any lost+found, so that's a good sign. Disk3 isn't mounting as before, I'm not sure what @JorgeB had in mind for that I notice disk1 has very little data, mostly just appdata and system shares. Is that expected?

What we really needed was the Diagnostics with the array started in Normal (not Maintenance) mode. SAFE mode isn't relevant in this case, but Maintenance mode means no filesystems are mounted, so we can't see whether any disks need filesystem repair. But apparently, at least that one filesystem does need repair, so go ahead and click FIX. Then start the array in Normal (not Maintenance) mode and posts new diagnostics.

https://docs.unraid.net/unraid-os/getting-started/set-up-unraid/customize-unraid-settings/#notification-settings

There is also help for many things in the webUI. Clicking on a label on a settings page may toggle on/off help for that item. Clicking the Help (?) icon on the main bar will toggle help on/off for the whole webUI

Settings - Notifications The webUI is searchable

Do you mean you can login to the Unraid webUI but can't access anything from Windows explorer? Attach Diagnostics ZIP to your NEXT post in this thread.

Until you figure out how you created all those shares and fix it, they will come back, including that cache share. Do you know how it happened?

You can New Config both new parity and new disk2 at the same time and let parity rebuild. You can format new disk2 after or even during parity rebuild.

These are my recommendations.

If you assign a disk as disk1, it will rebuild onto that disk. The rebuild will result in the same NTFS filesystem you already have with the emulated disk. Better to assign it as disk2, let it clear, format it, then copy the contents of the emulated disk to it. Then you can New Config/Trust Parity to get it reassigned as disk1 if you want.

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?