QuTS hero Won't Import. Don't zpool import It on TrueNAS.

Written and maintained by the Desert Data Recovery lab team. · Updated October 4, 2026

We already wrote about QNAP's Volume Not Active / Recover button, about Unraid Format and TrueNAS destroy-and-recreate, about a ZFS scrub that found checksum errors, and about the Rebuild button. This page is the QuTS hero pool that still will not mount, and the advice under the post is to move the disks to TrueNAS, Proxmox, or a Linux machine and force-import them.

What you are looking at

QNAP ships two operating systems, and the bezel does not say which one you have. QTS is mdadm, then a storage pool or a static volume, then ext4 or Btrfs. QuTS hero is QNAP's ZFS system. The pool under it is QZFS — a modified ZFS fork — not a skin on the OpenZFS that TrueNAS, Proxmox, and Ubuntu ship. Storage & Snapshots is where the name shows up. If the screen says QuTS hero, you are on this stack even when the RAID line says RAID 5 or RAID 6. Those labels are how QNAP draws a raidz or raidz2 vdev. They are not the mdadm RAID 5 the QTS path uses.

The failure looks like one of these:

• Storage & Snapshots will not bring the pool up. No storage pool, pool not ready, a pool that stays offline after a firmware update, a power cut, or a disk that dropped. Shares are gone. The wizard that follows is often Create, or an initialize step for a new pool.
• Someone already opened a shell on the QNAP or on another machine. zpool import lists a pool it will not accept, or it says the pool metadata is corrupted. The disks in that list can still say ONLINE.
• The disks have been moved. Trays pulled, set into a TrueNAS SCALE or CORE server, a Proxmox host, or a Linux box with OpenZFS, because "ZFS is ZFS." TrueNAS Import Pool does not offer the pool, or the shell offers -f.

QNAP's own FAQ tells you not to manage a QuTS hero NAS with raw ZFS commands. Storage & Snapshots is the supported layer, and a CLI change can disagree with the configuration database. That warning is about the QNAP. It is not permission to take the same disks to an operating system whose ZFS is a different format. And it does not make Initialize, Recover, or a new pool on the QNAP a safe button. Those still write.

QZFS is a different on-disk format

OpenZFS recognizes a pool by the uberblock, the root pointer written in a ring on each disk's vdev labels. The magic number OpenZFS expects is 0x00bab10c. Published comparisons of QNAP's fork show QZFS using 0x00bab10b. Stock zpool import walks those copies, rejects them, and can report the pool metadata as corrupted — the ZFS-8000-72 text — while the members still read and the transaction groups are still sitting there. The sentence describes the reader. It does not, by itself, describe destroyed files.

The magic is only the front door. The fork adds feature flags OpenZFS does not implement. One of them is a different indirect-block layout: the map from a file's dnode to its data blocks is not the structure TrueNAS walks. RAID-Z on QZFS carries its own layout, and published analysis of the fork describes parity landing in different places than an OpenZFS raidz of the same width would put it. A pool that somehow imports can reconstruct the wrong bytes from parity that was never in that place, and then write those bytes back as if they were a repair.

Changing the magic so the front door opens does not fix the rooms behind it. Import gets further, which is the dangerous direction. OpenZFS then writes its own uberblock, records its own host, and may replay or drop the intent log, using a block pointer format it does not share. The historical transaction groups in that ring are what a later read of the original labels would have walked. A committed import spends them.

The send stream is the same fork, for a different day. QNAP added record types in zfs send. OpenZFS reads those type numbers as different records, and zfs receive on TrueNAS fails with an invalid backup stream. People hit that while the pool is still mounted and they are trying to migrate. It is useful here for one reason: "just send it to TrueNAS" is not a way around the format, and a pool that will not mount has nothing to send. Do not import the disks on TrueNAS in order to create a stream.

This is not a branding difference and it is not a feature-flag version bump of the kind OpenZFS already knows how to refuse cleanly. A newer OpenZFS pool on an older TrueNAS says the pool uses unsupported features and stops. QZFS can fail that check too, because the flags are QNAP's. It can also fail earlier, at the uberblock, and look like corruption. Both refusals are the format. Neither one is fixed by -f.

