🚨 Telegraf Error Guide: '[inputs.disk] error getting disk usage info: permission denied' — Fix Disk Access

Overview

The disk input walks the list of mounted filesystems and calls statfs on each mount point to read capacity and usage. When the telegraf user cannot stat a particular mount, the plugin returns a permission error for that gather cycle:

2026-07-12T12:00:00Z E! [inputs.disk] Error in plugin: error getting disk usage info: permission denied

A related form names the specific path when Telegraf cannot enter a restricted or offline mount:

E! [inputs.disk] Error in plugin: error getting disk usage info: stat /mnt/secure: permission denied

Because a single unreadable mount can abort the whole gather, disk metrics for all filesystems can go missing even though most mounts are perfectly readable.

Symptoms

• All disk metrics disappear even though only one mount is actually restricted.
• journalctl -u telegraf repeats error getting disk usage info: permission denied each interval.
• df -h works as root/you but sudo -u telegraf stat /mnt/secure fails with permission denied.
• The offending path is an autofs, FUSE (e.g. gvfs, sshfs, s3fs), or a root-only-mode mount.
• The error appeared after adding a new NFS/FUSE mount or tightening a mount’s permissions to 0700 root.
• Running in a container, disk reports the container’s own filesystems instead of the host’s.

Common Root Causes

• Restricted mount owner/mode — a mount owned root:root 0700 cannot be stat’d by the unprivileged telegraf user.
• FUSE mount with allow_other off — FUSE filesystems are private to the mounting user by default; other users get permission denied.
• Autofs mount not triggered — an automount path exists in the table but stat’ing it as telegraf fails or hangs.
• Restricted /proc — hidepid=2 on /proc hides mount/stat data the plugin relies on.
• Container without host mount visibility — Telegraf in a container sees only its own rootfs unless the host tree is bind-mounted.
• Wrong HOST_MOUNT_PREFIX — a containerized deploy set the prefix incorrectly, so paths resolve to unreadable locations.
• SELinux/AppArmor confinement — MAC policy denies the service access to certain mount points.

Diagnostic Workflow

First identify which mount is unreadable by the service user. Iterate the mount points and stat each one as telegraf:

# Which mounts can the service user actually stat?
for m in $(findmnt -rno TARGET); do
  sudo -u telegraf stat "$m" >/dev/null 2>&1 || echo "DENIED: $m"
done

Inspect the offending mount’s ownership and options — FUSE and 0700 root mounts are the usual culprits:

findmnt /mnt/secure
ls -ld /mnt/secure

The cleanest fix is to exclude filesystem types and mounts Telegraf has no business reading. Use ignore_fs for pseudo/FUSE filesystems and mount_points to allow-list only the mounts you care about:

[[inputs.disk]]
  ## Only collect these mounts (allow-list); omit to collect all
  mount_points = ["/", "/var", "/data"]

  ## Skip pseudo, overlay, and FUSE filesystems that cause noise or denials
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs", "fuse.gvfsd-fuse", "fuse.sshfs", "autofs"]

Run only the disk input to confirm the denials are gone:

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

For containerized Telegraf, bind-mount the host root read-only and point the plugin at it with HOST_MOUNT_PREFIX so it reports the host’s filesystems, not the container’s:

docker run -d --name telegraf \
  -v /:/hostfs:ro \
  -e HOST_MOUNT_PREFIX=/hostfs \
  -e HOST_PROC=/hostfs/proc \
  telegraf:latest

If /proc uses hidepid, add the Telegraf service to the permitted group (gid= on the /proc mount) rather than loosening it globally.

Example Root Cause Analysis

A storage node’s disk metrics vanished entirely after an engineer mounted an s3fs bucket at /mnt/archive for a migration. Telegraf logged error getting disk usage info: permission denied every interval — and crucially, no disk metrics arrived, not even for / and /var, which had always worked.

The for loop over findmnt targets flagged exactly one DENIED: /mnt/archive. findmnt /mnt/archive showed a fuse.s3fs mount owned by the migration user without allow_other, so the telegraf user could not stat it — and that single failure aborted the whole gather. Adding fuse.s3fs to ignore_fs (and switching to an explicit mount_points allow-list) made Telegraf skip the archive mount, and all real disk metrics returned on the next interval. The lesson: one unreadable FUSE or restricted mount can black out the entire disk input, so exclude filesystem types you do not need instead of chasing per-mount permissions.

Prevention Best Practices

• Prefer an explicit mount_points allow-list so new, unrelated mounts can never break disk collection.
• Add FUSE and pseudo filesystem types to ignore_fs proactively (fuse.*, overlay, tmpfs, autofs).
• For containerized Telegraf, bind-mount /:/hostfs:ro and set HOST_MOUNT_PREFIX/HOST_PROC consistently.
• When a mount must be monitored but is root-only, grant the telegraf group read access rather than running Telegraf as root.
• Review the disk input after any storage change; new FUSE/NFS mounts are the most common trigger.
• On hidepid hosts, add Telegraf to the /proc gid allow-group instead of disabling the protection.

Quick Command Reference

# Find which mounts the service user cannot stat
for m in $(findmnt -rno TARGET); do sudo -u telegraf stat "$m" >/dev/null 2>&1 || echo "DENIED: $m"; done

# Inspect a suspect mount's type, source, and options
findmnt /mnt/archive
ls -ld /mnt/archive

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

# Watch disk permission errors live
journalctl -u telegraf -f | grep -i 'disk usage'

Related Guides

• Telegraf Error: [inputs.docker] permission denied on docker.sock
• Telegraf Error: [inputs.tail] permission denied
• Telegraf Error: input took longer to collect

More fixes in the Telegraf guides.

Conclusion

[inputs.disk] error getting disk usage info: permission denied means the telegraf user cannot stat one of the mounted filesystems — usually a FUSE mount without allow_other, a root-only mount, or a restricted /proc — and that single failure can black out all disk metrics. Find the culprit by stat’ing each mount as the service user, then exclude what you do not need with ignore_fs or lock collection to a mount_points allow-list. For containers, bind-mount the host root read-only and set HOST_MOUNT_PREFIX, and disk metrics will collect reliably across every real filesystem.