NAS Not Detecting Drives
When a NAS suddenly reports its disks as missing, uninitialized, or not recognized, the platters are usually fine. The fault sits upstream, either in the transport layer that connects the drives to the controller or in the metadata the operating system needs to assemble the array. We separate those two cases by imaging every member offline and reading the on-disk metadata from the clones, so the original drives are never written to. Nationwide service is mail-in to our lab at 2410 San Antonio Street, Austin, TX. Free evaluation. No data recovered means no charge.
What a NAS detection failure usually means
A NAS that cannot detect its drives is rarely simultaneous platter failure. The cause is almost always a transport-layer disconnect, such as a SAS expander reset or a backplane power MOSFET, or logical array-metadata corruption, such as a zeroed mdadm 1.2 superblock or a corrupted QNAP partition-1 config database. Power down immediately and image every member. Do not power-cycle, reseat, initialize, or rebuild.
Why is my NAS not detecting the drives?
A NAS fails to detect its drives for one of two mutually exclusive reasons, and the recovery path is different for each. Most consumer and small-business NAS appliances are a Linux box running mdadm software RAID and LVM under a graphical interface, so detection depends on a chain of conditions: the drive must receive power, spin up, negotiate on the bus, present a partition table, and expose a valid mdadm superblock and LVM header. A break anywhere in that chain produces the same symptom on the screen, a missing or uninitialized disk, with very different physical causes underneath.
Path A: physical / transport
The drives are electrically healthy but the appliance cannot reach them. A blown power MOSFET on a shared rail, a SAS expander that keeps resetting, a sagging PSU, or oxidized connectors will drop several drives at once even though the platters are untouched.
Path B: logical / metadata
The drives spin up and report healthy SMART, but the OS cannot assemble the array because the metadata is gone: a zeroed mdadm 1.2 superblock, a lost LVM physical-volume header, an overwritten partition table, or, on QNAP, a corrupted partition-1 configuration database.
Do this first: power the unit down. Every reboot, reseat, or Repair click while you are still guessing which path you are on can move a recoverable case into the unrecoverable column.
Are the drives dead or is it the backplane?
If several drives disappeared together while others in the same chassis are fine, the fault is almost certainly in the shared transport layer, not in the individual disks. A NAS backplane interfaces every drive to the motherboard through shared power rails and a shared signaling path, which means a single component failure can take down a whole bank of healthy drives at once.
Backplane power MOSFET failure
NAS backplanes switch the 5V logic rail and the 12V spindle-motor rail through surface-mount power MOSFETs. When one of these parts fails, for example a 4957AGM-class dual MOSFET governing a rail, power is severed instantly to the affected bay or the entire enclosure. The NAS CPU keeps running and the OS boots normally, but the drives behind the dead rail never spin up and never announce themselves on the bus. To the management UI the disks have simply vanished. This is non-destructive to the data: the platters were never touched, and the array reassembles cleanly once the members are imaged on working hardware.
SAS expander reset cascades
Larger NAS and server chassis fan out many drives behind a SAS expander connected to a single host bus adapter port. The expander behaves like a switch, and when one aging drive starts returning command timeouts, the Linux mpt2sas or mpt3sas driver responds by resetting the entire expander to re-establish communication. That reset briefly interrupts every drive on the topology. If the failing drive keeps timing out, the resets loop, and healthy members occasionally fail to recover from the aggressive bus reset and drop out of the array. The result is that one marginal disk causes the controller to report several good drives as missing.
PSU spin-up current sag
Hard drives draw far more current spinning up from rest, overcoming stiction and accelerating the platters, than they do at idle. As a power supply ages and its 12V rail capacitors degrade, it may no longer deliver the peak amperage needed to spin up several high-capacity drives at once. The voltage sags, the spindle motors stall, and the drives fail to report their presence during the controller scan. The array comes up degraded or empty even though every disk is healthy on a supply that can source the inrush current.
Connector oxidation and the reseat trap
Years of thermal cycling and ambient humidity build a microscopic oxide layer on the gold SATA and SAS contacts, which can raise contact resistance enough to drop a drive. The standard advice is to reseat the drive so the pins scrape the oxide away. That can work once, but repeated power-cycling to force detection is a serious risk: if a drive dropped because of a weak preamp or marginal heads, forcing it through repeated thermal expansion and spin-up surges accelerates head failure, and an unstable head can contact the platter and turn a transport error into permanent rotational scoring.
Why did my Synology or QNAP drop multiple drives at once?
If the drives spin up, report healthy SMART, and still will not assemble into a volume, the failure is logical: the OS cannot read the metadata labels it needs to instantiate the array. Synology and QNAP both run standard Linux storage stacks, so the failure lands in the same places every Linux array can fail: the mdadm superblock, the LVM headers, the partition table, or a vendor configuration database.
The mdadm 1.2 superblock
Linux software RAID identifies each member by a small metadata block called the superblock. Modern NAS systems default to version 1.2, which is 4,096 bytes long and is written at a 4 KiB offset from the start of the partition. That offset was chosen to keep 4K sector alignment and leave room for header data. The command below reads that structure without mounting anything, and on a recovery case it is run only against a write-blocked clone, never the original drive.
mdadm --examine /dev/sdX1A healthy member returns the array UUID, the RAID level, an event counter, and the data offset that marks where your payload begins:
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
UUID : a1b2c3d4:e5f60718:29304152:63748596
Level : raid5
Data Offset : 2048 sectors
Super Offset : 8 sectors
Events : 184213
State : clean
Active Devices : 4If an unexpected power loss interrupts an array write, or a firmware bug initializes a drive incorrectly, that 4 KiB sector can be overwritten with zeros or garbage. To the NAS the drive is blank and not a recognized member, even though your data still starts safely at the data offset and runs clean to the end of the disk. Mismatched event counts across members produce the same outcome: the array refuses to assemble because the superblocks disagree about which member was current at the moment of failure.
LVM headers and partition tables
Synology and QNAP layer LVM on top of mdadm, so the logical volume depends on an intact physical-volume header, and the whole stack depends on the GPT partition table that marks where the mdadm partition begins. If a firmware update or a mis-aimed command overwrites the GPT, the system loses the boundary pointers, cannot find the start of the mdadm partition, cannot read the superblock, and cannot activate the volume group. One overwritten header at the bottom of the stack makes every layer above it disappear.
QNAP partition-1 configuration database
QNAP reserves the first partition of every member, assembled as /dev/md9, for its system configuration database, including the /etc/enclosure_0.conf file that maps physical ports to drive World Wide Names. A sudden power loss, an aborted rebuild, or a failed firmware update can garble or zero that file. On reboot the unit mounts partition 1, fails to read the mapping, and can no longer associate the physical disks with the storage pool, so it reports the drives uninitialized or missing. The user data on partition 3 is physically untouched. This is a logical fault, and it reassembles offline once the metadata is parsed from the clones.
The same architectural reality is why an Synology array or a QNAP array can be reassembled and mounted on a standard Linux workstation. There is no proprietary silicon between you and the data, only standard Linux metadata that has to be read in the right order.
Why does reseating or power-cycling the drives make it worse?
Because the actions that feel like troubleshooting are the same actions that destroy data. Forum and basic support advice almost always escalates risk on a NAS that is already in trouble.
- Repeated power-cycling. If a member dropped because of marginal heads, every forced spin-up adds stiction and surge stress. A head-slap on a weak head converts a non-destructive logical or transport error into a scratched platter.
- Slot-swapping a foreign disk. Inserting a drive the NAS considers unrecognized into a different bay frequently prompts the OS to initialize it as a new volume, which overwrites the mdadm superblock and partition table on the spot.
- Using the Repair or Recover button. A DSM Repair, a QNAP Recover, or a manual
mdadm --createwithout--assume-cleanwrites fresh parity and metadata across the members. If you force this with a stale or out-of-sync drive, the controller recalculates parity against the wrong data and permanently scrambles the stripes. - Moving the drives to a new chassis. Selecting Migrate or Repair on a new enclosure tells it to rewrite system partitions and forcibly import the array. That import often fails and then offers a fresh install that overwrites the data partitions.
None of these is a recovery step. Rebuilding a degraded array restores redundancy on a working array; it does not recover data, and on a degraded array a single unrecoverable read error on a surviving member can halt the rebuild and crash the array entirely. RAID provides hardware availability, not a backup. The safe move is always to stop, power down, and image first.
How is a not-detected drive different from a failed drive?
A not-detected drive is usually healthy but unreachable, while a failed drive has a real physical fault. Telling them apart is the whole job, and it is why imaging comes before any conclusion. A drive that returns clean once it is cloned through a write-blocker was never the problem; the problem was the rail, the expander, or the metadata.
- Not detected, transport fault
- The drive is fine. It lost power or signaling through the backplane, expander, or PSU. Imaged on working hardware it reads end to end and the array reassembles.
- Not detected, logical fault
- The drive is fine and reachable, but its mdadm superblock, LVM header, or partition table is corrupt. The data is intact past the metadata and recovers once the array is assembled offline.
- Physically failed member
- A head crash, seized spindle, shorted PCB, or firmware lockout. This member needs physical work, a head transplant on the clean bench or firmware repair, before it can be imaged. In a parity array the other members still carry the stripes.
How do you recover a NAS that will not detect its drives?
We recover a NAS detection failure by imaging every member offline and reassembling the array virtually, so the original disks are never written to. The procedure is the same whether the root cause turns out to be transport or logical, because imaging first is what lets us tell the two apart safely.
- 1. Power down and document. Record the NAS model, RAID level, member count, filesystem, and every prior reboot, reseat, or Repair attempt. This evaluation is free.
- 2. Label every bay. Mark each drive with its physical slot number before removal. Slot order is required for correct reassembly.
- 3. Write-blocked imaging. Clone each member through hardware write-blockers on PC-3000 Express or DeepSpar Disk Imager. Mechanically failed members receive head transplants on the 0.02 micron ULPA-filtered clean bench before imaging. Software imaging of marginal members uses
ddrescueor HDDSuperClone with adaptive retry. - 4. Read the metadata on the clones. Run
mdadm --examineagainst each cloned partition, compare event counts, confirm the data offset, and inspect the LVM headers and partition table. On QNAP we check the partition-1 configuration database on/dev/md9. - 5. Offline virtual assembly. Reconstruct the exact array geometry from the cloned images with R-Studio or UFS Explorer. The original disks stay powered off.
- 6. Extract and verify. Mount the reassembled volume read-only, copy the filesystem to fresh target media, and verify it. Working copies are securely purged on request after you confirm receipt.
Related reading: RAID rebuild failure recovery covers what happens when a rebuild aborts partway, and two drives failed covers double-fault parity arrays.
What does NAS array recovery cost?
NAS recovery is priced per member drive, because the work is imaging each disk and then reassembling the array. A pool of healthy members that dropped for a transport or metadata reason is logical imaging plus reconstruction. A member with mechanical damage adds the head-swap or surface-damage tier for that one disk.
No data, no charge: if we recover nothing from your array, you owe $0. Free evaluation, no diagnostic fee, no obligation.
Example: a four-member array where all disks are healthy but the array will not assemble is priced from the per-member file-system recovery tier (From $250) for each disk, plus array reconstruction quoted after the free evaluation. A member with a head crash adds the head-swap tier ($1,200–$1,500) plus donor parts for that one drive.
+$100 rush fee to move to the front of the queue. Full per-drive pricing is published on our HDD recovery service page.
NAS Detection Failure Questions
Did all my NAS drives really fail at the same time?
Why does my NAS say the drives are uninitialized when SMART looks fine?
Why does my QNAP show an empty storage pool after a firmware update?
Is it safe to reseat the drives or power-cycle the NAS to force detection?
What is the difference between a drive that is not detected and a failed drive?
Can I just move the drives to a new NAS enclosure?
How do you recover a NAS that will not detect its drives?
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to make sure your hard drive is handled safely and properly. This approach allows us to serve clients nationwide with consistent technical standards.
Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Louis Rossmann's well trained staff review our lab protocols to ensure technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.
See our clean bench validation data and particle test videoYour NAS lost its drives. Power down before doing anything else.
Free evaluation. No data, no charge. Mail-in from anywhere in the U.S. to our Austin, TX lab.