Here's a scenario that plays out in homelabs and small offices constantly: a Proxmox VE host has been running fine for eight months. No errors in the GUI, no red icons anywhere. Then one morning a VM won't boot, the task log shows I/O errors, and it turns out a drive has been quietly failing for weeks. Nobody noticed because nobody was looking.

Proxmox VE actually gives you the tools to catch this before it happens. It's built on smartmontools, a package that reads a drive's own internal health counters and can email you the moment something looks wrong. Almost nobody sets it up on a fresh install, which is a shame, because it takes about fifteen minutes.

This tutorial walks through checking disk health from the GUI, reading the raw values from the command line, and — the part most guides skip — actually configuring smartd to send you an email when a drive starts degrading instead of waiting for it to die.

What You Will Learn

  • What S.M.A.R.T. is and which of its dozens of attributes are actually worth watching
  • How to check a disk's health from the Proxmox VE web interface
  • How to read full SMART data from the command line with smartctl
  • How NVMe drives report health differently from SATA/SAS drives
  • How to configure smartd so Proxmox emails you when a disk attribute crosses a warning threshold
  • What to do when a drive comes back "FAILED" or a specific attribute looks off

What Is This Feature?

S.M.A.R.T. stands for Self-Monitoring, Analysis and Reporting Technology. It's not a Proxmox feature exactly — it's built into the firmware of almost every hard drive and SSD made in the last twenty years. The drive itself keeps counters for things like how many sectors it's had to remap, how many hours it's been powered on, and how many read errors it's silently corrected. SMART is just a standard way to ask the drive for those numbers.

Proxmox VE doesn't invent this data, it just gives you two ways to read it. The web GUI shows a simplified Health column (PASSED or FAILED) under each node's Disks tab. Underneath that, the actual heavy lifting is done by smartmontools, a Debian package that's been included in Proxmox VE by default since version 4.3. It has two pieces: smartctl, a command you run manually to pull a full report, and smartd, a background daemon that checks your drives on a schedule and can send an email the moment something crosses a threshold.

Worth knowing up front: SMART works for individual SATA, SAS, and NVMe drives. If your storage sits behind a hardware RAID controller, the controller itself abstracts the physical disks and smartctl usually can't see through it. In that case you need the controller vendor's own tool (things like storcli, perccli, or megacli) instead.

Why Would You Use It?

Mechanical hard drives fail in a fairly predictable way — they start racking up reallocated sectors and pending sectors long before they actually die. SSDs and NVMe drives wear out more gradually, and their firmware tracks exactly how much of their rated write endurance is left. In both cases, the drive is telling you it's in trouble well before Proxmox itself would notice anything.

Without SMART monitoring turned on, the first sign of a problem is usually a VM crashing, a backup job failing halfway through, or the whole node hanging on I/O. With it turned on, you get an email a few weeks earlier that says "hey, /dev/sdb just hit 40 reallocated sectors," which is enough time to order a replacement drive, migrate your VMs off, and swap it during a maintenance window instead of during an outage.

I'd say this matters even more in a homelab than in an enterprise rack, honestly — homelabs are full of drives pulled from old desktops or bought used, and those are exactly the ones with the most wear already on the clock.

Prerequisites

  • A working Proxmox VE 8.x or 9.x host with shell or SSH access as root
  • Physical SATA, SAS, or NVMe drives attached directly to the host (not passed through a hardware RAID controller)
  • A working outbound mail path, or at least an email address configured during Proxmox installation so root's mail gets forwarded somewhere you'll actually see it
  • Comfort running a few commands over SSH — nothing here requires scripting experience

Step-by-Step Tutorial

Step 1: Check disk health from the GUI first

Before touching the command line, look at what Proxmox already shows you. In the web interface, click Datacenter, select your node by name in the left tree, then click the Disks tab. You'll get a table listing every physical disk with a Health column showing either PASSED or FAILED.

Select a disk in that list and click Show S.M.A.R.T. Values at the top. This opens the full attribute table for that drive without needing a terminal at all. It's a good habit to glance at this screen once a month even after you set up alerts, since it shows the whole attribute list, not just the summary.

Step 2: Confirm smartmontools is installed and running

