Monitoring drive health with SMART (smartctl)

Hard drives and SSDs do not usually die all at once. They fail gradually — a few bad sectors here, a rising error count there, weeks or months before the day they stop responding entirely. The good news is that every modern drive keeps a running tally of its own health and is happy to tell you about it, if you ask. That early-warning system is called SMART (Self-Monitoring, Analysis and Reporting Technology), and reading it is the single best habit for not losing data.

Think of this as the front half of disaster recovery. The companion file-recovery guide is what you reach for after something goes wrong; SMART is how you see it coming and back up while you still can — catching a dying disk before you ever need to recover from it. The tool that reads SMART on GNU/Linux is smartmontools (free software, GPLv2+), and for NVMe drives we also touch nvme-cli (free software, GPLv2). Nothing on this page is paid, proprietary, or cloud.

You do not need to read it top to bottom. Install the tool, run two commands, and skip to the attribute table — that is where you learn what the numbers actually mean.

Install smartmontools

The package is called smartmontools on every distribution. It gives you two programs: smartctl (the command you run by hand) and smartd (the background service that watches your drives and warns you — covered later).

# Debian / Mint / Ubuntu
sudo apt install smartmontools

# Arch / Manjaro
sudo pacman -S smartmontools

# Fedora
sudo dnf install smartmontools

Throughout this guide, /dev/sda is a stand-in for your drive. Confirm the real name with lsblk first — point these read commands at the wrong disk and nothing breaks, but you will be reading the wrong drive's health:

# list your disks by size and model so you can pick the right one
lsblk -d -o NAME,SIZE,MODEL,TRAN

Most smartctl commands need root to talk to the drive, so they are shown with sudo.

Check that SMART is supported and enabled

Start by asking the drive who it is and whether SMART is switched on. The -i flag (for information) prints the model, serial, firmware, and — near the bottom — two lines that matter:

sudo smartctl -i /dev/sda

Look for these two lines in the output:

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

If it says Available but Disabled, turn it on once (it stays on across reboots). The -s on flag means "SMART support: on":

# enable SMART on the drive
sudo smartctl -s on /dev/sda

Tip: if smartctl -i says SMART is not available at all, it is almost always a USB enclosure hiding the drive rather than a drive without SMART. Jump to the USB enclosures section below — a -d flag usually fixes it.

The overall health check

The fastest possible question — "is this drive okay?" — is answered by -H (for health). It prints a single PASSED/FAILED verdict the drive computes itself:

sudo smartctl -H /dev/sda

A healthy drive says:

SMART overall-health self-assessment test result: PASSED

Warning: PASSED is reassuring but not a clean bill of health. A drive only flips to FAILED when an attribute crosses the manufacturer's threshold — which often happens very late. A drive with hundreds of reallocated sectors and a fistful of pending ones can still report PASSED. So treat FAILED as "replace it today", but never treat PASSED as "nothing to see here" — read the attributes below.

The full report

The real detail comes from -a (for all), which prints the identity, the health verdict, every SMART attribute, and the error and self-test logs in one go:

sudo smartctl -a /dev/sda

For absolutely everything the drive exposes — including extra logs and vendor pages that -a leaves out — use -x (for extended):

sudo smartctl -x /dev/sda

The first time you run this it looks like a wall of numbers. The next section is the key to reading it: only a handful of those rows actually predict failure.

Reading the attributes that actually matter

On a SATA or older drive, -a prints a table of attributes, one per row, that looks roughly like this:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      ...  RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  ...  0
  9 Power_On_Hours          0x0032   089   089   000    Old_age   ...  9841
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   ...  0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   ...  0

The trap for newcomers is reading the wrong column. There are two different numbers on each row:

• The VALUE (and WORST) is a normalized score, almost always starting at 100 (or 200/253) and counting down toward the THRESH(old) as the drive wears. Higher is healthier; crossing the threshold is what trips a FAILED.
• The RAW_VALUE on the far right is the actual count — the real number of reallocated sectors, the real hours powered on, the real temperature. This is the column you usually care about.

Here are the rows worth knowing, and what they mean in plain terms:

Warning: the single rule that matters most — a count that is non-zero AND rising on Reallocated_Sector_Ct (5), Current_Pending_Sector (197), or Offline_Uncorrectable (198) means the drive is actively failing. Do not wait for FAILED. Back up immediately, then plan to replace it. Re-run smartctl -a a day or two apart to see whether the numbers are climbing.

