5 Best Free Hard Drive Health Check Tools for Linux (HDDs and SSDs)

The best free Linux tools for checking hard drive and SSD health are smartmontools (smartctl and smartd), nvme-cli, GSmartControl, Scrutiny, and badblocks. Together they read S.M.A.R.T. data and NVMe health logs, run drive self-tests, track health over time, and scan for unreadable blocks. This guide explains what each tool does, gives the exact commands, and shows how to read the results for SATA HDDs, SATA SSDs, and NVMe SSDs.

Versions checked: smartmontools 7.5, GSmartControl 2.0.2, nvme-cli 2.x, Scrutiny 0.9.x. Running Windows instead? Read our companion guide: 5 Best Free Hard Drive Health Check Software Tools for HDDs and SSDs.

Key Takeaways

• Start with smartmontools. It covers SATA, SAS, NVMe, USB bridges, and many RAID controllers, and it works in scripts and as a background monitor.
• Use nvme-cli when you want the NVMe controller’s own health log with no translation layer in between.
• Use GSmartControl for a graphical view of the same smartctl data.
• Use Scrutiny when you manage several drives or servers and want history, a dashboard, and alerts.
• Use badblocks only to burn in new or empty HDDs. Never run its write test on a drive that holds data, and never run it on an SSD.
• A “PASSED” result is weak evidence. Google’s study of more than 100,000 drives found that over 56% of failed drives had no count in four strong SMART signals. Backblaze found that 23.3% of failed drives showed no warning in its five tracked attributes. Keep verified backups.

Table of Contents

1. What S.M.A.R.T. Is and What Linux Reads
2. Quick Comparison of the Five Tools
3. 1. smartmontools: Best Overall
4. 2. nvme-cli: Best for NVMe SSDs
5. 3. GSmartControl: Best Graphical Tool
6. 4. Scrutiny: Best for Dashboards and Trends
7. 5. badblocks: Best for HDD Burn-In
8. Which Tool Should You Use?
9. A Five-Minute Drive Health Check on Linux
10. How to Read the Results
11. What S.M.A.R.T. Cannot Tell You
12. Automate Checks with smartd
13. USB Enclosures, RAID Controllers, and Virtual Machines
14. Also Considered
15. What to Do When a Drive Looks Bad
16. Frequently Asked Questions
17. How This List Was Built
18. References and Official Sources

What S.M.A.R.T. Is and What Linux Reads

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) is a monitoring system built into drives. The drive firmware counts internal events, such as remapped sectors and read errors, and exposes those counters to the host.

• SATA and SAS drives report a table of numbered attributes. Each attribute has a normalized value, a worst value, a threshold, and a raw value.
• NVMe SSDs report a standardized SMART / Health Information log. Its fields, such as Critical Warning, Percentage Used, and Available Spare, have the same meaning on every vendor’s drive.
• Drives can also run self-tests on their own. A short test takes about two minutes on many drives. An extended test reads the whole surface and can take hours.
• Linux tools read this data through the kernel’s ATA, SCSI, and NVMe drivers. They need root privileges, so every command in this guide uses sudo.

Quick Comparison of the Five Tools

Tool	Best for	Interface	SATA / SAS	NVMe	Self-tests	Alerts	License
smartmontools	Everything: one-off checks, scripts, servers	CLI and daemon	Yes	Yes	Yes (NVMe since 7.4)	Yes, through smartd	GPL
nvme-cli	NVMe logs and NVMe self-tests	CLI	No	Yes	Yes, if the drive supports them	No	GPL
GSmartControl	Graphical inspection	Desktop GUI	Yes	Yes	Yes	No	GPLv3
Scrutiny	History, dashboards, alerts	Web UI and collector	Yes	Yes	No (monitoring only)	Yes	MIT
badblocks	HDD burn-in and surface scans	CLI	Any block device	Not recommended	No (it is a block-level test)	No	Open source (e2fsprogs)

Important: A drive that reports good health can still fail without warning. Keep independent, verified backups of data you cannot replace.

1. smartmontools: Best Overall Free Linux Drive Health Tool

• Official source: smartmontools.org
• Best for: administrators who need accurate data, scripting, and automatic monitoring.
• Components: smartctl queries a drive and starts tests. smartd is a daemon that polls drives and sends alerts.
• Version checked: 7.5 (released April 30, 2025). Some distributions ship 7.4 or older, so run smartctl --version to confirm what you have.
• Package size: small. Fedora’s package, for example, is about 2 MB.

