QNAP Says Volume Not Active. Don't Click Recover.

Written and maintained by the Desert Data Recovery lab team. · Updated September 16, 2026

We already wrote about Synology DSM's Volume Crashed / Repair, about the RAID controller's Rebuild button, and about Unraid Format and TrueNAS destroy-and-recreate. This is the QNAP screen: Storage & Snapshots (older firmware still says Storage Manager), a volume or pool that will not come up, and Recover / Recover RAID Group. The words are different. The write is the same class of mistake.

What Volume Not Active usually means

A QNAP volume is not one thing. Under Storage & Snapshots it is a stack. On QTS that is typically an mdadm RAID group, then a storage pool or a static volume, then a thick or thin volume — ext4 on a lot of older boxes, Btrfs when snapshots were the point. On QuTS hero the pool is ZFS. Volume Not Active, Inactive, RAID x — Not Active, and a failed / Error volume are Storage & Snapshots states. They do not say which layer failed.

The same red or grey status can be:

• An mdadm RAID group that will not assemble — one disk dropped, two dropped, metadata that no longer agrees across members, or a power event that left the array unassembled
• A storage pool QTS or QuTS marked Inactive because the RAID group underneath is Error or Not Active
• A volume that will not mount even if the pool still comes up: dirty ext4, broken Btrfs tree roots, or a ZFS dataset QuTS will not import
• Qtier or SSD cache sitting on the same pool, so a cache disk or a tier move is mixed into what looks like "the volume died"

QTS does not split those out for you. Recover is offered in more than one of them. That is the problem.

The public case log does not have a named QNAP job whose intake was this banner. We will not invent a case ID or an outcome. The closest published RAID write-up is a Synology four-drive RAID 5 (DDR-2026-0003) that went offline with two members failed. That was a different NAS and a two-drive RAID 5 loss. Inactive on a QNAP can also be filesystem or pool metadata with every member still present. Those are different failures that share one family of UI statuses.

Inactive is not "degraded but still serving shares"

Warning / Degraded (and the nastier Warning — Degraded — Readonly) means the pool is still there and redundancy is gone, or QNAP has already kicked the set to read-only. Shares may still be up. That is the one situation where a replace-and-rebuild can be a normal maintenance step — if every remaining disk is healthy, the volume is still assembled, and you are following QNAP's procedure for a single known-dead member. QNAP's own notes on Degraded — Readonly are blunt: replacing the "faulty" disk in that state can push the group to Not Active. Back up first if the shares still mount. If they do not, you are not in a backup-then-rebuild job.

Inactive / Not Active / Error means the volume is offline. QTS or QuTS will not assemble the RAID group, or it assembled and the filesystem will not mount. Shares are gone. Recover here is not "check the disk and tell me what happened." It is the NAS attempting to fix a layer it has not identified.

QNAP's own Recover RAID docs say that path is for disks that were temporarily disconnected — a yanked tray, a SATA connector — then put back in the same bays. They say it does not help a failed disk. The UI does not make that distinction. Recover is still sitting there after a drive drop, a power event, or a member that is clicking. Clicking it on a failed disk is a rebuild onto a set that already lost a member you have not confirmed.

The buttons that make it worse

Recover / Recover RAID / Recover RAID Group. In Storage & Snapshots this is Manage → Recover RAID (wording varies slightly by QTS / QuTS version; older Storage Manager said Recover). QNAP's own text says the system then rebuilds the RAID group. That is a write. It is not a read-only report. Believe that it writes. On a set that lost a real disk — not a reseated cable — you are asking mdadm or ZFS to reconstruct onto members that may already be weak.

Check File System. After a Recover, QTS often wants Actions → Check File System on each volume. The check is still I/O against the patient disks. The repair is an in-place write to ext4 or Btrfs. If the crash is RAID- or pool-level, you just wrote to members that were not a filesystem problem. If it is Btrfs, see the next section.

Replace the red drive and rebuild. A rebuild writes reconstructed data onto the new disk and updates parity on the survivors. That is correct only when one member is dead, the rest are healthy, and the volume is still a RAID problem. On an Inactive volume you do not have that confirmation. Same class of mistake as a controller Rebuild.

Initialize, format, or create a new pool on the same disks. A new storage pool or a factory reinitialize treats the old RAID group, pool, and volume as gone. Do not "start clean" on disks that still hold the data.

Yanking or reordering bays. mdadm and ZFS care about member identity. Pulling disks to "test them in a PC," swapping two bays, or reseating until Storage & Snapshots looks happier can change which member QTS tries to reconstruct. Label first. Put a disk back only in the slot it came from. Do not shuffle.

SSH, mdadm assemble, zpool import -F, or a forum "force recover." A shell does not make those a test. Forced import and forced assemble write metadata. If the data matters, that is a lab job on images, not a command on the only copy.