On a normal Proxmox VE install this is already there, but it's worth checking:

dpkg -l smartmontools

If it comes back empty instead of showing a version number, install it:

apt update
apt install smartmontools

This takes a few seconds on an 8.x or 9.x host with working repositories.

Step 3: Pull a full SMART report for a SATA or SAS drive

Find your disk name first (usually something like /dev/sda or /dev/sdb) by checking the Disks tab in the GUI, or running lsblk. Then run:

smartctl -a /dev/sda

The -a flag means "all" — it prints identification info, the overall health assessment, and the full attribute table. Three attributes matter more than the rest for a mechanical drive:

  • Reallocated_Sector_Ct — the number of bad sectors the drive has already swapped out for spares. Anything above 0 and climbing is a warning sign.
  • Current_Pending_Sector — sectors that look unreadable right now but haven't been formally reallocated yet. A non-zero, growing value here is often the earliest warning you'll get.
  • Reported_Uncorrectable_Errors — errors the drive couldn't fix on its own. This one should stay at zero.

For an SSD, look instead at Wear_Leveling_Count or Percent_Lifetime_Remain (the exact attribute name varies by manufacturer), which tells you roughly how much write endurance is left.

Step 4: Check NVMe drives differently

NVMe drives report health through a different protocol, and smartctl -a works on most of them, but the more complete tool is nvme-cli. Install it if it's missing:

apt install nvme-cli

Then check the log:

nvme smart-log /dev/nvme0

Two fields matter most here: percentage_used, which climbs from 0 toward 100 as the drive burns through its rated write endurance (100 doesn't mean instant death, just that the manufacturer's warranty threshold has passed), and critical_warning, which should read 0. Anything else means the drive's firmware is actively flagging a problem right now.

Step 5: Turn on continuous background monitoring

Running smartctl by hand is useful, but the real value is having smartd check drives automatically and warn you. Open /etc/default/smartmontools and set:

start_smartd=yes
smartd_opts="--interval=10800"

The interval is in seconds — 10800 means smartd re-scans every three hours. On a lot of installs start_smartd is already set to yes and the daemon is scanning devices on its own default schedule every 30 minutes across every /dev/sd*, /dev/hd*, and /dev/nvme* device it finds. Setting it explicitly here just makes sure it stays that way after updates.

Step 6: Configure email alerts for specific drives

The default configuration in /etc/smartd.conf uses a catch-all DEVICESCAN line that monitors everything with reasonable defaults. For most homelab setups that's genuinely fine and you can skip to Step 7. If you want per-drive control — different email recipients, or different self-test schedules — comment out the default line:

#DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

And add explicit lines for each drive instead:

/dev/sda -a -d sat -s L/../../2/21 -m root
/dev/sda -m root -M test

The first line watches /dev/sda with all checks enabled (-a), forces SATA mode detection (-d sat, which matters for drives behind USB-to-SATA bridges or some HBAs), and schedules a long self-test every Tuesday at 9pm (-s L/../../2/21). The second line sends a one-time test email on startup so you know the mail path actually works — remove it after you've confirmed delivery, or it'll email you every time the daemon restarts.

The -m root flag routes alerts to the root mail account, and Proxmox forwards root's local mail to whatever address you entered during installation — assuming that's still correct and outbound mail actually works from this host.

Step 7: Restart the daemon and confirm it's alive

systemctl restart smartmontools
tail -n 50 /var/log/syslog

