When smartctl reports Critical Warning: 0x08 on an NVMe drive, the controller has locked the media into read-only mode. The drive is refusing all writes to protect existing data. This is a hardware-enforced decision made by the drive firmware. Reboots, firmware updates, and format commands will not clear it.

The most common cause is endurance exhaustion: the spare block pool is depleted and the controller locks writes rather than risk corruption. Read-only transitions can also result from firmware bugs, thermal events, or electrical issues. An unexpected transition on a drive well below its rated endurance warrants forensic review.

What bit 3 means

Bit 3 (value 0x08) in the NVMe Critical Warning byte means “media has been placed in read-only mode.” This byte is in Log Page 02h (SMART/Health Information), byte 0. When the controller sets this bit, it is already rejecting write commands at the hardware level. The host cannot override this.

smartctl surfaces this in two places:

  • The Critical Warning line in smartctl -a output shows 0x08 or a value with bit 3 set (0x09 if bit 0 is also active, 0x0c if bit 2 is also set).
  • The SMART overall-health self-assessment may report FAILED! - media has been placed in read only mode.

Characteristics of this state:

  • Reads still work. The drive serves existing data. This is by design.
  • Writes fail. Any write command returns a device-level error. The NVMe status code for write-to-read-only-range rejection is 0x182, visible in kernel logs as H:0x0 D:0x182 P:0x0.
  • Permanent. Software-level recovery (mkfs, fdisk, badblocks, controller resets, vendor format commands) fails because the controller enforces the lock below the host interface.
  • No false positive. This is not a threshold-based prediction. The controller has definitively locked writes.

Do not confuse bit 3 with bit 2 (0x04, “NVM subsystem reliability degraded”). Bit 2 is an early warning that reliability is degrading. Bit 3 is terminal: writes are already being rejected. Both can be set simultaneously.

Common causes

CauseWhat it looks likeFirst thing to check
Endurance exhaustionPercentage Used near or above 100%, Available Spare at or near 0%, Media and Data Integrity Errors climbingsmartctl -A /dev/nvme0n1 for Available Spare and Percentage Used
Firmware bugDrive well below rated endurance, Available Spare high, no media errors, but bit 3 is setVendor advisories for the drive model and firmware version
Thermal eventComposite Temperature at or above critical threshold around transition time; Warning/Critical Comp. Temperature Time elevatedWarning/Critical Comp. Temperature Time in health log
Electrical issueBit 3 set alongside other Critical Warning bits; symptoms after physical disturbancePower down, reseat the drive, inspect contacts
Security policy enforcementEnterprise drive; bit 3 set after security event or policy changeDrive security state via vendor tools

Quick checks

All commands below are read-only and safe on a production drive.

# Confirm the Critical Warning value and overall health
smartctl -a /dev/nvme0n1 | grep -E "Critical Warning|overall-health|SMART"

# Check endurance and spare state
smartctl -A /dev/nvme0n1 | grep -E "Available Spare|Percentage Used|Data Units Written"

# Check for media errors
smartctl -A /dev/nvme0n1 | grep "Media and Data Integrity Errors"

# Review NVMe error log for write rejection details
smartctl -l error /dev/nvme0n1

# Check temperature exposure history
smartctl -A /dev/nvme0n1 | grep -E "Temperature|Warning.*Temp|Critical.*Temp"

# Check kernel logs for I/O errors
dmesg | grep -iE "nvme|I/O error|read.only" | tail -30

# Verify the drive is still readable (100MB non-destructive read)
dd if=/dev/nvme0n1 of=/dev/null bs=1M count=100 iflag=direct

Diagnosis

The goal is to distinguish expected end-of-life from an unexpected failure that may affect other fleet drives.

flowchart TD
    A["Critical Warning bit 3 set (0x08)"] --> B{"Available Spare near 0%?"}
    B -->|Yes| C["Endurance exhaustion: expected end-of-life"]
    B -->|No| D{"Media errors increasing?"}
    D -->|Yes| E["NAND failing early: check firmware bugs"]
    D -->|No| F{"Thermal history elevated?"}
    F -->|Yes| G["Thermal event: check cooling"]
    F -->|No| H["Electrical or firmware cause"]
    H --> I["Reseat drive, check vendor advisories"]

  1. Confirm bit 3 is set. Run smartctl -a /dev/nvme0n1. Any value with bit 3 set (0x08, 0x09, 0x0c, 0x18) means read-only mode. Do not confuse with bit 2 (0x04), which means reliability is degraded but writes may still work.

  2. Check endurance state. If Available Spare is at or near 0% and Percentage Used is at or above 100%, the transition is expected end-of-life. If Available Spare is still high and Percentage Used is well below 100%, the transition is unexpected. Investigate further.

  3. Check media errors. Non-zero or increasing “Media and Data Integrity Errors” alongside bit 3 confirms the NAND is physically failing.

  4. Check temperature history. Warning Composite Temperature Time and Critical Composite Temperature Time are cumulative counters in minutes. Non-zero values mean the drive spent time above thermal thresholds, which may trigger read-only on some drives.

  5. Check the NVMe error log. smartctl -l error /dev/nvme0n1 shows write command failures with device-level status codes.

  6. Check kernel logs. Look for “I/O error, dev nvme0n1” patterns around the time of transition.

  7. If not endurance or thermal, check firmware and electrical causes. Record model and firmware version, check vendor advisories. If multiple Critical Warning bits are set simultaneously, electrical issues may be involved. Power down and reseat the drive if physical disturbance preceded the transition.

