How to Monitor S.M.A.R.T. Drive Health on Ubuntu via Email Alerts

Ubuntu 26.04 LTS currently offers smartmontools 7.5-2 in its package repository. The package includes smartctl, which reads drive health data, and smartd, a background service that watches for selected changes and can send email. S.M.A.R.T. means Self-Monitoring, Analysis and Reporting Technology. Before configuring email alerts, first confirm that Ubuntu can read S.M.A.R.T. data from each drive; a message cannot be sent for a device the system cannot monitor.

This guide sets up a monitor on a single Ubuntu desktop and sends a test email before relying on alerts. It assumes the computer has a working route to an SMTP relay, the service that accepts outgoing email for delivery. A desktop mail app by itself does not provide that service.

What can a S.M.A.R.T. alert tell you?

S.M.A.R.T. is drive-reported health and error information. It can reveal warning conditions such as a failed health check, increasing errors, or certain self-test results. It is an early warning system, not a promise that the drive will predict every failure. A drive may stop working without a useful warning, and a “PASSED” result does not prove that every file is readable. Keep a separate backup of important data.

The values also depend on drive type and firmware. SATA hard drives and SSDs often show attribute tables; NVMe drives report health information in a different format. Do not compare raw attribute numbers across manufacturers or treat one generic threshold as universal.

What should you prepare before setup?

• An Ubuntu account with administrator access.
• The package repositories enabled and an internet connection for installation.
• The address that should receive alerts.
• An SMTP relay you are authorized to use, such as a provider or organization’s authenticated mail server, with its host, port, TLS requirements, and credentials.
• A current backup before running drive diagnostics or making storage changes.

Some USB enclosures, hardware RAID controllers, virtual machines, and network storage layers do not pass S.M.A.R.T. data through to the Ubuntu host. A command that works on a directly connected disk may therefore fail through an enclosure. Identify your connection type before changing device options.

1. Find the drive names and check S.M.A.R.T. access

List storage devices and ask smartmontools which ones it can open:

lsblk -o NAME,TYPE,TRAN,MODEL,SIZE
sudo smartctl --scan-open

Device paths commonly look like /dev/sda for a SATA disk or /dev/nvme0 for an NVMe controller, but use the path reported on your computer. Test each target with a read-only health query:

sudo smartctl -a /dev/sda

Replace /dev/sda with the device you identified. For an NVMe drive, substitute its reported controller path. Read the command output: it should include drive identity and health information rather than a message that SMART is unsupported or the device cannot be opened. If the scan lists a device with a required device type, follow the smartmontools manual for that exact controller or bridge instead of copying another system’s -d option.

Install the monitoring package and supporting tools:

sudo apt update
sudo apt install smartmontools mailutils

mailutils supplies the command-line mail program used by smartd’s default email path. It is not, by itself, an outgoing mail relay. If Ubuntu does not already have a configured mail transfer agent, set one up before continuing.

2. Configure outgoing email before changing smartd

Ubuntu’s Postfix package can relay outgoing mail through an SMTP provider. Configure it as a mail client using the relay host, authentication, sender address, port, and TLS settings given by your provider; do not configure the desktop as an open relay. Ubuntu documents Postfix and relay configuration in its server guide. The exact credentials and settings vary by mail provider, so use that provider’s current instructions. Protect any stored secrets from other local users.

Send a test message from the command line before involving smartd:

printf 'This is an Ubuntu SMART email test.\n' | mail -s 'SMART alert test' you@example.com

Replace the sample recipient with your own address. Confirm that the message arrives, including in spam or junk folders. If it does not, troubleshoot the mail relay first. Check the mail queue with mailq and inspect Postfix logs with journalctl -u postfix. A successful local command can mean only that a message was queued; delivery to the remote mailbox is the real test.

3. Add a S.M.A.R.T. alert destination

Open the smartd configuration as an administrator:

sudoedit /etc/smartd.conf