The move to TrueNAS, and the flags that write

Do not pull the disks into TrueNAS SCALE, TrueNAS CORE, Proxmox, or a Linux OpenZFS box to import them. TrueNAS Import Pool is an OpenZFS import. The docs for that screen are about a pool that was exported from another OpenZFS host. A QuTS hero pool was not. If the UI shows nothing, the format is why. The next wizard — create a pool on the disks you just inserted — writes a new label over QZFS. Cancel it. Put the disks back in the bays they came from if you already moved them, and stop.

zpool import without a flag is still an open. When it works, it writes a new transaction group: this host, this boot, an updated uberblock. On QZFS it usually does not work, which is the outcome you want left alone. "It refused, so try -f" is how the refusal gets turned into a write.

zpool import -f forces an import OpenZFS is refusing because the pool was last used by another system, or was not exported. That host-lock is a real OpenZFS situation. It is not the QZFS mismatch. -f does not rewrite QNAP's indirect layout into something TrueNAS understands. What it does, when the import proceeds, is write. The uberblock ring advances. The intent log can be replayed onto the pool or discarded. Those are metadata writes on the only copy.

zpool import -F and -FX are a rewind. OpenZFS throws away newer transaction groups until an older label looks consistent, then commits that label. A dry run (-n) is information on an OpenZFS pool. On QZFS the preview is still the wrong reader, and the command people paste from the forum does not include -n. A committed rewind on disks whose blocks TrueNAS cannot interpret discards transaction groups you have not read. The TrueNAS import page already calls a committed -F a write for an OpenZFS pool. On these disks it is that write, aimed at the wrong format.

Destroy and re-create the pool from a backup source is the stock OpenZFS string when import gives up. It is not a finding that the files are gone. Destroy drops the pool label. Create writes a new one. If the backup was this pool, there is no backup. Do not build a new TrueNAS pool on the QNAP members because the dropdown was empty.

Do not scrub, replace, or clear a pool you just forced in, to "see if the data looks right." A scrub is a full read. A replace is a resilver: a full read and a full write of a new disk. That is the scrub page, and it assumes an OpenZFS pool that imported cleanly. A QZFS pool that only imported because the magic was patched is not that pool. Checksums computed by the wrong RAID-Z map will look like damage. Repairing them writes the wrong reconstruction back.

Factory reset, initialize, and Recover

Initialize Storage Pool, or create a new storage pool on these disks. When Storage & Snapshots cannot see a pool it recognizes, the way forward on screen is a new one. Wording moves between QuTS versions. Older firmware still calls the app Storage Manager. Accepting the initialize step writes new vdev labels and a new uberblock ring. The file bytes may still occupy the platters at that moment. The pointer QZFS used to find them is what the new pool replaces. A second reboot will not bring the old pool back, because the label the NAS reads first is the one you just wrote.

Factory reset is two different clicks that forums treat as one. Control Panel's restore-to-factory dialog has a settings reset, which QNAP documents as keeping user data, and a reinitialize path that formats volumes. "Factory-reset Storage so it will see the disks" is how people land on the format path, or on a settings reset that changes nothing about a pool QuTS already failed to import. The box comes back up. Storage & Snapshots still has no pool. The next offer is Create, or Recover. You have not repaired QZFS. You have armed the wipe.

Recover / Recover RAID is the button on the Volume Not Active page. QNAP documents it as a rebuild after disks were disconnected and put back in the same bays. It writes. On QuTS hero that write is against QZFS members, not against an mdadm group. Do not click Recover because TrueNAS refused the set and you put the trays back. Do not click it because a factory reset left the pool offline. If Volume Not Active is the screen you actually have, and nobody has moved the disks, read that post and stop there. This page does not replace it.

A member moved to a PC "to test the disk" meets Windows Disk Management. Unknown / Not Initialized is the Initialize Disk dialog. QZFS labels live on that member. A new partition table, and the backup table GPT writes at the end of the disk, sit where those labels live. diskpart clean is the same family. Slide the disk back into the NAS afterward and the set no longer matches the other members.