Why smartmontools is the reference tool

• It supports ATA/SATA, SCSI/SAS, and NVMe drives, plus many USB bridges and RAID controllers.
• It ships a drive database (drivedb.h) that decodes vendor-specific attributes. Many other programs show raw numbers without that context.
• It prints machine-readable JSON with the -j option (smartmontools 7.0 and newer).
• GSmartControl, Scrutiny, KDE’s Plasma Disks, and several monitoring agents all call smartctl underneath.

Install smartmontools

# Debian, Ubuntu
sudo apt install smartmontools

# Fedora, RHEL and derivatives
sudo dnf install smartmontools

# Arch Linux
sudo pacman -S smartmontools

# Refresh the drive database if your package is old
sudo update-smart-drivedb

Essential smartctl commands

# List drives and detected types (opens each device)
sudo smartctl --scan-open

# Identity: model, serial, firmware, rotation rate, SMART support
sudo smartctl -i /dev/sda

# Overall health verdict
sudo smartctl -H /dev/sda

# Attribute table (SATA) or health log (NVMe)
sudo smartctl -A /dev/sda

# Everything smartctl can read
sudo smartctl -x /dev/sda

# Error log and self-test log
sudo smartctl -l error /dev/sda
sudo smartctl -l selftest /dev/sda

# Capabilities and estimated test durations
sudo smartctl -c /dev/sda

# Start a short or extended self-test, or abort a running one
sudo smartctl -t short /dev/sda
sudo smartctl -t long /dev/sda
sudo smartctl -X /dev/sda

# NVMe drives use the same commands on the controller device
sudo smartctl -a /dev/nvme0

Use the exit status in scripts

smartctl returns a bitmask. Each set bit points to a specific condition, so scripts can react without parsing text.

Bit	Value	Meaning
0	1	The command line did not parse.
1	2	The device did not open, did not answer IDENTIFY, or is in a low-power mode.
2	4	A SMART command failed, or a SMART data structure had a checksum error.
3	8	The SMART status check returned DISK FAILING.
4	16	A pre-fail attribute is at or below its threshold.
5	32	The status is OK, but an attribute was at or below its threshold in the past.
6	64	The error log contains errors.
7	128	The self-test log contains errors.

sudo smartctl -a /dev/sda > /dev/null; rc=$?
(( rc & 8 ))   && echo "SMART status: DISK FAILING"
(( rc & 16 ))  && echo "A pre-fail attribute is at or below its threshold"
(( rc & 64 ))  && echo "The error log contains errors"
(( rc & 128 )) && echo "The self-test log contains errors"

Read JSON with jq

# Overall verdict as true or false
sudo smartctl -j -H /dev/sda | jq '.smart_status.passed'

# The five attributes Backblaze tracks (SATA HDD or SSD)
sudo smartctl -j -A /dev/sda | jq -r '.ata_smart_attributes.table[] | select(.id==5 or .id==187 or .id==188 or .id==197 or .id==198) | "\(.id) \(.name) raw=\(.raw.value)"'

# Key NVMe health fields
sudo smartctl -j -a /dev/nvme0 | jq '.nvme_smart_health_information_log | {critical_warning, percentage_used, available_spare, available_spare_threshold, media_errors, unsafe_shutdowns}'

Advantages

• Widest hardware coverage of any free tool.
• Accurate attribute names through the drive database.
• Scriptable, with JSON output and a documented exit status.
• Includes a monitoring daemon (smartd).
• Available in the repositories of nearly every distribution.

Limitations

• The interface is a command line, and raw values need interpretation.
• USB enclosures often need an explicit device type (see the USB section below).
• Distribution packages can lag behind the current release.
• Virtual disks and some RAID setups do not expose SMART data.

Verdict: smartmontools is the best free Linux drive health tool. Install it first, even if you plan to use a graphical tool later.

2. nvme-cli: Best Free Tool for NVMe SSD Health

• Official source: github.com/linux-nvme/nvme-cli
• Best for: reading the NVMe SMART / Health Information log exactly as the controller reports it.
• Version checked: the nvme-cli 2.x series. Ubuntu 25.04, for example, ships 2.11.