You should see smartd log lines confirming it opened each configured device. If you left the -M test line in from Step 6, check your inbox (or mail at the shell, or wherever root's mail actually lands) for a test message within a minute or two.

Commands Explained

CommandWhat it does
dpkg -l smartmontoolsChecks whether the smartmontools package is installed and which version
smartctl -a /dev/sdaPrints the full SMART report — identity, overall health, and every attribute — for a SATA/SAS drive
smartctl -s on /dev/sdaTurns on SMART support on a drive where it's been disabled (rare, but happens on some older or refurbished drives)
nvme smart-log /dev/nvme0Prints the NVMe health log, including percentage used and any critical warning flags
systemctl restart smartmontoolsRestarts the smartd background daemon so it picks up changes to its configuration files
tail -n 50 /var/log/syslogShows recent system log entries, including smartd's startup and scan messages

Common Errors

"Unable to detect device type" usually shows up when a drive sits behind a RAID controller or an unusual USB-to-SATA bridge. Try forcing the type explicitly, for example smartctl -a -d sat /dev/sda, or check the smartmontools documentation for the right -d value for your specific controller.

"Permission denied" or no output at all means you're not running as root. Every command in this tutorial needs root access to talk directly to the disk device.

A drive shows up in lsblk but smartctl reports no SMART data is common on cheap USB enclosures and some virtual disks — the bridge chip simply doesn't pass SMART commands through. There's no fix for this beyond a different enclosure; it's a hardware limitation, not a configuration problem.

No test email ever arrives almost always means outbound mail isn't actually configured on the host, not that smartd is broken. Check that first before assuming SMART itself is the problem — see the troubleshooting section below.

Troubleshooting

If you added the -M test line and nothing arrives, confirm root's mail is actually being delivered somewhere before blaming smartd. Run echo "test" | mail -s "test subject" root and check whether that shows up. If it doesn't, the issue is your mail relay configuration (Proxmox uses Postfix by default), not your SMART setup.

If the GUI shows a disk as FAILED but smartctl -a looks mostly fine, look specifically at the "SMART overall-health self-assessment test result" line near the top of the output rather than individual attributes — that's the same PASS/FAIL flag the GUI reads, and it can trip on a single pre-fail attribute even while most of the drive still looks okay.

If a drive's Reallocated_Sector_Ct or Current_Pending_Sector count is climbing week over week, don't wait for it to hit some specific number before acting. Both attributes going up steadily, even slowly, is the pattern to treat seriously — a static, small, non-zero number that never changes is far less urgent than one that keeps growing.

Best Practices

  • Don't treat a PASSED health status as a guarantee. SMART catches most mechanical failures early but it's not perfect, and some SSDs die suddenly with no warning attributes at all.
  • Schedule a long self-test (the -s L/../../2/21 style syntax from Step 6) rather than relying only on smartd's background scans, since a full self-test actually exercises the whole disk surface instead of just reading cached counters.
  • Back up your VMs regardless of what SMART reports. Disk health monitoring buys you warning time — it's not a substitute for Proxmox Backup Server or vzdump.
  • Keep at least one spare drive of the same size on hand if you're running anything you actually care about. Ordering a replacement after the alert email arrives is too slow if the drive is already in Current_Pending_Sector territory.
  • If your array is behind hardware RAID, don't rely on smartctl at all — use the controller vendor's monitoring tool, since the OS often can't see individual disks in that setup.

Frequently Asked Questions

Does enabling SMART monitoring slow down my drives?

No. Reading SMART attributes is a lightweight background query, and even a full self-test runs at low priority without meaningfully affecting VM performance.

Can I monitor SMART data for a virtual disk inside a guest VM?

Not directly — SMART needs to talk to the physical drive controller, and a virtual disk is an abstraction on top of that. Monitor the physical drives on the Proxmox host instead.

What if smartctl says a drive doesn't support SMART at all?

That's genuinely rare on modern hardware, but it happens with some older or very cheap flash drives and certain virtual/passthrough configurations. In that case there's nothing to monitor and you'll need to rely on other signs of failure, like I/O errors in the syslog.

Is the GUI Health column enough, or should I still set up email alerts?

The GUI is fine if you check it regularly, but most people don't. Email alerts mean you find out the moment something changes instead of whenever you happen to remember to look.

My drive shows a few reallocated sectors but has for months. Should I replace it?

A small, stable number that isn't increasing is usually fine — plenty of healthy drives accumulate a handful of reallocations over years of normal use. What matters is the trend, not the absolute number.

Conclusion

Fifteen minutes of setup is a small price for not finding out about a dying drive from a crashed VM at 2am. The GUI gives you a quick glance, smartctl gives you the full picture on demand, and smartd's email alerts do the actual watching so you don't have to remember to check. Set it up once, replace drives when the trend says to, and keep backing up regardless — SMART tells you when to worry, it doesn't replace having a copy of your data somewhere else.