Do not run QNAP's ZFS commands over SSH to finish what the UI would not. zpool import -f on the QuTS hero box is the same flag as on TrueNAS, pointed at the original disks. QNAP already says that CLI is unsupported. Unsupported here means it can desync the configuration database. It also means a forced import still writes pool metadata. A shell is not a read-only mode.

This screen is not the other pages

Volume Not Active, don't click Recover is the QNAP UI: QTS or QuTS hero, a volume or pool marked Inactive, and Recover. That post covers the stack difference in one section and tells you QuTS hero is ZFS. It does not cover pulling the disks. Use it when the button in Storage & Snapshots is Recover and the trays are still in the NAS. Use this page when the proposed fix is TrueNAS, a factory reset of Storage, or zpool import -f. Do not follow this page into a Recover click, and do not follow that page into a TrueNAS import.

Unraid unmountable, TrueNAS will not import is a different pool that happens to share a sentence. Unraid's Format checkbox empties a disk and then teaches parity that the empty disk is correct. TrueNAS's destroy-and-recreate line is what OpenZFS prints when an OpenZFS pool will not import. -f, -F, and -FX on that page are flags against OpenZFS metadata. A QuTS hero set is not an Unraid array and it is not a TrueNAS pool that forgot to export. The same words appear because OpenZFS is doing the talking. The bytes on the platters were written by QZFS. If your screen is Unraid, or a pool you created on TrueNAS, use that post. If the pool was born on QuTS hero, you are here.

The scrub page is an imported pool. A scrub found checksum errors. Replace starts a resilver. QuTS hero can show a degraded pool that is still mounted; the "do not resilver the only copy" idea is that post, and QNAP's own rule still applies: do not run the raw ZFS commands from the shell as the repair. This page is earlier. The pool did not import on stock OpenZFS, or QuTS will not mount it. Do not export it, move it, and force-import it so you can scrub it on TrueNAS. A scrub of a pool the wrong ZFS only barely accepted is a read of the wrong layout, and a repair pass writes.

Rebuild vs. recovery is the general difference. A rebuild writes a replacement from the members the controller believes are healthy. Recover on QuTS, a resilver after a forced import, and a new pool's initial sync are all that write. The healthy-members condition is something you do not have while the pool is offline and the format is QZFS. If a RAID card is offering Rebuild, use that post. If Storage & Snapshots or a TrueNAS shell is offering to fix a QuTS hero pool, stay here.

RAID 5 with two drives down is a parity set that has already lost a second member. A QuTS hero line that says RAID 5 is usually a raidz1 vdev, which has the same one-disk budget. The "do not rebuild on the originals" rule transfers. The on-disk format does not. That post will not tell you what zpool import -f does to a QZFS label, and this page will not tell you how to reconstruct a hardware RAID 5.

Qtier belongs to QTS, on the Volume Not Active page. Shipping QuTS hero uses ZFS roles for the SSDs instead of that tier. A read cache, a write log, and a metadata device are not Qtier members you can follow the QTS article into removing. Leave them in the set.

What to do right now

Stop importing. If a disk is clicking, or a resilver or a Recover already started, power the NAS down. If the box is quiet and the pool is simply absent, photograph the screen and shut it down before the next wizard. Do not create a pool. Do not initialize. Do not factory-reset Storage to see if the pool returns.