nvme-cli is the Linux NVMe community’s own command-line tool. It talks to the controller through the kernel’s NVMe driver. The NVMe standard defines the health log fields, so the output means the same thing on every vendor’s SSD.

Install and run nvme-cli

# Debian, Ubuntu
sudo apt install nvme-cli

# Fedora, RHEL and derivatives
sudo dnf install nvme-cli

# List NVMe devices
sudo nvme list

# Read the SMART / Health Information log
sudo nvme smart-log /dev/nvme0

# The same data as JSON (temperature is reported in Kelvin)
sudo nvme smart-log /dev/nvme0 -o json

# Read the error log
sudo nvme error-log /dev/nvme0

# Show the temperature thresholds and optional-command support
sudo nvme id-ctrl /dev/nvme0 | grep -E 'oacs|wctemp|cctemp'

Run an NVMe self-test

The Device Self-test command is optional in the NVMe standard. Check bit 4 (value 0x10) of the oacs field from nvme id-ctrl. If that bit is set, the drive supports self-tests.

# Short self-test (self-test code 1)
sudo nvme device-self-test /dev/nvme0 -s 1

# Extended self-test (self-test code 2)
sudo nvme device-self-test /dev/nvme0 -s 2

# Read the results
sudo nvme self-test-log /dev/nvme0

# Abort a running test (self-test code 0xf)
sudo nvme device-self-test /dev/nvme0 -s 0xf

Advantages

• Reports the controller’s log pages directly, with no translation layer.
• Works the same way on every NVMe vendor.
• Includes JSON output for scripts.
• Offers vendor plugins for extended logs on some drives.

Limitations

• It supports NVMe only. SATA and SAS drives need smartctl.
• It does not store history or send alerts.
• The error log can include harmless host command errors, so read the entries before you worry about the count.

Verdict: Use nvme-cli to confirm what an NVMe SSD reports. Pair it with smartctl for a second opinion and for scheduled monitoring.

3. GSmartControl: Best Free Graphical Drive Health Tool

• Official source: gsmartcontrol.shaduri.dev
• Best for: desktop users and technicians who want smartctl’s full data in a window.
• Version checked: 2.0.2 (released February 2025). License: GPLv3.

GSmartControl is a graphical front end for smartctl. It needs smartmontools installed, and it inherits smartctl’s drive database. It highlights anomalies automatically, so you do not have to know every attribute by heart.

Key features

• Shows drive identity, capabilities, attributes, and device statistics.
• Starts and reads SMART self-tests.
• Lets you set global and per-drive smartctl options.
• Reads a saved smartctl output file as a read-only virtual drive. This helps when you review a report from another machine.
• Supports ATA drives, NVMe drives, various USB-to-ATA bridges, and drives behind some RAID controllers.
• Runs on Linux, Windows, macOS, and FreeBSD.

Install GSmartControl

# Debian, Ubuntu
sudo apt install smartmontools gsmartcontrol

# Fedora
sudo dnf install smartmontools gsmartcontrol

# Arch Linux
sudo pacman -S smartmontools gsmartcontrol

Most distributions package GSmartControl. The project’s download page also links to its own build repository for newer packages, and the GParted Live image includes the tool.

Advantages

• Easier to read than raw smartctl output.
• Accurate attribute names, because it uses smartctl.
• Good for troubleshooting a drive with ambiguous warnings.

Limitations

• It is an inspection tool. It does not run in the background or send alerts.
• It needs a desktop session and root privileges.
• USB bridges and RAID controllers still depend on smartctl support.

Verdict: GSmartControl is the best graphical choice on Linux. Use it for hands-on checks, and use smartd or Scrutiny for monitoring.

4. Scrutiny: Best Free Dashboard for Drive Health Trends

• Official source: github.com/AnalogJ/scrutiny
• Best for: home labs, NAS builders, and administrators who watch many drives.
• Version checked: the 0.9 release series. License: MIT.

Scrutiny adds what smartctl lacks: history, a web dashboard, and alerts. A collector runs smartctl on each host and sends the results to a web service. The service stores them in InfluxDB. Scrutiny then highlights the attributes that matter and applies thresholds based on real-world failure rates. The project explains why: manufacturer thresholds are sometimes unset, or so high that they only confirm a drive that has already failed.

Key features

