🚨 Telegraf Error Guide: '[inputs.smart] smartctl --scan: permission denied' — Fix S.M.A.R.T. Privileges

Overview

The smart input shells out to smartctl (from smartmontools) to read disk S.M.A.R.T. attributes. Because raw device access needs root, the plugin fails when the unprivileged telegraf user runs smartctl directly:

2026-07-12T12:00:00Z E! [inputs.smart] Error in plugin: failed to run command '/usr/sbin/smartctl --scan': permission denied - 

A closely related form appears once scanning works but reading an individual device is still blocked, or smartctl is not on the resolved path:

E! [inputs.smart] Error in plugin: failed to run command '/usr/sbin/smartctl --info --health ... /dev/sda': permission denied - 

Telegraf keeps running, but no smart_device/smart_attribute metrics are produced until smartctl can access the disks.

Symptoms

• All smart_* metrics are missing while other inputs report normally.
• journalctl -u telegraf repeats failed to run command '/usr/sbin/smartctl --scan': permission denied each interval.
• smartctl --scan works when you run it with sudo, but fails as sudo -u telegraf smartctl --scan.
• The plugin error’s trailing text is empty because smartctl was blocked before it could print anything.
• NVMe drives specifically report no data even after SATA disks start working.

Common Root Causes

• smartctl needs root — reading raw ATA/NVMe device nodes (/dev/sda, /dev/nvme0) requires privileges the telegraf user does not have.
• use_sudo not enabled — the plugin runs smartctl directly instead of via sudo, so it hits the permission wall.
• Missing sudoers entry — use_sudo = true is set but there is no NOPASSWD sudoers rule allowing telegraf to run smartctl.
• Wrong path_smartctl — smartctl lives at /usr/sbin/smartctl but is not on the service’s PATH, so the plugin cannot find it.
• smartmontools not installed — the smartctl binary is absent entirely on minimal images.
• NVMe needs the nvme path/tool — some setups also require nvme-cli and a sudoers entry for nvme to read NVMe health.
• Hardware RAID hides disks — physical drives sit behind a controller and need smartctl -d megaraid,N style device rules.

Diagnostic Workflow

First confirm smartctl exists and reproduce the failure as the service user. If it works with sudo but not as telegraf, the fix is a sudoers rule:

# Where is smartctl, and does it run at all?
command -v smartctl
sudo smartctl --scan

# Reproduce the exact failure as the telegraf user
sudo -u telegraf /usr/sbin/smartctl --scan

Add a tightly scoped sudoers entry so telegraf can run only smartctl (and nvme if needed) without a password. Edit with visudo to a drop-in file:

sudo visudo -f /etc/sudoers.d/telegraf-smart

# /etc/sudoers.d/telegraf-smart
telegraf ALL=(root) NOPASSWD: /usr/sbin/smartctl
telegraf ALL=(root) NOPASSWD: /usr/sbin/nvme

Then enable use_sudo in the input and pin the binary path so it is always found:

[[inputs.smart]]
  use_sudo = true
  path_smartctl = "/usr/sbin/smartctl"
  # path_nvme = "/usr/sbin/nvme"   # for NVMe health via nvme-cli
  attributes = true
  # devices = ["/dev/sda", "/dev/nvme0"]   # optional explicit list

Run only the smart input under Telegraf to confirm it collects after the change:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter smart --debug

As an alternative to sudo, you can grant smartctl the raw-IO capability directly, though a scoped sudoers rule is usually cleaner:

sudo setcap cap_sys_rawio,cap_sys_admin+ep /usr/sbin/smartctl

Example Root Cause Analysis

A storage host reported zero smart_* metrics after a fresh Telegraf install, with failed to run command '/usr/sbin/smartctl --scan': permission denied on every interval. Running sudo smartctl --scan listed all disks, but sudo -u telegraf /usr/sbin/smartctl --scan reproduced the permission denied — confirming the service user simply lacked device access.

The config already had use_sudo = true, but there was no sudoers rule, so sudo smartctl still prompted for a password and failed non-interactively. Adding /etc/sudoers.d/telegraf-smart with telegraf ALL=(root) NOPASSWD: /usr/sbin/smartctl fixed it, and telegraf --test --input-filter smart immediately printed attribute metrics. NVMe drives followed once a matching NOPASSWD line for /usr/sbin/nvme was added. The lesson: use_sudo = true alone does nothing without a NOPASSWD sudoers entry — grant the exact binary, scoped to telegraf, and keep NVMe in mind as a separate path.

Prevention Best Practices

• Enable use_sudo = true and pair it with a scoped NOPASSWD sudoers rule for the exact smartctl path — never blanket sudo access.
• Pin path_smartctl (and path_nvme) in the config so a minimal service PATH cannot hide the binary.
• Provision the sudoers drop-in and smartmontools install through config management so new hosts collect S.M.A.R.T. data from day one.
• Add a NOPASSWD entry for nvme and set path_nvme when the host has NVMe drives.
• Validate rules with sudo -u telegraf sudo -n /usr/sbin/smartctl --scan in post-deploy checks so a missing sudoers rule is caught early.
• Prefer a narrow sudoers rule over setcap when you want an auditable, per-command grant.

Quick Command Reference

# Locate smartctl and reproduce the failure as telegraf
command -v smartctl
sudo -u telegraf /usr/sbin/smartctl --scan

# Confirm the NOPASSWD rule works non-interactively
sudo -u telegraf sudo -n /usr/sbin/smartctl --scan

# Run only the smart input with debug
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter smart --debug

# Watch smart input errors live
journalctl -u telegraf -f | grep -i smart

Related Guides

• Telegraf [inputs.docker] docker.sock permission denied
• Telegraf [inputs.tail] permission denied
• Telegraf [inputs.exec] exit status 1

More fixes in the Telegraf guides.

Conclusion

[inputs.smart] ... smartctl --scan: permission denied means the unprivileged telegraf user cannot access raw disks — smartctl needs root. Set use_sudo = true, add a scoped NOPASSWD sudoers entry for the exact smartctl (and nvme) path, and pin path_smartctl so the binary is always found. Verify with sudo -u telegraf sudo -n smartctl --scan, provision the rule through config management, and S.M.A.R.T. metrics collect reliably across your storage fleet.