Unraid Says Unmountable. TrueNAS Won't Import. What Not to Click.

Written and maintained by the Desert Data Recovery lab team. · Updated August 26, 2026

We already wrote about the RAID controller's Rebuild button, and about a RAID 5 that loses a second drive. This is a different screen, on boxes people actually run at home and in small offices: Unraid saying a disk is unmountable, or TrueNAS refusing to import the pool. The words are different. The damage from clicking the wrong thing is the same.

Unraid is not RAID. That is the part most people get wrong.

Unraid stores each file on one data disk and keeps parity so it can emulate a missing or disabled disk. It does not stripe every file across the set the way RAID 5 does. That design is why you can mix drive sizes, and why a single unmountable disk is often just that disk's filesystem, not the whole array.

It is also why the Format checkbox does not do what people think.

If a disk shows "Unmountable: Unsupported or no file system" (or Wrong or no file system), Unraid is telling you it cannot mount the filesystem that is supposed to be on that disk. Parity cannot invent a filesystem that is not there. Official Unraid guidance is blunt about this: do not format an unmountable disk. Formatting does not rebuild the files from parity. It writes a new empty filesystem, then updates parity to match the empty disk. The old data on that disk is gone.

That is the single most common way an Unraid case goes from a filesystem repair to a lab problem we cannot undo.

What "unmountable" usually is — and what it is not

On Unraid, unmountable is often one of these:

• The XFS (or Btrfs) filesystem on that array disk is dirty or damaged after an unclean shutdown, a cable/power blip, or a disk that started throwing read errors.
• The disk was disabled and you are looking at the emulated disk. The physical drive and the emulated contents are not the same thing.
• After a New Config, Unraid forgot the filesystem type (it flips back to Auto) or the disk assignments no longer match the data that is actually on those platters.
• A brand-new disk in the array is unmountable because it has never been formatted. That one should be formatted. An old disk full of data should not.

A clicking, grinding, or rapidly accumulating-error disk is not a filesystem problem. Power it down. Do not run repair utilities on a drive that is failing mechanically.

The buttons that make it worse

Format. Next to an unmountable disk there is a checkbox. On start, Unraid warns that existing data will be overwritten. Believe that warning. If you thought parity would put the files back, it will not.

New Config, then guess. People run New Config to "fix" assignments, then do it again when a disk still will not mount, then again. Each start with the wrong disk in the wrong slot, or with a blue "this device will be overwritten" icon they click past, writes a new reality onto the set. We have seen three unmountable disks appear where there was one, because the assignments were shuffled until nothing lined up.

xfs_repair on the wrong device. A filesystem check in Maintenance Mode against the array device (md1p1, md2p1, …) is sometimes the right first step, and it keeps parity valid. The same command against the raw /dev/sdX disk is a different operation: it can invalidate parity, and xfs_repair -L zeros the journal. If you do not know which device you are pointing at, stop. If the repair already failed and reported no superblock, formatting is still not the next move.

Starting the array so it can "rebuild." Unraid can rebuild a disabled disk onto a replacement. That is not what unmountable means. Starting the array to force a rebuild onto a disk you just formatted is how you teach parity that the empty filesystem is correct.

TrueNAS: the pool will not import

TrueNAS does not say "unmountable" as often. It says the pool is FAULTED or UNAVAIL, or zpool import prints "The pool cannot be imported due to damaged devices or data" and then, helpfully, "Destroy and re-create the pool from a backup source."

That last line is a ZFS error string. It is not a diagnosis that your data is gone, and it is not an instruction to wipe the disks.

What we see on these boxes:

• One disk dropped (cable, HBA, backplane, a 3.3V pin trick on a SATA SSD) and the pool is short a replica. The data is often still on the set. Importing degraded can be correct. Importing after you have already pulled the "bad" disk and added a new vdev is not.
• A Replace in the UI that was actually an Add. The pool geometry just changed. The old disk is still part of the pool. Do not format it. Do not use it as the replacement a second time.
• A resilver that was interrupted, then a string of zpool import -f, -F, and -FX attempts. Force-import flags rewind or rewrite pool metadata. They are not a free retry. A dry run (-n) is information. A committed rewind on dying disks is a write.
• Metadata that is actually damaged. That is recoverable more often than the error text implies, but only if the original disks stay untouched so a lab can image them and reconstruct the pool from copies.

If the UI wants you to destroy the pool, export and recreate, or wipe a member so you can "replace" it, that is the same class of mistake as Unraid's Format checkbox. It writes.

What to do right now

Do not start the array or import the pool just to see if it comes back. Do not format. Do not destroy. Do not run New Config to reshuffle slots.

1. Stop. Leave the box powered off if a disk is clicking, if errors are climbing, or if you already clicked something you cannot undo. If the array is still up and only one filesystem is dirty, that is the one case where a careful Maintenance Mode check can still be the right next step — if you know the exact disk and the exact device name.
2. Photograph the screen. Unraid Main (disk order, filesystem column, any blue/orange icons, the exact unmountable text). TrueNAS Storage and the full zpool import / zpool status output. Serial numbers, not just sdb.
3. Label every drive with its slot or Unraid disk number before anything is unplugged. Bay order is part of the configuration.
4. Keep every disk, including the one you think is dead and the spare you already inserted. On TrueNAS, the disk you "replaced" may still be a required member.
5. Write down the config you remember: Unraid array vs cache/pool, XFS vs Btrfs vs ZFS, TrueNAS RAIDZ1/2/3 or mirrors, encryption keys or recovery keys if you used them. Encryption without the key is still encryption.

If a disk is mechanical, pack it like any other failed drive and do not open the enclosure to "check" it.

How a lab handles these without writing to your disks

We do not import your pool on your hardware and we do not start your Unraid array to "try one more thing."

Each member is imaged sector by sector, including disks that only read in pieces. The array or ZFS pool is rebuilt in software from those images: Unraid disk order and parity, or ZFS vdev layout, tried against the copies. A wrong guess costs a clone, not the original. That is the same method we use on hardware RAID and Synology, and it is why we can still work a case after someone has already had a bad night with New Config or zpool import -F — as long as the originals were not formatted afterward.

We will tell you if the data is not there. A format that finished, a committed ZFS destroy, or a disk whose platters are gone is not a puzzle we pretend we can solve. The free evaluation is how you find out which one you have before anyone bills you.

If the screen you are looking at is a controller Rebuild button rather than Unraid or TrueNAS, start with RAID rebuild vs. data recovery. If a second drive has already dropped from a RAID 5, see RAID 5 with two drives down. For how these cases are handled in the lab, see our RAID data recovery service.