• A web dashboard that focuses on critical metrics.
• Automatic detection of connected drives through smartctl --scan.
• Historical charts, so you can see whether an attribute rises slowly.
• Temperature tracking.
• Notifications through email, webhooks, and many chat and push services.
• A hub-and-spoke mode: one web service and one collector on each server.
• Docker images, plus a manual install without Docker.

Run Scrutiny with Docker

The commands below adapt the project’s README example. Replace PINNED_VERSION with a current release tag from the project’s package list. The README advises against the moving latest tags.

docker run -d --name scrutiny --restart unless-stopped \
  -p 8080:8080 -p 8086:8086 \
  -v /run/udev:/run/udev:ro \
  -v "$(pwd)/scrutiny:/opt/scrutiny/config" \
  -v "$(pwd)/influxdb2:/opt/scrutiny/influxdb" \
  --cap-add SYS_RAWIO \
  --device=/dev/sda --device=/dev/sdb \
  ghcr.io/analogj/scrutiny:PINNED_VERSION-omnibus

# NVMe drives also need: --cap-add SYS_ADMIN and the NVMe device nodes

# Trigger the first collection by hand (it runs daily at midnight by default)
docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run

Open http://localhost:8080 to see the dashboard. Pass every device that smartctl --scan lists on the host into the container.

Advantages

• The only tool in this list that keeps history and draws trends.
• Alerts reach you through the services you already use.
• Reuses smartctl, so it supports the same drives.

Limitations

• It needs Docker (or a manual install) and an InfluxDB database.
• The collector runs once a day by default. Change the schedule for faster detection.
• The project’s own README calls it a work in progress with some rough edges.
• It monitors drives. It does not run self-tests.
• It detects drives with smartctl --scan. In some cases that scan reports the wrong device type and returns incomplete SMART data. Scrutiny lets you override the type in collector.yaml.
• Inside a container, you must pass each drive (and each RAID virtual disk) through with --device.

Verdict: Choose Scrutiny when you want one page that shows the health of every drive you own. For Prometheus and Grafana users, our guide to monitoring with Grafana and Prometheus covers a similar stack.

5. badblocks: Best Free Tool for HDD Burn-In and Surface Scans

• Official source: part of e2fsprogs, preinstalled on most distributions.
• Best for: testing a new or empty hard drive before you trust it with data.

badblocks writes to or reads from every block of a device and reports the blocks that fail. It does not read S.M.A.R.T. data. It tests the drive through ordinary block reads and writes.

The three modes

• Read-only (default): reads every block. It does not change data.
• -n non-destructive read-write: reads each block, writes test patterns, and restores the original data. It is slow and needs an unmounted device.
• -w destructive write: writes four patterns (0xaa, 0x55, 0xff, 0x00) to every block and reads each one back. It destroys all data.

# Identify the device first. A wrong name here destroys the wrong drive.
lsblk -d -o NAME,MODEL,SERIAL,SIZE

# Read-only scan. Set -b 4096 for modern drives and large capacities.
sudo badblocks -b 4096 -sv /dev/sdX

# Destructive write test. ERASES EVERYTHING. New or empty drives only.
sudo badblocks -b 4096 -wsv /dev/sdX

• -s shows progress and -v prints verbose results.
• badblocks uses 32-bit block numbers, so very large drives need a larger -b value than the 1024-byte default.
• badblocks refuses to test a mounted device unless you add -f. Do not override that check on a device that holds data.

How long does a write test take?

The write test makes eight full passes: four patterns, each written and then read back. For an 8 TB drive at 180 MB/s sequential speed, one pass takes about 12 hours. Eight passes take roughly four days. Plan for that before you start.

A common burn-in routine for a new HDD

1. Run sudo smartctl -t long /dev/sdX and read the result.
2. Run sudo badblocks -b 4096 -wsv /dev/sdX.
3. Run another extended smartctl test.
4. Check attributes 5, 197, and 198. All three raw values should still be zero.

Limitations

• Do not use it on SSDs. A write test spends endurance, and a read scan cannot see the physical flash. An SSD controller translates block addresses and manages bad blocks internally. For SSDs, use SMART data and the drive’s own extended self-test instead.
• Modern drives remap bad sectors themselves. badblocks results rarely map to a filesystem-level bad block list anymore.
• Heavy reads on a drive that is already failing can make it worse. Image the drive first (see the failing drive section).

