Hi.

I decided to change some SATA cables on my 7-disk raidz2 array. At the same time, I reconnected some disks to other connectors. After loading, Unriad could not start the array, it wrote Unmountable: wrong or no file system. At the same time, the array was imported by the zpool import command, although it was mounted in shares. The files were in place through the explorer.

I decided to create a New Config in order to import it through the interface (I had succeeded with another array before). Apparently, I made two mistakes. I did not select the None option, that is, the array remained in the interface. The second mistake - I launched this array as is, without looking at the properties. It turned out that the file system was reset to Auto in the properties. As a result, the array did not start, and zpool import displays the UNAVAIL status for 4 of the 7 disks (the other 3 are ONLINE). Accordingly, the array is not imported through the command line either. In the Unriad interface, these disks are visible as No partition.

It looks like Unraid wrote something to these four disks and erased the partition information.

Is there any way to restore the array?

39 minutes ago, box01 said:

It turned out that the file system was reset to Auto in the properties.

This is normal, and the way to reimport a pool, it won't cause any issues; please post the current diagnostics.

12 minutes ago, JorgeB said:

This is normal, and the way to reimport a pool, it won't cause any issues; please post the current diagnostics.

elvinhome-diagnostics-20250908-1809.zip

Cannot see what happened since the server was rebooted multiple times, but some devices are reporting no partitions. Post the output from:

fdisk -l /dev/sdi

Yes, these 4 disks reported as no partitions in GUI

Disk /dev/sdi: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors

Disk model: WDC WD102KRYZ-01

Units: sectors of 1 * 512 = 512 bytes

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

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

That suggests they were wiped or the disks lost the partitions due to some other issue. Just trying to reimport a pool would never wipe anything.

We can see if the old zfs signature is still there, type:

sfdisk /dev/sdi, then type 64 and hit Enter and post the results; don't do anything else for now.

When I started the array after new config , the GUI showed about a hundred writes for each disk. It was fast, so it's unlikely that much was rewritten. Maybe some partition headers or else.

Welcome to sfdisk (util-linux 2.41).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Checking that no-one is using this disk right now ... OK

Disk /dev/sdi: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors

Disk model: WDC WD102KRYZ-01

Units: sectors of 1 * 512 = 512 bytes

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

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

sfdisk is going to create a new 'dos' disk label.

Use 'label: <name>' before you define a first partition

to override the default.

Type 'help' to get more information.

>>> 64

The size of this disk is 9.1 TiB (10000831348736 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT).

Created a new DOS (MBR) disklabel with disk identifier 0xcf93c739.

Created a new partition 1 of type 'Linux' and of size 2 TiB.

/dev/sdi1 : 64 4294967295 (2T) Linux

/dev/sdi2:

Edited September 8, 2025Sep 8 by box01

You can hit CTRL + C to abort, there's no zfs signature on the expected sector, meaning the disk wasn't just wiped with wipefs for example, I'm afraid the pool is likely gone; you should restore from a backup.

If there's no backup, the only option may be a file recovery app like UFS Explorer, but the version that supports raidz pool is expensive, though the free trial should show if it can recover something.

I was hoping that this was some known and preferably reversible glitch. Well, thanks for the help anyway!

Maybe it would be possible to, say, create the same partition as on "healthy" disks? So that only the header would be rewritten - if such a concept is applicable...

You can recreate the partition, but since there's no signature, it should not help, but it also won't make it worse. This creates a standard Unraid GPT partition layout for HDDs:

sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

Thank you, I'll try it when the ufs explorer finishes its work :)

After restoring the partition, try

zdb -l /dev/sdi1

To see if it finds a backup label.

root@elvinhome:~# zdb -l /dev/sdi1
failed to unpack label 0
failed to unpack label 1
failed to unpack label 2
failed to unpack label 3

Edited September 9, 2025Sep 9 by box01

Not going to work as expected. Did UFS Explorer find anything?

It spent several hours trying to find the array, and I eventually decided it wasn't worth it, most of the data was in other places. Individual files from the disks weren't recoverable either - probably because of data stripe. Well, for the future, I guess I shouldn't store everything in one zfs array, but give some of the disks to "flat" backup.