9 minutes ago, trurl said:

Did you?

I did, but the page just refreshes and doesn't do anything else.

Did the new diagnosis log provide any information?

I still have a flash backup from 12/29/25 before all these issues. If I need to revert, what files are needed to be replaced for the array configurations?

Edited January 29Jan 29 by Rinny

What are you going to revert to? The old disk7 with the broken connector?

5 minutes ago, trurl said:

What are you going to revert to? The old disk7 with the broken connector?

We could certainly New Config that disk back in if it could be fixed.

How important is the data? Here is something I found:

Datarecovery.com

Can You Fix a Broken SATA Connector on a Hard Drive? - Da...

In order to fix a broken SATA connector on a hard drive, you’ll need to replace the electronics — but first, you should understand the risks.

12 minutes ago, trurl said:

What are you going to revert to? The old disk7 with the broken connector?

I'm thinking about restoring the config from 12/29 and using Disk 6.

The initial problem was with Disk 6 generating crc errors until Unraid removed/deactivated it from the array. I didn't think it was the controller at the time so I purchased a new 26TB drive instead. The array was running on depreciated mode while the new drive was being delivered. I also purchased new mini SAS to Sata cables just in case.

When the new drive arrived, I used the onboard mobo SATA to pre-clear it which took 112 hours.

