Up until today, I had my server limpng along (previous udma crc errors). I removed my SATA expansion card SY-PEX40167JMicron chipsets (JMB582/JMB575) thinking it was failing. I replaced it with a Supermicro AOC-S3008L-L8E (LSI 9300-8i clone). Once I was able to get the card to work through BIOS settings, I rebooted the server with errors.

I was going to try and go into maintenance mode and do the xfs repair however there is no option to go into maintenance mode.

Is there another way I can get Disk 6 back running so I can then deal with Disk 5?

My plan is to use unbalance to move all data from disk 5 to disk 7 and pull it out of the array and zero it out.

Any help is greatly appreciated.

tower-diagnostics-20260729-2024.zip

2 hours ago, Erik M said:

there is no option to go into maintenance mode.

In MAIN - Array Operation

Stop the array. Check the box for Maintenance mode. Start the array.

2 hours ago, Erik M said:

My plan is to use unbalance to move all data from disk 5 to disk 7 and pull it out of the array and zero it out.

Better plan, check filesystem on emulated disk5 and on disk6, then rebuild disk5.

Your plan won't work as stated, some details missing. For one thing, you can't move any data from the unmountable emulated disk5, it won't mount without repairing the filesystem. Whatever you do, you can't remove it from the array without New Config/Rebuild Parity. And why do you think you want to zero it outside the array? Zeroing it while still in the array might make sense so you can remove it with New Config without rebuilding parity.

In any case, doesn't look like there is anything wrong with either disk, just connection problems. In fact, disk6 has disconnected and is now an Unassigned Device.

Except, there is this with disk6

Jul 29 19:59:41 Tower kernel: unraidd1: attempt to access beyond end of device
Jul 29 19:59:41 Tower kernel: sdj: rw=0, sector=3910720624, nr_sectors = 8 limit=0
Jul 29 19:59:41 Tower kernel: md: disk6 read error, sector=3910720560

Not sure how to proceed with that. The disk that was assigned as Disk6 is now Unassigned Device sdl instead of sdj.

What do you get from command line with this?

fdisk -l /dev/sdl

Might also be useful to see if physical disk5 will mount as an Unassigned Device, but we can decide on that later. Hopefully someone else will chime in with some idea what to do about disk6, maybe its problems are preventing disk5 from being emulated accurately.

Stopping the array did not give me the maintainence option.

running root@Tower:~# fdisk -l /dev/sdl

fdisk: cannot open /dev/sdl: No such file or directory

running root@Tower:~# fdisk -l /dev/sdj

Disk /dev/sdj: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors

Disk model: HGST HUH728080AL

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 16773120 bytes

Disklabel type: gpt

Disk identifier: A203B7E7-5C05-4BB1-8522-89E093D27450

Device Start End Sectors Size Type

/dev/sdj1 64 15628053134 15628053071 7.3T Linux filesystem

Also, because I stopped the array, it will now not let me restart it.

I'll attach a new diag, (diag 1) reboot and attach another one.

Interesting. I ran the new diag before I rebooted and now Disk 6 has returned to sdj and it will let me choose maintenance mode.

After restarting the array in maintence mode, I selected disk 6 and the check file system status gives me this

Phase 1 - find and verify superblock...
superblock read failed, offset 0, size 524288, ag 0, rval -1

fatal error -- Input/output error

and it moved it to the unassigned devices again as sdl. I can mount it as sdl and all of the files are there. (diag 2)

Reboot and (diag 3).

Issue has not been fixed.

diag 2.zip diag 1.zip diag 3.zip

Before attempting any filesystem check you need to resolve the issues with disk6, which dropped offline due to an apparent power/connection issue. Check/replace cables for that disk and post new diags after array start

Will do when I get home from work tonight.

I ordered new power cables that will be here tomorrow just incase.

I replaced the power cables with older ones that I had laying around.

Disk 6 is now back online and I ran a diag attached to this post.

After the diag, I went in and disk the Check Filesystem Status on Disk 5. It reported a dirty log. I zero'd the log (results attached) and restarted the array. Still has the red X but it did allow me to check and verify that the data was still on the drive.

I believe that in order to get rid of the red x, I need to do a new config and set it to preserve everything and when I start the array set to parity to valid so it does not try and rebuild parity. Once that is done, I need to fire up Unbalanced and move everything off of Drive 5 to Drive 7. There is now a folder on Disk 5 called lost+found. Do I need to move that to Disk 7 as well or can I skip it?