Signals to monitor

SignalWhy it mattersWarning sign
Critical Warning byteBit 3 (0x08) is the definitive read-only indicatorAny value with bit 3 set: immediate page
Available SpareDepletion is the most common precursorDeclining toward 0%, or below vendor threshold (typically 10%)
Percentage UsedEndurance consumption rateAbove 100%, especially with Available Spare near 0%
Media and Data Integrity ErrorsConfirms NAND is physically failingAny increase from baseline
Composite TemperatureSustained high temperature can trigger read-only on some drivesAbove WCTEMP/CCTEMP, or Warning/Critical Comp. Temp. Time increasing
Kernel I/O errorsHost-side confirmation that writes are rejected“I/O error, dev nvme0n1” in dmesg

Fixes

There is no software fix for a read-only NVMe drive. The response depends on the cause.

Endurance exhaustion

This is expected end-of-life. The drive has consumed its rated write endurance and exhausted its spare block pool.

  • Evacuate data immediately. Reads still work. Copy all data to a healthy drive before the underlying NAND degrades further. The read-only state protects data, but does not guarantee indefinite readability.
  • Replace the drive. This is terminal. File an RMA if under warranty.
  • Review the write workload on the replacement. Compare Data Units Written rate against rated TBW. High write amplification (swap on SSD, excessive journaling) burns endurance faster than expected.

Firmware bug

If the drive is well below rated endurance (Available Spare high, Percentage Used low), a firmware bug may be responsible.

  • Check vendor firmware updates. An update will not unlock an already-locked drive, but may prevent the issue on other fleet drives of the same model and firmware.
  • Document firmware version and report to the vendor.
  • Audit other drives of the same model and firmware. Every matching drive is at risk.

Electrical issue

If multiple Critical Warning bits are set, or the transition followed physical disturbance:

  • Power down and reseat the drive. Dirty PCIe contacts have been linked to spurious Critical Warning bits.
  • If the bit clears after reseat, the read-only state may have been triggered by a transient electrical fault. Monitor closely.
  • If bit 3 does not clear, the controller has permanently locked writes. Replace the drive.

Thermal event

Some drives enter read-only mode after exceeding critical temperature thresholds.

  • Check Warning and Critical Composite Temperature Time. Non-zero values confirm past thermal exposure.
  • Fix the cooling problem before deploying a replacement. Missing heatsink, failed fan, or blocked airflow will affect the replacement the same way.
  • The read-only state from thermal events is typically permanent. Cooling the drive does not reverse the controller’s decision once bit 3 is set.

Prevention

Most endurance-exhaustion transitions are predictable weeks or months in advance.

  • Monitor Available Spare continuously. Decline toward the vendor threshold (typically 10%) is the strongest leading indicator. At 0%, the next bad block cannot be remapped.
  • Track Data Units Written against rated TBW. Compute the consumption rate to project when the drive reaches rated endurance.
  • Alert on earlier Critical Warning bits. Bit 0 (Available Spare below threshold) and bit 2 (reliability degraded) precede bit 3. Configure alerts on these bits individually.
  • Keep firmware current. Track model, serial, and firmware version across the fleet for quick identification of fleet-wide exposure.
  • Schedule extended self-tests. smartctl -t long adds read load but is non-destructive. It surfaces latent media defects before they accelerate spare consumption.
  • Configure smartd alerting. Do not suppress alerts on bit 3 in production.

How Netdata helps

Netdata can provide early warning before a drive reaches read-only mode:

  • Correlate Available Spare decline with write rate. Trending Available Spare against Data Units Written gives an accurate exhaustion runway for replacement scheduling.
  • Individual Critical Warning bit tracking.
  • Temperature anomaly detection. ML-based anomaly flags on Composite Temperature catch sustained thermal stress, even when temperature has returned to normal by the time you investigate.
  • Media and Data Integrity Errors growth. Per-second collection surfaces new media errors as they appear.
  • Kernel I/O error correlation. System-level metrics and log collection correlate kernel-side write failures with SMART health data, confirming the read-only state from both perspectives.