For SSDs: the wear attributes

Solid-state drives wear out by writes, not by spinning, so they report a different set. The names vary by manufacturer, but watch for these:

• Wear_Leveling_Count or Media_Wearout_Indicator — a normalized VALUE that counts down from 100 as the flash is used up. When it approaches the threshold, the SSD is near the end of its rated writes.
• Percentage_Used (often shown for NVMe and newer SATA SSDs) — counts up: 0 means brand new, 100 means the rated endurance is spent. Above 100 it keeps working but is past its warranty life.
• Total_LBAs_Written / Host_Writes — how much data has been written over the drive's life; compare against the manufacturer's TBW (terabytes-written) rating.
• Reallocated_Sector_Ct / Reallocated_NAND_Block_Cnt — failed flash blocks. As with spinning disks, a rising count is the warning sign.

Tip: an SSD nearing its write limit usually fails gracefully — many switch to read-only so you can still copy your data off. A spinning disk shedding sectors is the more urgent emergency. Either way, the response is the same: back up now.

NVMe drives

NVMe SSDs (the gumstick-shaped ones that plug straight into the board) use a different health log, but recent smartctl reads it just fine — point it at the NVMe device node:

# full report for an NVMe drive
sudo smartctl -a /dev/nvme0

For an NVMe-native view you can also install nvme-cli (free software, GPLv2), which speaks the protocol directly and is the canonical tool for these drives:

# Debian / Mint / Ubuntu
sudo apt install nvme-cli
# Arch / Manjaro:  sudo pacman -S nvme-cli
# Fedora:          sudo dnf install nvme-cli

# read the drive's SMART / health log
sudo nvme smart-log /dev/nvme0

The fields to read on an NVMe health log:

• percentage_used — endurance consumed, 0 (new) to 100 (rated life spent), same meaning as above.
• available_spare vs available_spare_threshold — the pool of spare flash blocks, as a percentage. When available_spare drops toward the threshold, the drive is running out of replacements for failed blocks.
• media_errors — unrecoverable data-integrity errors. Should be 0; any non-zero value is a warning.
• critical_warning — a bitmask that is 0 when all is well; non-zero flags problems like spare-below-threshold, an overheating drive, or read-only mode.
• temperature — NVMe drives run hot; sustained high temperatures throttle them and shorten their life.

Running self-tests

The attributes above are passively recorded. You can also tell the drive to actively test itself — scan its surface for problems on demand. There are two common lengths, and the test runs on the drive in the background while you keep working.

# quick test (a minute or two): checks the electronics and a sample of the surface
sudo smartctl -t short /dev/sda

# thorough test (can take hours on a big disk): reads the ENTIRE surface
sudo smartctl -t long /dev/sda

The command returns immediately and tells you roughly when the test will finish; it does not wait. Come back later and read the results from the self-test log with -l selftest (for log: self-test):

# show the self-test history and the latest result
sudo smartctl -l selftest /dev/sda

You want to see Completed without error. A line ending in read failure with a low remaining-percentage points straight at a failing surface:

Num  Test_Description    Status                  Remaining  ...  LBA_of_first_error
# 1  Extended offline    Completed without error       00%  ...  -
# 2  Short offline       Completed: read failure       40%  ...  104857600

Warning: a self-test that reports read failure, or one that bumps Current_Pending_Sector upward, is the drive telling you it cannot read part of itself. That is a confirmed problem — back up and replace.

Automating warnings with smartd

Checking by hand is fine, but you will forget. The smartd daemon — installed alongside smartctl — watches every drive around the clock and warns you automatically the moment an attribute degrades, so you are not relying on remembering to look.

Enable and start the service (the unit is smartd on most systems, smartmontools on Debian/Ubuntu):

# Most distros (Arch, Fedora, openSUSE)
sudo systemctl enable --now smartd

# Debian / Mint / Ubuntu
sudo systemctl enable --now smartmontools

Its behaviour comes from /etc/smartd.conf. The simplest useful configuration is a single line that tells it to scan every drive, monitor all attributes, and email you on trouble. Edit the file:

sudoedit /etc/smartd.conf

and make sure it contains a DEVICESCAN line like this (replace the address with your own):

# scan all drives; -a = monitor everything; -m = email on failure;
# -M test sends one test mail now so you can confirm delivery works
DEVICESCAN -a -m you@example.com -M test

