Hi!

Below is a screenshot of how my array used to look. I recently added Disk 3 and moved all the data from Disk 1 to this new drive. Before adding Disk 3, I ran preclear to test it since it was brand new. I did not notice any issues with it, except that I could not get it to spin down, even when pressing the green button next to it with all VMs and Dockers shut down.

I do not remember exactly what happened next. I created a new config, removed Disk 1 and started a preclear on that drive, which I later stopped to continue at another time.

At some point I noticed that Disk 3 had changed its filesystem from xfs to auto, with the additional text "Unmountable: unsupported or no file system", as seen in the screenshot below.

At the same time as Disk 3 is listed in the started array, it also appears in "Historical Unassigned Devices".

I restarted the array in maintenance mode and run xfs_repair with the command 'xfs_repair -v /dev/md3p1'.

The result can be seen below, it has printed dots for an hour and I am not sure for how long this should go on.

I have also added the drive to a computer running Windows. I ran PhotoRec which managed to find and restore files, but not with their original file name.

Any idea on how to restore the drive to xfs and make it work again? I do have backups, but it would be much more convenient if I just could get the drive working again and also understand why this issue occurred in the first place. Please see the attached diagnostics file.

Thank you

claypool-diagnostics-20251225-1111.zip

Disk3 is still being detected as precleared. Stop the array and post the output from fdisk -l /dev/sdb

On 12/25/2025 at 8:05 PM, JorgeB said:

Disk3 is still being detected as precleared. Stop the array and post the output from fdisk -l /dev/sdb

I have recovered all files with UFS Explorer, so if any further actions destroys the data that wont be a problem.

The drive is now removed from the array and appears as an unassigned disk with the correct filesystem.

When I try to mount the disk i get the following error in the log:

Dec 27 12:57:20 Claypool unassigned.devices: Mounting partition 'sdb1' at mountpoint '/mnt/disks/WD_My_Book_25ED'...

Dec 27 12:57:20 Claypool unassigned.devices: Mount cmd: /sbin/mount -t 'xfs' -o rw,relatime '/dev/sdb1' '/mnt/disks/WD_My_Book_25ED'

Dec 27 12:57:20 Claypool kernel: mount: attempt to access beyond end of device

Dec 27 12:57:20 Claypool kernel: sdb1: rw=4096, sector=15628048383, nr_sectors = 1 limit=4294967295

Dec 27 12:57:20 Claypool kernel: XFS (sdb1): last sector read failed

Dec 27 12:57:21 Claypool unassigned.devices: Mount of 'sdb1' failed: 'mount: /mnt/disks/WD_My_Book_25ED: can't read superblock on /dev/sdb1. dmesg(1) may have more information after failed mount system call.'

Dec 27 12:57:21 Claypool unassigned.devices: Partition 'WD My_Book_25ED' cannot be mounted.

The fdisk output confirms there's still a precleared partition layout there; it's an MBR partition, not even using the full disk.

You should still be able to recover the old layout, assuming the XFS signature is still there, and most likely it is. Post the output from :

dd if=/dev/sdX bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

Replace X with the correct device letter, if there is still a signature, it should show something after a few seconds, a couple of minutes tops.

This is the output:

Edited December 27, 2025Dec 27 by BlindOwl

That confirms it starts on sector 2048, which is expected since UD trying to mount it based on the previous partition. This should fix:

Confirm the device is still /dev/sdb, this can change if you reboot

wipefs -a /dev/sdb (this will zap the current partition, not the data)

sgdisk -o -a 8 -n 1:1M:0 /dev/sdb (this will create a new GPT partition from sector 2048 until the end of the disk)

After doing this reboot Unraid, this is required if you are still on 7.2.2, if the disk shows as wrong, do a new config, and it should then mount normally.

54 minutes ago, JorgeB said:

That confirms it starts on sector 2048, which is expected since UD trying to mount it based on the previous partition. This should fix:

Confirm the device is still /dev/sdb, this can change if you reboot

wipefs -a /dev/sdb (this will zap the current partition, not the data)

sgdisk -o -a 8 -n 1:1M:0 /dev/sdb (this will create a new GPT partition from sector 2048 until the end of the disk)

After doing this reboot Unraid, this is required if you are still on 7.2.2, if the disk shows as wrong, do a new config, and it should then mount normally.

Unraid can now mount the disk and access all the files. Thank you! It was also interesting to learn something new.

Do you have any idea what might have caused the issue in the first place?

17 hours ago, BlindOwl said:

Do you have any idea what might have caused the issue in the first place?

I believe this is related to bug that affects all 7.2.x releases except 7.2.3, where a pre-cleared disk signature was only detected after a reboot, I think that is also causing issues if users boot with a partition layout, then change it, add a disk to the array, and format the disk without rebooting, Unraid thinks they are still using the old layout, so after a reboot it will detect the new layout and cause the issue.

I recommend upgrading to 7.2.3, since that's no longer an issue there.