After the days of it moving everything over, (I'm not sure how to do this part) zero out disk 5 and then rebuild parity.

By zeroing Drive 5, I'm hoping that will remove any garbage that could cause it to have file system failures.

Is my thinking correct?

tower-diagnostics-20260730-1844.zip Disk 5 XFS Repair Log.zip

4 hours ago, Erik M said:

Is my thinking correct?

All of it is wrong. You need to rebuild the disk.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

But here is where it might be useful to examine the contents of the physical disk as an Unassigned Device.

Rebuilding the emulated disk will result in exactly what you see with the emulated disk, including the lost+found.

The contents of the physical disk will be missing any writes to the disk that happened after it was disabled, but the emulated disk will have those missing writes. If you rebuild the disk, you will recover those missing writes.

But, the lost+found that will result from rebuilding the disk might be a more significant problem than any writes that might have been missed.

In so, your idea of New Config the physical disk back into the array could be a better choice, but in that case you must allow it to rebuild parity because the physical disk and parity are not in sync.

Before reassigning the disk to rebuild it, see if it will mount as an Unassigned Device.

To move Disk 5 to an unassigned device, is the proper way to stop the array, use the drop down menu to unassign it then restart the array?

I understand the logic of rebuilding before I move files around I was just trying to save a couple of days as the parity checks normally take 2.5 days.

I just thought of some added information in regards to losing any writes to Disk 5. There are 2 shares that are on that drive. I have notwritten any new files to those shares in a few weeks so I don't think I'd lose anything and it's not the end of the world if I lose a few of those files in the shares. I'd prefer not to but am not going to be heartbroken as long as a good amount of the files are recovered.

Adding to the question of checking the unassigned devices, currently there are no devices listed in the Unassigned Devices hence me asking if I need to unassign it from the array and then restart the array.

Yes, unassign the disk then start the array. If the disk will mount as an Unassigned Device, you can check its contents. If it is unmountable then it would have to be repaired as the emulated disk was. Perhaps that would also result in lost+found. Maybe the physical disk will have less (or none) in lost+found than the emulated disk.

Those most recent diagnostics you posted appear to have been taken when emulated disk5 was still unmountable. Post new diagnostics after starting the array.

Yes, I could mount and view all files in Unassigned Devices.

I left it unassigned, started the array and did a diagnostic with Disk 5 is still unassigned but mounted.

Once that was done, When I put Disk 5 back in the array, it warns that all data will be over written. I'm assuming that this is due to it being rebuilt by the parity.

If this is what we are looking for then I'll start the parity check before I go to work in the morning.

tower-diagnostics-20260731-0232.zip

If the actual disk5 contents look better than the emulated disk, i.e., it doesn't need a filesystem repair and there aren't lost+found folders, it may be better to do a new config instead of rebuilding, since the disk itself looks health.

For that, you would go to Tools -> New Config -> Preserve current assignments: All -> Apply

Then reassign disk5 (if not yet assigned)

Check "parity is already valid"

Start the array and run a correcting parity check, a few sync errors are expected.

Rebuild was going quickly until at 11.8% a new error occured.

Disk 3 (which I never had issues with previously) is in an error state and was automaticly disabled.

I can't begin to think of a reason for these failures.

Should I stop the array and do a file system check on Disk 3 now and then start over?

tower-diagnostics-20260731-0758.zip

1 hour ago, Erik M said:

Rebuild was going quickly until at 11.8% a new error occured.

I assume you mean the parity check.

Also looks like a power/connection issue; any power splitters in use?

Yes there are. 2 of them that split into 5. The power supply I have is the Thermaltake Smart Series 600W (Model: PS-SPD-0600NPCWUS-W) and with needing 10 connections, I use splitters.

I do have 2 new splitters that were delivered today that I planned on swapping out the old ones. It was October 2023 when I last replaced them.

I assume that since right now, the parity check automatically paused. I Should cancel it, shut down, replace the power cables and reboot so it will start performing the parity check again.

1 hour ago, Erik M said:

2 of them that split into 5.

This is very bad news and a known issue, avoid splitting any Molex connector into more than 2, and never split a SATA connector into more than two; SATA plug doesn't have enough amps for more.

Ok, I'll have to use what I have for now and will look at other PSU's that have more connections. I have another modular style in a computer that I don't use. Maybe that will have more connectors.

I can also, for now, put a second power supply next to the server to power up a few of the drives. If the parity check makes it through with no more power issues, I will get a new PSU that has more wattage and more than 3 SATA connectors

It appears I need a bigger PSU. With seperating the power connectors so none of them were on splitters, it sucessfuly completed the parity check.

Lots of errors written back to the parity drive but I suspect that is due to all of the previous attempts at running a check and the power connectors failing.

Bigger PSU is on it's way.

Thank you to everyone who helped me get this back on track!

Also time to scale back and remove a couple of drives.

tower-diagnostics-20260801-1246.zip

Edited August 1Aug 1 by Erik M

Number of sync errors is normal considering what was one, important part is not disk read/write errors, also 0 ATA errors logged.

If that was not a correcting parity check, you must run one.