We had several power blackouts and after restarting the array all my drives show as unmountable. It seems to me that Unraid is seeing all the drives as not having a file system at all despite having had the array running for several weeks. I have attemped to find a solution from searching but have gotten nowhere. running XFS_REPAIR from command line results in it searching for missing super block with no success and seemingly never ending dots. Just an fyi i am a complete noob with unraid and will also be investing in a ups after this nightmare.

Easy to get command line wrong. Should use webUI.

Attach Diagnostics ZIP to your NEXT post in this thread.

Because the filesystem appears to be missing, the webui doesnt give the option to run it like that. That is why i tried the command line. Diagnostics attached, i will post screen shots later. gen8microserver-diagnostics-20260109-1049.zip

Edited January 9Jan 9 by beng40

Jan 7 18:20:37 gen8microserver kernel: md: could not read superblock from /boot/config/super.dat

suggests there might be something wrong with the USB or the super.dat is corrupt/missing.

Jan  7 18:21:10 gen8microserver emhttpd: Mounting disks...
Jan  7 18:21:10 gen8microserver emhttpd: mounting /mnt/disk1
Jan  7 18:21:10 gen8microserver emhttpd: disk1: mount error: unsupported or no file system
Jan  7 18:21:10 gen8microserver emhttpd: mounting /mnt/disk2
Jan  7 18:21:10 gen8microserver emhttpd: disk2: mount error: unsupported or no file system
Jan  7 18:21:10 gen8microserver emhttpd: mounting /mnt/disk3
Jan  7 18:21:10 gen8microserver emhttpd: disk3: mount error: unsupported or no file system

can you put the array in maintenance mode? Click on the disk# name and see if you can see the repair button

Edited January 9Jan 9 by MowMdown

11 minutes ago, MowMdown said:

Jan 7 18:20:37 gen8microserver kernel: md: could not read superblock from /boot/config/super.dat

suggests there might be something wrong with the USB or the super.dat is corrupt/missing.

Do you have a current flash backup?

Disks are showing up as precleared; post the output from fdisk -l /dev/sdX for all disks.

no option to check disk in the gui when in maintenance mode

Edited January 9Jan 9 by beng40

All the disks have a pre-cleared partition layout.

Assuming the disks were formatted with XFS, see if this command shows an output:

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

Replace X with the correct identifier of one of the data disks. Assuming the previous partition layout was not a weird one, it should show something after a couple of minutes tops if there's an XFS fs there

That shows the XFS filesystem is on sector 206848, which was likely the previous partition layout, it starts at 101MiB exactly, meaning there was likely a small 100MiB partition starting at 1MiB.

To confirm, this is all non destructive, type:

mkdir /x

losetup -f --show -o 105906176 /dev/sde

mount -o ro /dev/loop# /tmp

Replace # with the actual number you get after losetup, e.g. /dev/loop2

Then, assuming the mount command succeeds, browse /x to confirm you see the expected disk contents.

yes all data appears present as expected

Good, now unmount that disk with

umount /x

And run the same dd command for the other data disk to confirm if they all use the same starting sector, so that we can then recreate the partitions.

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

The other two are using a different sector. Confirm using the same method as before if they mount and the contents look correct by mounting one of them at a time in /x

losetup -f --show -o 1048576 /dev/sdc

mount -o ro /dev/loop# /x

Browse and confirm it looks good, then unmount first

umount /x

And try the other one:

losetup -f --show -o 1048576 /dev/sdd

mount -o ro /dev/loop# /x

Browse and unmount

umount /x

sdd shows correct data, sdc was not utilized for storage as yet so shows no data, but that should be correct.

OK, make sure you unmount the last filesystem from /x, If you rebooted since, check that the disk identifiers are the same; they can change with a reboot.

Then, to recreate the partitions, use (assuming the disk identifiers are still all the same):

This will zap the current wrong partitions (not the data)

wipefs -a /dev/sdc

wipefs -a /dev/sdd

wipefs -a /dev/sde

Then create the correct partition layouts:

sfdisk --label dos /dev/sdc <<< 'start=2048'

sfdisk --label dos /dev/sdd <<< 'start=2048'

sfdisk --label dos /dev/sde <<< 'start=206848'

When creating the partitions, sfdisk should output, together with the new layout info, in red: Partition #1 contains a xfs signature.

It should show that for all 3 using the commands above, but if it doesn't, the starting sector is not correct for that disk, so let me know.

If all 3 showed the signature message, all should be OK. Reboot Unraid; this is required, and related to a bug that is in all 7.2.x releases except 7.2.3, which I believe is what caused your issue, so you may want to take the opportunity to upgrade to 7.2.3 (but it's not required to upgrade now, just rebooting is).

After the reboot, all data disks should show as "wrong." Go to Tools - New Config - Keep All - Apply.

Back on Main, check that all disks are assigned correctly; also click the "parity is already valid" box next to the array start button, and then start the array, confirming all disks mount and show the expected data.

If all looks good, and parity was valid before, it should still be, but it's a good idea to run a correction check when you can.

All up and running again, thanks. Some lessons learnt here i guess, ups required to prevent unclean shutdowns, need to backup my flash device asap and also update unraid. Appreciate your help!!!!!!

4 hours ago, beng40 said:

ups required to prevent unclean shutdowns

That's definitely recommended, but if it was what I think, in this case the issue would have occurred the same after a normal reboot, it was not because the reboot was unclean.