Why Does a SATA SSD Disappear After a Warm Reboot but Return After Power-Off?

A SATA SSD may disappear after a warm reboot when the controller or link remains in a bad state that only full power removal clears.

A normal reboot resets software but may not remove standby power from the SSD, controller, backplane, or motherboard port. If the link fails to become ready, the drive can vanish before partitions, filesystems, pools, or applications are involved. A complete shutdown changes the diagnosis because it forces deeper controller and link initialization. Start by identifying the lowest layer that loses the device rather than immediately rebuilding storage or replacing the filesystem.

Determine Whether BIOS, the SATA Controller, or Only the OS Loses the SSD

Record whether the SSD appears in BIOS or UEFI, the operating system’s controller view, the block-device list, the partition table, and the mounted filesystem before and after a warm reboot.

The Linux libATA guide describes how the driver waits for a SATA link to become ready and may treat a device as absent when readiness fails. Its SATA link recovery model explains why a disk can disappear before any filesystem layer is reached.

If BIOS also loses the SSD, focus on firmware, port power, link initialization, cable, and the drive controller. If BIOS sees it but the OS does not, preserve operating-system logs and inspect driver enumeration and controller mode.

Compare Warm Reboot, Full Shutdown, and Power Removal

Test an ordinary reboot, an operating-system shutdown followed by immediate power-on, and a shutdown with power disconnected long enough for standby rails to drop. Repeat each state at least twice.

The PCI device view provides a clean boundary between controller presence and storage discovery. The lspci utility can confirm whether the AHCI or SATA controller itself changed across the reboot even when the SSD block device is absent.

If only full power removal restores the drive, the strongest candidates are retained controller state, incomplete SATA PHY reset, SSD firmware state, or a power-management interaction. That pattern is less consistent with an ordinary mount or partition problem.

Inspect the First SATA Link and Reset Error

Save the kernel or system event log from the failed warm reboot before performing a cold boot. Look for link-down messages, COMRESET failures, device readiness timeouts, failed IDENTIFY commands, or repeated port resets.

SATA Active Link Power Management can place the link into low-power states that some controller and SSD combinations handle poorly. ArchWiki warns that aggressive link power management can cause serious problems on incompatible devices.

The first error is more valuable than later messages saying the filesystem or pool is unavailable. Preserve the port number and drive model so every later cable, slot, and firmware test can be matched to the same path.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Check SATA Cable, Power Connector, and Interface Error Counters

Reseat the SATA data cable and power connector with the server fully powered off. Inspect loose locking tabs, sharp bends, splitters, backplane connectors, and adapters.

Unraid’s storage troubleshooting guidance states that rising UDMA CRC errors should trigger checks of data cables, power cables, controller connections, and ports rather than immediate filesystem repair.

A historical CRC count does not prove the current cable is still bad. Record the raw value, perform one controlled reboot cycle, and check whether the counter increases.

Review SSD SMART, Error Logs, and Firmware State

Capture the SSD model, serial number, firmware revision, power-cycle count, unsafe-shutdown count, interface errors, and available device error logs while the drive is visible.

The smartctl reference describes SMART attributes and error logs that help separate flash-health problems from transport or controller failures.

Apply an SSD firmware update only after verifying backups, model compatibility, and the vendor’s recovery instructions. Change one firmware layer at a time so a successful fix can be identified.

Use a Rescan Only as a Diagnostic

When the controller remains present but the disk is missing, perform one supported storage rescan after all active I/O is stopped. Record whether the SSD returns without a power cycle.

Microsoft documents that the DiskPart rescan command locates newly detected disks, making it useful for distinguishing delayed OS enumeration from a drive that is absent at the controller level.

A successful rescan is not a permanent fix. It shows that the controller and SSD can communicate after another discovery attempt, so the remaining work belongs in firmware, driver, controller mode, or link initialization.

Isolate the Drive, Port, and Controller Before Replacement

After backing up the data, move the SSD to a known-good SATA port using a known-good cable, or test a known-good drive on the original path. Change only one component per cycle.

The ZimaSpace guide to separating SATA cable and drive faults provides the adjacent isolation workflow for storage paths that fail intermittently.

The issue is resolved when the SSD remains visible through repeated warm reboots, cold boots, idle periods, and sustained reads without new link errors. Stop using the drive for primary data if it continues disappearing across known-good ports and cables or reports worsening device errors.