To also run scheduled self-tests automatically, add a -s schedule. Its argument is a pattern — S/L for short/long test, then regex-like fields for month, day, hour:

# short self-test every day at 2am, long self-test every Saturday at 3am
DEVICESCAN -a -m you@example.com -s (S/../.././02|L/../../6/03)

Reload the service after editing, then confirm it picked up your drives:

# reload the service (use smartmontools instead of smartd on Debian/Ubuntu)
sudo systemctl restart smartd
# watch its log to confirm it found and is monitoring your disks
journalctl -u smartd -b

Tip: smartd emails through the local mail system, so the -m address only works if your machine can actually send mail. On a desktop that often is not set up; people commonly point -M exec at a script that sends a desktop notification or a message to their phone instead. At minimum, the journalctl log above records every warning even if email is not configured.

SMART through a USB enclosure

External drives and USB-to-SATA adapters add a translation layer that often hides SMART, so a plain smartctl -a /dev/sdb may report that SMART is unavailable. The fix is the -d flag (for device type), which tells smartctl how to tunnel SMART commands through the bridge chip. Try these in order:

# most common: SAT (SCSI/ATA Translation) over the USB bridge
sudo smartctl -d sat -a /dev/sdb

# some JMicron-based enclosures need their own type
sudo smartctl -d usbjmicron -a /dev/sdb

# let smartctl probe and report what it thinks the bridge is
sudo smartctl --scan

Tip: enclosures from different makers use different bridge chips, so if one -d type fails, try the next. The smartmontools project maintains a USB device database, and the right -d value for a known enclosure is often listed there. Some cheap bridges block SMART entirely — in that case, plug the bare drive into a SATA port to read it.

The verdict: when to replace a drive

Pulling it together — here is when a drive has crossed from "fine" to "get your data off it":

• Replace immediately if smartctl -H reports FAILED, if a self-test ends in read failure, or if Reallocated_Sector_Ct, Current_Pending_Sector, or Offline_Uncorrectable are non-zero and climbing between checks.
• Plan a replacement if those counts are non-zero but stable, if an SSD's Percentage_Used is near or past 100, or if NVMe available_spare is approaching its threshold. The drive may last a while, but it has shown its weakness.
• Just fix the cable if the only thing climbing is UDMA_CRC_Error_Count — that is a connection problem, not a dying drive.
• Carry on if everything is zero, self-tests pass, and the only large numbers are benign counters like Power_On_Hours.

Warning: if a drive is already failing — bad sectors climbing, read errors, dropping offline — do not keep hammering it. Every read risks the heads on a struggling disk. Make a byte-for-byte image with GNU ddrescue first, then work from the copy. See the file-recovery guide for exactly that: sudo ddrescue -d -r3 /dev/sdX /mnt/backup/rescue.img /mnt/backup/rescue.map images the disk while skipping and retrying bad sectors, so you recover from a safe clone instead of stressing the dying original.

The real lesson is that SMART buys you time. A drive rarely fails without first dropping a hint in its attributes or a self-test. Watch for the hint, keep current backups, and a failing disk becomes a routine swap instead of a data-loss emergency.

Quick reference

• lsblk -d -o NAME,SIZE,MODEL,TRAN — find the right drive first.
• sudo smartctl -i /dev/sda — identity; check SMART is Available and Enabled.
• sudo smartctl -s on /dev/sda — enable SMART if it is off.
• sudo smartctl -H /dev/sda — quick PASSED/FAILED verdict (treat PASSED with caution).
• sudo smartctl -a /dev/sda — full report and attribute table (-x for everything).
• Watch RAW values of 5 Reallocated, 197 Current_Pending, 198 Offline_Uncorrectable — non-zero and rising means back up now.
• SSD: Percentage_Used / Wear_Leveling_Count; NVMe: sudo nvme smart-log /dev/nvme0 (percentage_used, available_spare, media_errors).
• sudo smartctl -t short /dev/sda / -t long, then sudo smartctl -l selftest /dev/sda — run and read self-tests.
• sudo systemctl enable --now smartd + DEVICESCAN -a -m … in /etc/smartd.conf — automatic warnings.
• USB enclosure hiding SMART? Add -d sat (or -d usbjmicron).
• Already failing? Image it with ddrescue first, then recover from the copy.