1. Stop. Cancel zpool import, including -f, -F, and -FX, on TrueNAS, Proxmox, Linux, and the QNAP shell. Cancel Import Pool if the TrueNAS UI is waiting on you. Cancel Initialize Storage Pool, Create, Recover, and any factory restore that formats volumes. If a disk is clicking, grinding, or dropping out, power the machine down. See what a clicking drive means.
2. Photograph Storage & Snapshots before a reboot changes the words. QuTS hero, not QTS. Pool name and status. The RAID line QNAP showed (RAID 5, RAID 6, RAID-TP, mirror). Any exact error. The drive list with serials if they are on screen. SSD cache, write log, or a metadata / special disk, if the UI lists them. The TrueNAS or zpool import output too, if you already ran it — the refusal text, not just the last line. Screenshots help. They are not a diagnosis.
3. Label every bay and every serial before anything is unplugged. Slot, and the serial on the label. QZFS knows its members by id. A pile of unlabeled disks is how the wrong one gets initialized on a bench later. If you already moved a tray, write down which bay it left and which machine it visited.
4. Keep every disk. Data members, the disk QuTS already marked failed, a hot spare, the read-cache SSD, the write-log SSD, and any metadata or special device. A write log can hold the newest synchronous writes that never reached the hard drives. A special device holds metadata the pool does not mount without. You cannot tell those apart from the caddy. The system flash inside the NAS (the DOM) is not one of these disks. Do not send a USB copy you made after the import and call it the set.
5. Write down what you remember: QuTS hero version if you know it, whether anyone already ran an import flag, patched a label, clicked Recover, initialized a pool, or factory-reset the NAS — and which restore option. Encryption: the shared-folder password or key file, and a self-encrypting drive's secret if the pool used SED. Encryption without the key is still encryption. And whether a backup exists on media that is not this pool. "The NAS is the backup" means it does not.

Pack loose disks the way you would any failed drive — how to ship a failed drive safely. If you cannot pull the set cleanly, or a backplane is part of the failure, the chassis can come in as a chassis. Do not open a drive on a table to see which member QuTS called faulted.

How a lab handles it

We do not put your disks in a TrueNAS server and run zpool import to see if a dataset appears. We do not force it with -f, rewind it with -F or -FX, or rewrite the uberblock magic on the originals. We do not factory-reset the QNAP, click Recover, or create a new storage pool on those disks.

Each member is imaged write-blocked first. That includes a disk the UI already calls failed, a spare, a read cache, a write log, and a metadata SSD. A drive that only reads in pieces is still imaged as far as it will go. Imaging uses the lab tools already named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager. Those tools image the disks. They are not a QZFS import button, and we will not pretend a stock zpool import of the images is a different operation than a stock import of the disks. Work happens on the copies.

On those images the question is what the QZFS labels still say: which disks were in the vdev, which uberblock is the latest consistent one, where the indirect blocks and the RAID-Z parity actually are. A wrong transaction group, or a RAID-Z map borrowed from OpenZFS, costs a clone. The same guess in TrueNAS writes the disks. Where an initialize or a committed import has already replaced the label, reconstruction uses whatever older copies the ring and the platters still hold. It does not put the label back by creating a pool on the originals.

What imaging cannot do: put back a vdev label a new pool already overwrote, a transaction group a force-import or a rewind already discarded, or a resilver that wrote a bad reconstruction across the set. The technician on your case will tell you if that current copy is not there.

The public case log has no QuTS hero pool, no QZFS job, and no case where the disks were imported on TrueNAS or Storage was factory-reset to remount the pool. We will not invent one.

The closest published array work is other firmware. DDR-2026-0003: a Synology four-drive RAID 5, two members failed, nothing rebuilt in the NAS, each drive imaged, the array reconstructed from the images. Full recovery. The filesystem on that volume was EXT3/4. It is not QZFS, and it is not a QNAP. 21607: twelve HPE 1.8 TB SAS drives on one SmartArray, a five-drive RAID 5 and a seven-drive RAID 6, three RAID 6 members failed, nothing rebuilt on the original controller, every member imaged, the arrays reconstructed virtually. Full recovery. It is a hardware controller, not a QuTS hero pool. Those outcomes belong to those drives. They are not a rate, and they are not a prediction about a QZFS pool someone is about to zpool import -f. We don't advertise a success rate.

If the button on the QNAP is Recover and the disks have not been moved, start with Volume Not Active. If the pool was created on TrueNAS or the array is Unraid, start with what not to click on those boxes. If the pool is up and the scrub is the problem, start with don't race the replace. For the work itself, see RAID data recovery.