Verdict: badblocks remains a useful burn-in tool for new HDDs. For everyday health checks, use smartctl’s extended self-test instead.

Which Tool Should You Use?

Situation	Recommended tool
Quick health check of a SATA drive	smartctl
Quick health check of an NVMe SSD	nvme smart-log or smartctl
Graphical view on a desktop	GSmartControl
Automatic email alerts on a server	smartd
Dashboard and history for several drives or hosts	Scrutiny
Test a new HDD before use	smartctl extended test, then badblocks
Check a drive in a USB enclosure	smartctl with -d sat or an NVMe bridge type
Check a drive behind a hardware RAID controller	smartctl with -d megaraid,N (or the matching controller type)
Script health checks and parse the results	smartctl -j with jq

Fresh server builds can include these packages in a standard baseline. Our post-installation Linux setup checklist is a good place to add them.

A Five-Minute Drive Health Check on Linux

1. Identify the drives. In the output, ROTA=1 marks a rotating HDD and TRAN shows the interface:

   lsblk -d -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN

2. Read the overall verdict and key counters. This script prints the most important signals for every drive smartctl can open:

   #!/usr/bin/env bash
   # disk-health-summary.sh - run as root
   smartctl --scan-open | while read -r dev _ type _; do
     echo "=== ${dev} (${type}) ==="
     smartctl -H -A -d "${type}" "${dev}" 2>/dev/null | grep -E \
       'overall-health|SMART Health Status|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Reported_Uncorrect|Command_Timeout|UDMA_CRC_Error_Count|Critical Warning|Percentage Used|Available Spare|Media and Data Integrity Errors|Unsafe Shutdowns|Temperature'
   done

3. Check the kernel log for I/O errors and link resets in the last boots:

   sudo journalctl -k -b -p err | grep -Ei 'ata[0-9]|nvme|i/o error|blk_update'

4. Run a short self-test. Wait for the estimated time, then read the log:

   sudo smartctl -t short /dev/sda
   sudo smartctl -l selftest /dev/sda

5. Decide. If any counter in the next section looks bad, back up first, then investigate.

Tip: smartctl --scan lists device nodes without probing them, and it often labels SATA disks as -d scsi. smartctl --scan-open opens each device and reports the detected type, such as -d sat or -d nvme. Prefer --scan-open when you copy device types into scripts.

How to Read the Results

SATA and SAS HDD attributes that matter

Attribute names and numbers are not fully standardized. Not every vendor reports every attribute, so check the names that your drive prints.

ID	Name	What it means	What to do
5	Reallocated_Sector_Ct	Sectors remapped to spare area.	Any nonzero value deserves attention. A rising count means ongoing damage. Plan a replacement.
187	Reported_Uncorrect	Reads that error correction could not fix.	Backblaze schedules a drive for replacement once this value passes zero. Not every vendor reports it.
188	Command_Timeout	Commands that timed out or were aborted.	Can point to the drive, the cable, or the power supply. Check all three.
197	Current_Pending_Sector	Unstable sectors that wait for a remap.	Back up now and run an extended test. This counter can fall again, unlike the cumulative ones.
198	Offline_Uncorrectable	Uncorrectable errors found during offline scans.	Treat any nonzero value like a pending sector. Back up and test.
199	UDMA_CRC_Error_Count	Data corruption on the SATA link.	Usually a cable, port, or connector problem. Reseat or replace the cable, then watch whether the count still rises.
194 / 190	Temperature_Celsius / Airflow_Temperature_Cel	Drive temperature.	Compare with the manufacturer’s limit. Fix cooling if the drive runs hot.

Pay attention to the trend as well as the value. A counter that jumps by 20 in one day is more alarming than one that grew by one a month for five years. The normalized VALUE column counts down as a drive degrades. When a pre-fail attribute falls to its THRESH value, smartctl reports failure.

NVMe SMART / Health Information fields