For a computer where the default device scan finds the drives, use one active device-scan line, replacing the example address. If the file already has an active DEVICESCAN entry, edit that line rather than adding a duplicate:

DEVICESCAN -a -m you@example.com -M test

DEVICESCAN asks smartd to detect supported devices. -a enables the common set of health, error-log, self-test, and attribute checks. -m sets the email recipient. -M test requests one test email when the daemon starts. The smartd configuration manual notes that a DEVICESCAN entry takes over the scan configuration, so do not append per-disk lines after it. If auto-detection misses a disk, use explicit device entries based on smartctl --scan-open output and the manual.

Save and close the editor. Keep the configuration file readable only to administrators if it contains private information. The recipient is not a password, but SMTP relay credentials must never be placed in this file.

4. Start monitoring and confirm the test alert

On Ubuntu, the packaged unit is named smartmontools.service. Enable and start it, then inspect its state:

sudo systemctl enable --now smartmontools.service
systemctl status smartmontools.service

Ubuntu’s package also uses /etc/default/smartmontools to control daemon startup on supported package configurations. If the service is inactive after installation, check that file for a start_smartd=yes setting, then restart the service. If startup fails, read the journal before altering unit files:

sudo journalctl -u smartmontools.service -b

Because the configuration includes -M test, restarting the service should trigger one test email. Confirm receipt. The test proves that smartd can invoke the mail path and that a message can reach the inbox; it does not simulate a failing drive or guarantee future delivery. After the test succeeds, edit /etc/smartd.conf and remove -M test so normal restarts do not send extra test messages. Then restart the service again:

sudo systemctl restart smartmontools.service

5. Verify that each drive is being watched

Check both service logs and the manual health output:

sudo journalctl -u smartmontools.service -b
sudo smartctl -a /dev/sda

Replace the path with each drive reported during discovery. The daemon log should show that it opened supported devices and scheduled checks without repeating device-access errors. A healthy report now is useful baseline information, but it is not a guarantee against a sudden failure.

To inspect behavior without waiting for a failure, run a drive self-test when the device supports it. A short test is generally less disruptive than a long test, but check the drive’s manual and avoid starting diagnostics on an unstable system or a drive with irreplaceable data and no backup. A test command can look like sudo smartctl -t short /dev/sda; the drive reports when the test is expected to finish. Review the result with sudo smartctl -l selftest /dev/sda. The email test and drive self-test are separate checks: one verifies delivery, while the other asks the device to examine itself.

Common problems and what to check

The service is running, but there is no email

First send another message with the mail command. If that fails, inspect the SMTP relay, authentication, TLS settings, sender policy, DNS, queue, and spam folder. If command-line mail works but the smartd test does not, confirm that the recipient appears on the active DEVICESCAN line, that the mail executable is installed, and that smartd can find it. Check the daemon journal for the mailer’s error output.

A drive is missing from the scan

Run sudo smartctl --scan-open again and inspect the device-specific instructions. A USB-to-SATA bridge may need a particular pass-through mode, while some RAID controllers require a controller-specific device syntax. Do not guess: the wrong device type can make smartmontools query the wrong target or fail to report anything useful.

The disk reports “PASSED,” but there are errors

Read the detailed attributes, error log, and self-test log instead of treating the overall summary as the entire diagnosis. If errors are increasing, the device becomes unreliable, or an alert arrives, back up important data promptly and plan a replacement. A clean result is not a substitute for routine backups.

Know the limits of email monitoring

smartd polls supported devices periodically and emails selected warnings; it does not watch every possible failure mode, and an offline desktop cannot report while it is powered down or disconnected. Email can also be delayed, rejected, or filtered. Check service health occasionally and repeat the mail-delivery test after changing SMTP credentials or providers. For critical data, combine S.M.A.R.T. monitoring with independent backups and a recovery plan.

Official references

• Ubuntu 26.04 LTS smartmontools package
• Ubuntu smartd.conf manual
• Ubuntu smartctl manual
• Ubuntu Server: Install and configure Postfix