May 31May 31 I will preface by admitting that I set up UnRaid server years ago and have not given it much focus since. I set it up to run a Plex server for my kids and me (single dad) , and have not done much beyond that other than catch up updates and troubleshoot small issues. I was in the process of better-acquainting myself with UnRaid in preparation to upgrade server drives when this all went sideways...Now trying to get back to functional so that I can work towards a more stable setup.In prep for disk upgrades, I figured it best to update "everything". Watched upgrade vid from AlienTech42 for stepwise prep. I backed up the boot drive, checked SMART on all drives (no errors), updated plugins and dockers, stopped the array, and ran update from 7.0.3 to 7.3.1. After update and reboot, server didn't come back up. Went to office and hardware rebooted, and knew there were problems when I heard an internal drive (the cache) trying to boot. Hard rebooted again and went into CMOS and found evidently CMOS battery was dead and boot config had been dropped so that it was trying to boot from cache drive rather than USB. Replaced CMOS battery, fixed boot order, and booted server back up. Booted up fine this time, but array did not start, pointing at my Disk 1 and saying the "replacement" drive was too small, though it was the same drive. Cache drive also had a error. Started array in maintenance mode, cache fixed seemingly without issue. However, Disk 1 would not fix with xfs_repair (watched SpaceInvaderOne fix video; it didn't directly address array disks, but got the gist that needed to r un repair tool). Tried running xfs_repair from cmd, same issue (no superblock found). Went ahead and synced parity, then checked parity, all without issue. But Disk 1 still shows unmountable. snips attached, again xfs_repair says it can't repair the file system. Disk 1 SMART short test comes back no errors.Also noted after reboot back in one last time to see if by chance it would fix that my dockers are gone. I only had Plex, filebot, and Jellyfin, but all are gone. I'm assuming it is likely an issue with how my appdata is set up; including a snip of drives info.Data in shares appears to be intact, though admittedly I did not get out to check every file directly. The server was running 15TB (4+4+4+3) plus single parity and was not yet at half capacity.So, question is can Disk1 be made remountable? If not, what is best process for going forward ? I know from documentation that I cannot simply replace Disk 1 in this state as the new disk would be unmountable as well due to lack of file system. I have in the wings right now 5 new 8tb drives that are planned for swap in as the box doesn't have enough room to house more drives (except maybe a 2nd cache).Next question is what have I done wrong (appdata?) up to now that caused my dockers to disappear and how do I correct it to best practice going forward?
May 31May 31 Author Array in maintenance stopped, restarted in running mode. Diagnostics run and attached tower-diagnostics-20260531-1034.zip
June 1Jun 1 Community Expert Partition for disk1 appears to be smaller than it should; with the array stopped post the output fromfdisk -l /dev/sdb
June 1Jun 1 Community Expert 33 minutes ago, Blue_Knight said:I too have the same issue, but mine is Disk 3 and none of my dockers are listed.Start your own thread with your diagnostics
June 1Jun 1 Author Array stopped, fdisk run.root@Tower:~# fdisk -l /dev/sdbDisk /dev/sdb: 3.64 TiB, 4000785948160 bytes, 7814035055 sectorsDisk model: WDC WD40EFRX-68NUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 4096 bytesI/O size (minimum/optimal): 4096 bytes / 4096 bytesDisklabel type: dosDisk identifier: 0x00000000Device Boot Start End Sectors Size Id Type/dev/sdb1 1 4294967295 4294967295 2T ee GPTPartition 1 does not start on physical sector boundary.
June 1Jun 1 Community Expert Wrong partition layout, with the array stopped (and assuming disk1 is still sdb), type:sgdisk -o -a 8 -n 1:32K:0 /dev/sdbReboot the server. Disk1 should then show as "wrong." Go to Tools - New Config - Keep All - Apply.Back on main check that all disks are assigned as before but with a blue icon, check "parity is already valid", start the array and post new diags.
June 1Jun 1 Author Verified Disk1 still sdb.Ran command with this result:-------------------------root@Tower:~# sgdisk -o -a 8 -n 1:32K:0 /dev/sdbWarning! Disk size is smaller than the main header indicates! Loadingsecondary header from the last sector of the disk! You should use 'v' toverify disk integrity, and perhaps options on the experts' menu to repairthe disk.Caution: invalid backup GPT header, but valid main header; regeneratingbackup header from main header.Warning! One or more CRCs don't match. You should repair the disk!Main header: OKBackup header: ERRORMain partition table: OKBackup partition table: ERROR****************************************************************************Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but diskverification and recovery are STRONGLY recommended.****************************************************************************The operation has completed successfully.------------------Rebooted.Disk1 does not show as "wrong" as it did at the beginning of this issue, rather has the same message on Main of "Unmountable: wrong or no file system". Array auto-started without including Disk1.Stopped here to clarify whether this is what I should be seeing before doing New Config.
June 1Jun 1 Author Array stopped. Fdisk as follows: --------------root@Tower:~# fdisk -l /dev/sdbDisk /dev/sdb: 3.64 TiB, 4000785948160 bytes, 7814035055 sectorsDisk model: WDC WD40EFRX-68NUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 4096 bytesI/O size (minimum/optimal): 4096 bytes / 4096 bytesDisklabel type: gptDisk identifier: 6762BB78-CD20-4754-B782-107576AB0130Device Start End Sectors Size Type/dev/sdb1 64 7814035021 7814034958 3.6T Linux filesystem-------------New diagnostics run, attached. tower-diagnostics-20260601-1133.zip
June 1Jun 1 Community Expert I missed before that besides the partition layout being wrong, the disk is actually a little smaller than it should be (for a normal 4TB disk)User Capacity: 4,000,785,948,160 bytes [4.00 TB]This is the normal capacity, and what you also have for the other 4TB disks.User Capacity: 4,000,787,030,016 bytes [4.00 TB]So you will need a normal 4TB disk to replace it with. Was that disk always disk1?
June 1Jun 1 Community Expert OK, so the disk is not physically smaller; HPA is enabled:Jun 1 09:59:44 Tower kernel: ata9.00: HPA detected: current 7814035055, native 7814037168You need to disable this:
June 1Jun 1 Author I'm not finding a setting in CMOS that resembles any of the suggested labels in the attached article. The only feature in BIOS I find related to drives is the toggle for HDD S.M.A.R.T. There is an Express Recovery 2 mentioned on the BIOS Splash, but hitting it tells me to install it from CD so guessing that's not what I'm looking for.
June 1Jun 1 Community Expert Solution You can still disable HPA on the Unraid side, but if it's still enabled in the BIOS, it can happen again after a reboot.Type hdparm -N /dev/sdb
June 1Jun 1 Author 30 minutes ago, JorgeB said:You can still disable HPA on the Unraid side, but if it's still enabled in the BIOS, it can happen again after a reboot.Type hdparm -N /dev/sdcsdc or sdb? sdb is Disk1.
June 1Jun 1 Author And from reading the issue description post, if HPA is still being instituted by BIOS, then will disabling it to Disk1 cause the BIOS to potentially drop the HPA on the parity drive?
June 2Jun 2 Community Expert It's for disk1; if it's still enabled in the BIOS, HPA can be re-enabled after a reboot like mentioned.
June 2Jun 2 Author Gigabyte had legacy BIOS updates online. The documentation for them is next to nonexistent, but will flash the last BIOS release this evening to see if it provides control for HPA.
June 3Jun 3 Author Updated BIOS to latest; regrettably no "HERE I AM" new setting in BIOS menus for toggling HPA. Been up for 20 hours...will run command provided [ hdparm -N /dev/sdb ] after a few hours sleep and post back.Many thanks for your patience and assistance.
June 3Jun 3 Community Expert When you run hdparm -N on that disk, it should show something like this (with different numbers)/dev/sda: max sectors = 3907027055/3907029168, HPA is enabledIf yes, you then run hdparm -N p3907029168 /dev/sdX where the number is the second one from before, the larger one, also, replce X with the correct identifierThen reboot and post new diags.
June 3Jun 3 Author Ran the command as directed, but it states it failed (see snip). Did not reboot yet given the fail message.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.