Field	Meaning	What to do
Critical Warning	A bit field: bit 0 spare capacity below threshold, bit 1 temperature outside limits, bit 2 reliability degraded, bit 3 media is read-only, bit 4 volatile memory backup failed, bit 5 persistent memory region unreliable.	Any nonzero value needs action. Back up and plan a replacement.
Available Spare / Available Spare Threshold	Remaining spare capacity as a percentage, and the level that triggers a warning.	A value near or below the threshold means the drive is nearly out of reserve.
Percentage Used	The vendor’s estimate of consumed endurance. It can exceed 100.	100 does not mean immediate failure. Treat 80 or more as a prompt to plan a replacement. This is a practical guideline, not a vendor rule.
Media and Data Integrity Errors	Unrecovered data integrity errors.	Back up and investigate any nonzero value.
Unsafe Shutdowns	Power losses without a shutdown notice.	A rising count points to power or cable problems.
Data Units Written	Counted in units of 1,000 x 512 bytes (512,000 bytes).	Multiply by 512,000 for bytes, and compare with the drive’s rated endurance (TBW).
Temperature, Warning and Critical Temperature Time	Composite temperature and minutes spent above the warning and critical thresholds.	Compare with wctemp and cctemp from nvme id-ctrl. Add airflow or a heatsink if the drive throttles.

SATA SSD notes

• Wear attributes vary by brand. Examples include Wear_Leveling_Count (ID 177 on many Samsung drives), Media_Wearout_Indicator (ID 233 on Intel drives), and Percent_Lifetime_Remain (ID 202 on Crucial and Micron drives). The same ID can mean different things on different brands.
• Read the normalized value. It usually starts near 100 and falls as the drive wears.
• Try smartctl -x. When a SATA SSD supports the standard Device Statistics log, it can show a vendor-neutral endurance indicator.

What S.M.A.R.T. Cannot Tell You

S.M.A.R.T. is an early-warning system. It is not a guarantee. Two large field studies show both its value and its limits.

• Google (2007). Researchers studied more than 100,000 consumer ATA hard drives. After a drive’s first scan error, it was 39 times more likely to fail within 60 days. After the first reallocation, the risk was over 14 times higher. Even so, over 56% of failed drives had no count in any of four strong SMART signals. Over 36% of failed drives had zero counts on all SMART variables except temperature. The authors concluded that SMART alone is unlikely to predict individual drive failures.
• Backblaze (2016). Backblaze tracks five attributes: 5, 187, 188, 197, and 198. Among its failed drives, 76.7% had at least one of the five above zero. Only 4.2% of operational drives did. That leaves 23.3% of failures with no warning in those five attributes.

How to use these numbers correctly

• Both studies cover hard drives. The Google data comes from consumer drives of 80 to 400 GB, observed in 2005 and 2006. Neither study measures SSD failure prediction.
• Backblaze’s “failure” includes pre-emptive replacement. The company schedules a drive for replacement once SMART 187 passes zero. That choice makes the attribute look more predictive in its own data.
• Backblaze notes that most tracked counters are cumulative, except 197. Time matters. One error per month over five years differs from 20 errors in one day.
• A PASSED verdict is the weakest signal. The drive only reports FAILED after a pre-fail attribute crosses a manufacturer threshold, and many failing drives never reach it.
• Add other signals. Kernel log errors, filesystem checksum errors, and slow responses all carry information that SMART misses.

Complementary checks on Linux

• ZFS: sudo zpool scrub POOL reads every block and verifies checksums.
• Btrfs: sudo btrfs scrub start -B /mountpoint does the same for Btrfs volumes.
• Linux software RAID: echo check | sudo tee /sys/block/md0/md/sync_action starts a consistency check of an md array.
• Backups: test restores on a schedule. A backup that you never restored is an assumption.

Automate Checks with smartd

smartd runs as a service. It polls each drive (every 30 minutes by default), watches for changes, runs scheduled self-tests, and sends alerts. Edit /etc/smartd.conf on Debian, Ubuntu, and Arch. On Fedora and RHEL, edit /etc/smartmontools/smartd.conf.

# Monitor every detected drive.
# Run a short self-test daily at 02:00 and an extended test every Sunday at 03:00.
# Skip drives in standby, warn on temperature changes of 4 C, at 45 C, and at 55 C.
# Mail root when something changes.
DEVICESCAN -a -n standby,q -s (S/../.././02|L/../../7/03) -W 4,45,55 -m root

