trurl

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.

Maybe anonymized @Mibix examine your syslog at that timestamp and see if you can identify the file

No way to know how well disk2 emulation might work without trying. Any linux should be able to read any of the other disks assuming there are no problems with them. Unraid is linux and if we can get the array started one way or another we can try to read them that way. If we have to give up completely on disk2 we can just New Config and it will let us start the array without that disk. Or if we can get it to emulate disk2 then the array will be started. Those other drives look healthy, but no way to know if the filesystems on them are mountable without starting the array.

The diagnostics only has logs from yesterday so can't tell what happened before that. That's where it gets a little tricky. We would have to force Unraid to accept parity and then disable disk2 instead so we could try to rebuild it. This takes multiple steps that have to be followed exactly, and it isn't really documented except in other forum threads where we have used this method. I will give those instructions when we are ready to try them.

I say this because if disk2 went missing first, disk2 would be the disabled/emulated drive. If parity has been disabled for a while, it might be too out-of-sync to do a good rebuild of disk2 even if the parity drive were really good. Another way to recover the data for disk2 would be to get the array to emulate disk2 from the parity calculation and copy the emulated data somewhere off the array, not to other array disks since that would require parity updates which should be avoided considering the poor state of parity. But of course, the poor state of parity and the fact that it might be out-of-sync, would make it difficult to accurately emulate disk2, whether for rebuilding or just for copying its emulated data.

Parity must have become disabled before disk2 went missing. Do you know how long parity has been disabled?

Depends on how we define "recover". One possible definition would be to rebuild disk2 onto that new drive from existing parity plus all other drives. Whether parity works well enough to allow that remains to be seen, but it may be our only hope if original disk2 can't be read. And if nothing we can do can recover disk2, then you could use that new drive as parity in a New Config that didn't include original disk2.

You will also need to replace parity after we see if we can recover disk2. So another 12TB might be needed. We will see how it goes.

One of the great features of Unraid is each data disk in the parity array is an independent filesystem that can be read all by itself. So there is every reason to expect that all of your other data disks have their data intact.