Hello

I need some advice on how to proceed with an issue that I have just discovered which likely has been there a while, my secondary server which is fairly old had all reserf drives and I realised I needed to convert to xfs a bit quick to avoid the cut off.

As far as I was aware things had gone fine, but on starting today for the first time after a long period after the initial convert I appear to have Drive 4 showing unsupported or no file system, furthermore the format option is being displayed.

It is suggesting to me that the drive was not formatted before the data was transferred back, I cant imagine that I would have done that, as I had completed the process on all the other disks, but I cant rule that out. But in any event I do not have the data previously moved to facilitate the conversion.

Unraid 6.12.3

Windows 11

tower-diagnostics-20251229-0918.zip

With the array running post the output from xfs_repair -v /dev/md4p1

1 hour ago, JorgeB said:

With the array running post the output from xfs_repair -v /dev/md4p1

Hi Jorge

Thanks for your reply, do you mean with the array started in maintenance mode, ?

In this case it doesn't matter, since the fs is not mounting, as long as the array is started it will work.

1 hour ago, JorgeB said:

In this case it doesn't matter, since the fs is not mounting, as long as the array is started it will work.

Am I applying xfs_repair -v /dev/md4p1 in the file system status box ? if so , access is only possible in maintenance mode or is this in the terminal?

Edited December 29, 2025Dec 29 by TopTrainer

You can run that from the CLI, or if you prefer, start in maintenance mode and use the GUI.

4 hours ago, TopTrainer said:

Hi Jorge

Current update using GUI

-V is still running, Phase 1 has found a bad primary superblock - bad magic number, attempting to locate a secondary, verify superblock continuing.

Edited December 29, 2025Dec 29 by TopTrainer

Let it continue to see if it does find a backup; if it doesn't, using the CLI, type:

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

Just in case there's an XFS signature, but is not aligned to the current partition. If one exists, it should show something after a few minutes; you can cancel anytime with CTRL + C

56 minutes ago, JorgeB said:

Let it continue to see if it does find a backup; if it doesn't, using the CLI, type:

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

Just in case there's an XFS signature, but is not aligned to the current partition. If one exists, it should show something after a few minutes; you can cancel anytime with CTRL + C

The previous command did not find the required result, I have applied the above command via the terminal it also proved fruitless.

That suggests the disk was not converted to XFS, or if it was, it lost the filesystem signature, only possible option that I can see to recover, if there was really an XFS filesystem, there, would be to use a file recovery app, like UFS Explorer. The free trial should show what it can recover.

2 hours ago, JorgeB said:

That suggests the disk was not converted to XFS, or if it was, it lost the filesystem signature, only possible option that I can see to recover, if there was really an XFS filesystem, there, would be to use a file recovery app, like UFS Explorer. The free trial should show what it can recover.

It seems I had issues with this particular drive back in October when I originally undertook the conversion, it appears that there were credential issues caused by windows 11 preventing the conversion, you found a solution for those issues back then, I am wondering if windows has caused another problem here?

6 minutes ago, TopTrainer said:

credential issues caused by windows 11 preventing the conversion

I found your other thread. This really is unrelated to conversion.

There are several ways you could have copied the data from that disk to others without using windows at all. Then "conversion" just means reformatting it to XFS.

But assuming you did in fact attempt to "convert" (reformat) it to XFS, the question now is whether or not you had written any data to it after reformatting.

37 minutes ago, trurl said:

I found your other thread. This really is unrelated to conversion.

There are several ways you could have copied the data from that disk to others without using windows at all. Then "conversion" just means reformatting it to XFS.

But assuming you did in fact attempt to "convert" (reformat) it to XFS, the question now is whether or not you had written any data to it after reformatting.

I can definitely confirm that the data was written to the drive, I simply moved the data back onto the drive from an empty drive on my other server using Tera copy pro, I had done it 13 times previously.

16 minutes ago, TopTrainer said:

data was written to the drive,

then

4 hours ago, JorgeB said:

only possible option that I can see to recover, if there was really an XFS filesystem, there, would be to use a file recovery app, like UFS Explorer. The free trial should show what it can recover.

3 minutes ago, trurl said:

only possible option that I can see to recover, would be to use a file recovery app, like UFS Explorer. The free trial should show what it can recover.

Would be specifically for Linux or windows, I presume it has to be loaded into windows to access?

UFS Explorer

Tried and trusted data recovery software solutions

UFS Explorer is sophisticated data recovery software that has proved to be efficient in numerous data loss cases of different complexity and on various systems

Never used it.

There's one more thing you can try, if the disk was really converted, parity was valid, and something happened to that disk that made it lose the file system without updating parity, you can see if the emulated disk mounts.

Note that to try this, you would need to disable the disk, meaning it will require a rebuild after.

1 hour ago, JorgeB said:

There's one more thing you can try, if the disk was really converted, parity was valid, and something happened to that disk that made it lose the file system without updating parity, you can see if the emulated disk mounts.

Note that to try this, you would need to disable the disk, meaning it will require a rebuild after.

I was wondering myself if this might be an option to try, I don't think I have anything to loose by trying it do I? the disk is dead in the water presently. What is the preferred method of disabling to invoke emulation?

Edited December 30, 2025Dec 30 by TopTrainer

Stop array, unassign that disk, start the array and post new diags.

3 hours ago, JorgeB said:

Stop array, unassign that disk, start the array and post new diags.

tower-diagnostics-20251230-1242.zip

4 hours ago, TopTrainer said:

I can confirm the contents are emulated.

The emulated disk is mounting. Assuming the contents look correct, you can reassign the disk to rebuild, though I'm not sure I would trust that disk, since the emulated disk mounts, it confirms the actual disk lost data by itself (assuming nothing else was done, like a wipefs or similar).

17 minutes ago, JorgeB said:

The emulated disk is mounting. Assuming the contents look correct, you can reassign the disk to rebuild, though I'm not sure I would trust that disk, since the emulated disk mounts, it confirms the actual disk lost data by itself (assuming nothing else was done, like a wipefs or similar).

The contents look correct to me, like you, I have lost confidence in the disk, I know the disk is old, nothing else was done to the disk, I do have a new disk that I could slot in there, though I am away overnight for new years eve, so it might be pertinent to leave till my return please remind me of that procedure, as it is not a regular occurrence for me.

On 12/30/2025 at 2:52 PM, TopTrainer said:

The contents look correct to me, like you, I have lost confidence in the disk, I know the disk is old, nothing else was done to the disk, I do have a new disk that I could slot in there, though I am away overnight for new years eve, so it might be pertinent to leave till my return please remind me of that procedure, as it is not a regular occurrence for me.

Happy new year, im back, am I right in think, as the contents are emulated, and the disk 4 is mounting, can I just remove the disk and replace it with a new larger one, or do I have to rebuild the original unreliable one first?

Assign new disk to slot 4 and start array to begin rebuild. New disk must be at least as large as original disk, but no larger than parity.

There is also a way to copy parity to a larger disk and rebuild disk4 to original parity disk (parity swap).