• -a turns on the standard set of checks: health status, attribute changes, the error log, the self-test log, and the 197 and 198 sector counters.
• -s takes a regular expression in the form T/MM/DD/d/HH. T is S (short) or L (long), and d is the weekday from 1 (Monday) to 7 (Sunday).
• -W DIFF,INFO,CRIT sets the temperature rules.
• -m sends mail, which needs a working local mail setup. Use -M exec /path/to/script to run your own script instead, for example to call a webhook.
• Add -M test once to send a test message and confirm delivery, then remove it.
• Self-test scheduling for NVMe drives needs a current smartmontools release. Check the NEWS file of your version.

# Check the configuration once and exit
sudo smartd -q onecheck

# Enable the service (Debian and Ubuntu name the unit smartmontools, with smartd as an alias)
sudo systemctl enable --now smartd

# Read the log
sudo journalctl -u smartd

Send smartd’s syslog output to a central server if you run more than one machine. Our Linux syslog server guide shows the receiving side.

USB Enclosures, RAID Controllers, and Virtual Machines

USB enclosures

• Many USB-to-SATA bridges pass SMART commands through the SAT protocol: sudo smartctl -d sat -a /dev/sdb.
• Recent smartmontools releases also support several USB-to-NVMe bridge chipsets, with types such as -d sntjmicron, -d sntasmedia, and -d sntrealtek.
• Some bridges block these commands. If every type fails, connect the drive directly to a SATA or NVMe port.
• GNOME Disks does not show ATA SMART data for USB drives. After many bug reports of kernel errors that sometimes disconnected the USB device, the UDisks developers disabled their ATA probes for USB devices.

Hardware RAID controllers

• Address each physical drive with the controller’s device type. Examples: sudo smartctl -a -d megaraid,0 /dev/sda, -d cciss,0, and -d 3ware,0.
• Not every controller passes SMART data through. Plain host bus adapters, and controllers in pass-through mode, usually expose each drive directly.

Virtual machines

• Virtual disks do not normally expose SMART data. Run smartctl on the hypervisor host.
• If a VM must read SMART data, pass the physical disk or its controller through to the VM.

Also Considered

• GNOME Disks. The app shows SMART data and runs self-tests through the UDisks service. By default, UDisks reads ATA SMART data through libatasmart. The UDisks developers state that libatasmart is unmaintained upstream and has no internal drive database, so it can report false values for some attributes. Attributes that UDisks cannot map appear under generic names such as attribute-171. UDisks reads NVMe health information through a separate libblockdev NVMe plugin, and it polls SMART data on a fixed 10-minute interval. Use GNOME Disks for a quick look and confirm anything important with smartctl. The UDisks developers also offer an experimental plugin that calls smartctl, but it is not the default.
• KDE Plasma Disks. This Plasma service reads SMART data through smartctl, adds a page to KInfoCenter, and sends notifications when a drive looks bad. It suits KDE desktops. See the project page.
• openSeaChest. Seagate publishes these open-source command-line utilities for Linux. They support SATA, SAS, NVMe, and USB drives and include a SMART tool. Some functions change drive settings or firmware, so read the documentation before you use them.
• Solidigm Storage Tool. The command-line version runs on Linux (deb and rpm packages). It reports health, SMART attributes, and diagnostic scans for Solidigm SSDs.
• Monitoring stacks. Zabbix, Netdata, and Prometheus exporters can ingest smartctl data. They suit teams that already run those platforms.
• hdparm. It reads identity data and changes ATA settings. It is not a health tool.

What to Do When a Drive Looks Bad

1. Back up first. Copy irreplaceable data to a healthy drive before you run any further test.
2. Image a drive that shows read errors. GNU ddrescue copies the readable data first and retries the bad areas later:

   sudo ddrescue -n /dev/sdX /mnt/backup/sdX.img /mnt/backup/sdX.map

3. Save the evidence. Store the output of smartctl -x and the kernel log. Warranty claims often need it.
4. Rule out the cable and port. Rising CRC errors (attribute 199) and link resets in the kernel log often come from cables, ports, or power.
5. Run an extended self-test once your data is safe.
6. Replace the drive if it keeps reporting pending sectors, uncorrectable errors, a nonzero NVMe Critical Warning, or failed self-tests. If the drive belongs to a RAID or ZFS pool, use your platform’s replace procedure.

Formatting does not repair failing hardware, and software cannot reverse physical wear.

Frequently Asked Questions

What is the best free tool to check hard drive health on Linux?