The major issue happened when I swapped Disk 6 with the new drive and reconnected all the drives to the new cable, I broke the L connector on Disk 7 (ruining all my plans to copy the files from emulated disk 6 to it) so I swap the new drive back with Disk 6 and then swap the new drive with Disk 7. After getting to Unraid (I didn't start her array), the new pre-cleared drive, now connected to the LSI HBA, started getting CRC errors that I realized the controller is bad.

So with the realization that disk 6 is still working perfectly, except Unraid removed it from the array, I thought about using parity + disk 1-6 to recover disk 7 onto the new 18tb drive I purchased today (not the 26tb one I precleared).

The flash backup from 12/29/25 should contain the old config where disk 6 wasn't removed from the array and Unraid not emulating disk 6? Would that resolve the issue where we can't get disk 7 emulated now?

Edited January 29Jan 29 by Rinny

Not sure I understand. We are using the original disk6 in the array right now aren't we?

3 minutes ago, trurl said:

We are using the original disk6 in the array right now aren't we?

Disk6 is mounted, enabled, and has nearly 10TB of data.

9 minutes ago, Rinny said:

using parity + disk 1-6 to recover disk 7

As far as I am aware, that is exactly what we have been trying to do.

13 minutes ago, trurl said:

As far as I am aware, that is exactly what we have been trying to do.

I was thinking about what you mentioned earlier today:

*Emulated disk7 is unmountable.

When disk6 became disabled, it would be emulated while the array was still started, up until you did New Config. Emulated disk6 would have been written to, at least the initial failed write and maybe more. So the array could be out-of-sync with physical disk6, which means it can't accurately emulate disk7"

Would reverting from the flash backup to before when disk 6 had to be emulated allow disk 7 to be mounted? Or would the array still be out of sync with the initial failed write?

Edited January 29Jan 29 by Rinny

On 1/26/2026 at 9:08 PM, trurl said:

1. New Config - Retain All - Apply

2. Assign replacement as disk7, check that all other disks are assigned as before.

3. Check BOTH Parity Valid AND Maintenance mode checkboxes then start the array. This will accept all disks into the array just as they are without mounting anything, so no disk will be changed.

4. Stop the array, unassign disk7, Start the array in Normal (not Maintenance) mode. This will disable disk7

5. Post diagnostics so we can check if emulated disk7 is mountable. Wait before proceeding, may need to repair before rebuilding.

6. Stop the array, reassign disk7, Start the array to begin rebuild.

In step 2, if original disk6 was assigned, and I assumed it was since you didn't say you had rebuilt it, and it has nearly 10TB of data. Then step 3 enabled original disk6 and step 4 disabled disk7 instead so we could rebuild disk7 instead of disk6.

Unfortunately, original disk6 (assuming it was) was no longer in-sync with the array since you had been running with the array degraded for a while. So parity plus disks 1-5 and original disk6 can't provide the data from the parity calculation to accurately emulate disk7.

We attempted to fix emulated disk7 filesystem to maybe recover at least some of its files. Often that will work but some things might be put in "lost+found", where it couldn't figure out what folder a file belonged in or what name a folder or file should have.

Ultimately, you are no worse than you were when you started the thread. All your other disks still have their data, though original disk6 may be missing some writes that happened when it was disabled and being emulated while the array was degraded for a while.

Professional repair of the broken disk7 might be the next step if you decide that is worthwhile.

You could wait and see if @JorgeB or anyone else has another idea.

2 minutes ago, Rinny said:

Would reverting from the flash backup to before when disk 6 had to be emulated allow disk 7 to be mounted? Or would the array still be out of sync with the initial failed write?

Your flash doesn't really have any information on it relevant to this problem except your drive assignments. And we have already reassigned them as they were. All the important information beyond that is on the disks themselves. The flash doesn't know anything about the actual drive contents, and even if it did know a little about the contents, it couldn't be enough since it doesn't have the capacity.

Probably you already know this part, but I sometimes explain that parity doesn't contain any of your data and it couldn't possibly have the capacity by itself to recreate any and all of your other disks. It might be able to be a backup of a single disk, but that isn't what it is. It needs to be able to help rebuild any disk, not a particular single disk. Parity plus all other disks allow the parity calculation to provide the data for a missing disk.

Flash has much less capacity than that. It just has your disk assignments and other settings from the webUI. Even your user shares are ultimately based on the disk contents. They are just the combined top level folders on array and pools. Flash only has webUI settings for those shares, and it often has settings for shares that don't even exist since those top level folders no longer exist for some reason.

5 minutes ago, trurl said:

In step 2, if original disk6 was assigned, and I assumed it was since you didn't say you had rebuilt it, and it has nearly 10TB of data. Then step 3 enabled original disk6 and step 4 disabled disk7 instead so we could rebuild disk7 instead of disk6.

Unfortunately, original disk6 (assuming it was) was no longer in-sync with the array since you had been running with the array degraded for a while. So parity plus disks 1-5 and original disk6 can't provide the data from the parity calculation to accurately emulate disk7.

We attempted to fix emulated disk7 filesystem to maybe recover at least some of its files. Often that will work but some things might be put in "lost+found", where it couldn't figure out what folder a file belonged in or what name a folder or file should have.

Ultimately, you are no worse than you were when you started the thread. All your other disks still have their data, though original disk6 may be missing some writes that happened when it was disabled and being emulated while the array was degraded for a while.

Professional repair of the broken disk7 might be the next step if you decide that is worthwhile.

You could wait and see if @JorgeB or anyone else has another idea.

Thanks. I did send the broken Disk 7 to Kotor data recovery today, awaiting a free eval.

Will await for others about on alternative ideas if there are any. Thanks for the help @trurl .

Edited January 29Jan 29 by Rinny

17 minutes ago, Rinny said:

Or would the array still be out of sync with the initial failed write?

If only it were just the initial failed write, check filesystem would almost certainly be able to recover most if not all files from disk7.

But the array was running degraded while you waited for a replacement, and many things could have been written to the emulated disk6.

When a disk is disabled, it isn't used again by Unraid until it is rebuilt, or New Config accepts it back into the array. Instead, the disabled disk is emulated by reading parity and all other disks and calculating the data for the disabled disk. Even if the original disk is destroyed, the emulated disk can be read in this way. And the emulated disk can be written by updating parity as if the disk had been written, so those writes can be recovered by rebuilding. The initial failed write that caused the disk to be disabled is emulated, and all writes to that disk after that. Maybe a lot of writes were emulated while you waited for a replacement. But since those were written to parity and not the original disk, the original disk was out-of-sync with the array.

Parity is very simple. If you're interested, follow this link

https://docs.unraid.net/unraid-os/getting-started/what-is-unraid/

then expand the Software Defined NAS section and then expand the How Parity Works section under that.

25 minutes ago, trurl said:

If only it were just the initial failed write, check filesystem would almost certainly be able to recover most if not all files from disk7.

But the array was running degraded while you waited for a replacement, and many things could have been written to the emulated disk6.

When a disk is disabled, it isn't used again by Unraid until it is rebuilt, or New Config accepts it back into the array. Instead, the disabled disk is emulated by reading parity and all other disks and calculating the data for the disabled disk. Even if the original disk is destroyed, the emulated disk can be read in this way. And the emulated disk can be written by updating parity as if the disk had been written, so those writes can be recovered by rebuilding. The initial failed write that caused the disk to be disabled is emulated, and all writes to that disk after that. Maybe a lot of writes were emulated while you waited for a replacement. But since those were written to parity and not the original disk, the original disk was out-of-sync with the array.

Parity is very simple. If you're interested, follow this link

https://docs.unraid.net/unraid-os/getting-started/what-is-unraid/

then expand the Software Defined NAS section and then expand the How Parity Works section under that.

I actually disabled every VM and Docker that would use the Array when disk 6 was deactivated. I wanted to reduce the risk as much as possible. For the most part, the only apps that are on the mirrored cache nvme drives were running (bitwarden, swag, etc).

should i try force log zeroing? "xfs_repair -L /dev/md7p1" ?

Edited January 29Jan 29 by Rinny

@trurl & @JorgeB - I wanted to check if the parity was actually holding valid data.

Using xfs_db -r /dev/md7p1, I looked at inode 128. Even though the drive wouldn't mount, the directory structure returned a (good) status for the root entries. Since I couldn't see files in the GUI, I ran a raw search on the emulated partition for known file extensions (.mp4, .png, etc.). The terminal returned clear file paths and executable headers from my shares.

Seems like the data is there and being correctly calculated by parity? The 'Fatal Error 117' appears to be a metadata issue preventing the mount, but the raw data is intact?

I have a new 18TB drive ready to go. Should I proceed with the data-rebuild onto the new physical drive first and then attempt xfs_repair on the physical disk? I've read that trying to perform complex xfs_repair on an emulated drive is not as stable.

Edited January 29Jan 29 by Rinny

If xfs_repair cannot fix the filesystem, best bet is rebuilding it then running a file recovery app like UFS Explorer; the free trial should show if/what it can recover.

5 hours ago, JorgeB said:

If xfs_repair cannot fix the filesystem, best bet is rebuilding it then running a file recovery app like UFS Explorer; the free trial should show if/what it can recover.

I have a paid version from years ago that's still works well. Will try the rebuild onto the physical then.

I think I may be able to recover 10TB of data. 🤞. I should probably delete all the ExoDos/RetroeXo files and redownload them after everything is copied... it's ~1.6TB as a set.