QTS Btrfs vs QuTS hero ZFS — why the "fix" still writes

On QTS, a modern volume with snapshots is often Btrfs. Btrfs is copy-on-write. It keeps historical tree roots — older generations of the filesystem — that a lab can walk with read-only tooling if nobody has written over them. That is often the whole job when Storage & Snapshots will not mount: the current root is dirty, an older one is not. In-place Check File System / repair rewrites superblocks and tree roots on the live members. It can destroy the older generations that were still readable. Once those roots are gone, we are not walking them back.

QuTS hero is ZFS. The pool is not mdadm-plus-a-volume in the QTS sense. Recover RAID on QuTS is still documented as a rebuild after disks were disconnected. A forced import, a scrub you started to "see if it comes back," or destroying the pool to recreate it from backup is the TrueNAS-shaped version of the same write. We already cover that click on the TrueNAS import page. Do not destroy the pool to start clean if you still need the data.

Older QTS ext4 volumes do not have the Btrfs generation story, but fsck-style repair is still a write. If the Inactive status is actually a dead RAID member, you are running filesystem repair against an incomplete array.

This is not the Synology post with the logo swapped

Synology DSM says Volume Crashed and offers Repair. QNAP says Inactive / Not Active and offers Recover. Do not copy the Synology clicks onto a QNAP. The stacks are not the same:

• QNAP names three layers you can see: RAID group, storage pool (or static volume), then the volume. Inactive can sit on the pool while RAID x — Not Active sits on the group. Recover targets the RAID group. Check File System targets the volume. Mixing those up is how people "repair" the wrong layer.
• QTS is usually mdadm, not Synology SHR/LVM. There is no SHR map to walk. Member order and md metadata still matter. QuTS hero is ZFS, which is closer to TrueNAS than to DSM.
• Qtier and SSD cache are common on QNAP pools and rare in the Synology write-up. A cache disk that dropped, or a tier that was mid-move when power died, can present as the volume going Inactive. Pulling the cache SSDs or recovering the HDD RAID group without the cache members is another way to write a new map.

The rule that transfers from the Synology post is one sentence: the friendly button writes. Stop before Storage & Snapshots "fixes" the only copy.

What to do right now

Do not click Recover. Do not run Check File System to "see if it comes back." Do not create a new pool on the same disks.

1. Stop. Leave the NAS alone. If a drive is clicking, grinding, or SMART / Storage & Snapshots errors are climbing, power the unit down. Extra uptime on a dying member is more heads-on-media you do not get back. See what a clicking drive means.
2. Photograph Storage & Snapshots. Pool status, volume status, RAID type, drive list with serials if shown, any exact error text (Volume Not Active, Inactive, RAID x — Not Active, Error), and the bay order on the chassis. Screenshots help. They are not a diagnosis.
3. Label every bay before anything is unplugged. Slot 1 through slot N, matching the photos. Bay order is part of the configuration. If you already pulled a disk, write down which slot it left.
4. Keep every disk, including the one you think is dead, the spare you already inserted, and any SSD cache or Qtier members. The disk you "replaced" may still be a required member.
5. Write down what you remember: QTS vs QuTS hero, RAID 1/5/6/10 vs RAID-Z, encryption passwords or SED keys if the pool was encrypted. Encryption without the key is still encryption.

If a disk is mechanical, pack it like any other failed drive. Do not open a drive to "check" it. Do not leave the set running overnight so Recover can finish.

How a lab handles it

We do not click Recover on your NAS. We do not run QTS Check File System against the patient disks.

Each member is imaged write-blocked, sector by sector, including disks that only read in pieces. On QTS, the RAID group is reassembled from those images, then the storage pool or static volume, then the filesystem — ext4 or Btrfs — extracted offline. On QuTS hero, the ZFS pool is imported from the copies, not force-imported on the originals. A wrong guess about rotation, member order, or which Btrfs generation / ZFS uberblock to walk costs a clone, not the original. That is the same method we use on hardware RAID, Synology, Unraid, and TrueNAS. Imaging uses the lab tools already named on this site — including the ACE Lab PC-3000 and DeepSpar Disk Imager — then file work happens on the copies.

We will tell you if the data is not there. A Recover that finished, a reinitialize, or a disk whose platters are gone is not a puzzle we pretend we can solve. There is no QNAP Volume Not Active case in the public case log, and we will not invent one. We don't advertise a success rate. The free evaluation is how you find out which failure you have before anyone bills you.

If the screen you are looking at is Synology DSM rather than QTS / QuTS, start with don't click Repair. If it is Unraid or TrueNAS, see what not to click on those boxes. If it is a controller Rebuild button, see RAID rebuild vs. data recovery. For how these cases run in the lab, see our RAID data recovery service.