smartmontools is the best overall choice. Its smartctl command reads SATA, SAS, and NVMe drives, and its smartd daemon monitors them in the background. Add GSmartControl for a graphical view or Scrutiny for a dashboard.

How do I check SSD health on Linux?

For an NVMe SSD, run sudo nvme smart-log /dev/nvme0 or sudo smartctl -a /dev/nvme0. Check Critical Warning, Percentage Used, Available Spare, and Media and Data Integrity Errors. For a SATA SSD, run sudo smartctl -x /dev/sda and look for the wear attribute that your brand reports.

Can I check drive health without installing anything?

Only partly. The kernel log shows I/O errors and link resets: sudo journalctl -k -p err. For SMART data, install smartmontools. The package is about 2 MB.

Is a SMART “PASSED” result enough to trust a drive?

No. The drive reports FAILED only after a manufacturer threshold is crossed. Google found over 56% of failed drives with no count in four strong SMART signals. Backblaze found 23.3% of failures with no warning in five tracked attributes. Look at the individual counters, and keep backups.

How often should I run self-tests?

A common schedule is a short test every day and an extended test every week or month. The smartd example in this guide uses that pattern. A self-test runs inside the drive and the drive stays usable, but speed can drop during an extended test. Schedule it for off-hours on busy servers.

Does smartctl work on USB drives?

Often, with the right device type. Try -d sat first. Some USB bridges do not pass SMART commands at all.

Can I use badblocks on an SSD?

No. The write test uses up endurance, and block-level reads cannot see the state of the flash. Use SMART data and the drive’s extended self-test instead.

Does 100% Percentage Used mean my NVMe SSD is dead?

No. It means the drive has used the endurance that the vendor estimated. Many drives keep working beyond that point, but the margin for error is gone. Back up and plan a replacement.

Why does smartctl show different attribute names than another tool?

Attribute names are not standardized, and tools differ in how they decode them. smartctl uses a maintained drive database. Tools without one can show generic or wrong names for some drives.

Can I read SMART data inside a virtual machine?

Usually not. Run smartctl on the host, or pass the physical disk or controller through to the VM.

How This List Was Built

This guide ranks tools against six criteria:

1. Accuracy: does the tool decode drive data correctly, and does it document its sources?
2. Coverage: does it support SATA, SAS, NVMe, and common enclosures?
3. Maintenance: does the project publish releases and fix bugs?
4. Automation: can you script it or run it on a schedule?
5. Cost and license: is it free, with an open license?
6. Availability: can you install it from standard distribution repositories?

The author did not run hardware benchmarks for this article. Each statement comes from project documentation, manual pages, vendor pages, or the primary research cited below. Facts were checked in October 2026. Package versions differ between distributions, so confirm behavior on your own system with the commands shown.

References and Official Sources

1. smartmontools project. Downloads, documentation, news, and the smartd.conf manual. smartmontools.org and smartd.conf manual page
2. nvme-cli. Source and documentation. github.com/linux-nvme/nvme-cli and the nvme-device-self-test manual page
3. libnvme documentation. Structure of the NVMe SMART / Health Information log. nvme_smart_log manual page
4. NVM Express. NVMe specifications. nvmexpress.org/specifications
5. GSmartControl. Project site and downloads. gsmartcontrol.shaduri.dev and source repository
6. Scrutiny. README, features, and Docker instructions. github.com/AnalogJ/scrutiny
7. e2fsprogs. The package that provides badblocks. e2fsprogs.sourceforge.net
8. Storaged Project (UDisks). “ATA SMART in libblockdev and UDisks,” January 30, 2026. storaged.org
9. Pinheiro, Weber, and Barroso (2007). “Failure Trends in a Large Disk Drive Population,” USENIX FAST. USENIX
10. Backblaze (2014). “Hard Drive SMART Stats.” backblaze.com
11. Backblaze (2016). “What SMART Stats Tell Us About Hard Drives.” backblaze.com
12. KDE Plasma Disks. invent.kde.org/plasma/plasma-disks
13. openSeaChest (Seagate). github.com/Seagate/openSeaChest
14. Solidigm Storage Tool. solidigm.com

Technical note: Diagnostic capabilities vary by drive model, firmware, interface, controller, kernel, and software version. Not every feature in this guide works on every drive. Run the commands as root, double-check device names before any write test, and keep verified backups.