🚨 Telegraf Error Guide: 'outputs.file: open metrics.out: permission denied' — Fix File Output Permissions

Overview

The file output writes serialized metrics to a path on disk. When the telegraf user cannot create or open that path, the agent fails to open the output at startup and logs a permission error:

2026-07-12T12:00:00Z E! [agent] Error writing to outputs.file: failed to open file: open /var/log/telegraf/metrics.out: permission denied

A closely related form appears when the parent directory itself is missing or unwritable, so the open fails before the file is ever created:

E! [outputs.file] failed to open file: open /var/log/telegraf/metrics.out: no such file or directory

Until the target is writable by the service user, no metrics are persisted to the file and the output is effectively dead.

Symptoms

• /var/log/telegraf/metrics.out is empty, stale, or absent while other outputs (InfluxDB, Prometheus) work.
• journalctl -u telegraf repeats permission denied for the file output on every flush.
• Writing works when Telegraf is started interactively as root but fails under systemd as the telegraf user.
• The error appeared after a logrotate run recreated the file with root:root ownership.
• ls -ld /var/log/telegraf shows a directory owned by root with no write bit for telegraf.

Common Root Causes

• Target directory not writable by telegraf — /var/log/telegraf is owned by root:root mode 0755, so the service user cannot create files in it.
• File owned by another user — a previous run (or logrotate) created metrics.out as root, and the telegraf user cannot reopen it for writing.
• SELinux/AppArmor denial — MAC policy blocks writes outside the labeled Telegraf paths even when Unix permissions look correct.
• logrotate recreates with wrong perms — a create 0640 root root directive in the rotate config resets ownership away from telegraf.
• Path on a read-only or noexec mount — the directory lives on a filesystem mounted read-only, or a container volume mounted read-only.
• Missing parent directory — the configured path points into a directory that was never created, so the open fails outright.

Diagnostic Workflow

First confirm who Telegraf runs as and whether that user can write the target. Check the service user and the directory ownership together:

systemctl show -p User telegraf          # usually User=telegraf
ls -ld /var/log/telegraf
ls -l /var/log/telegraf/metrics.out 2>/dev/null

Reproduce the write as the exact service user — this is the definitive test:

sudo -u telegraf touch /var/log/telegraf/metrics.out && echo "writable"

To isolate whether the problem is the plugin or the path, temporarily send the file output to stdout and run only that output under test:

[[outputs.file]]
  files = ["stdout"]
  data_format = "influx"

telegraf --config /etc/telegraf/telegraf.conf --test --debug

If stdout works but the file path does not, the issue is filesystem permissions. Fix ownership on the directory (and rotate output) so the service user owns it:

sudo install -d -o telegraf -g telegraf -m 0755 /var/log/telegraf
sudo chown telegraf:telegraf /var/log/telegraf/metrics.out
sudo systemctl restart telegraf

The working file output points at the owned path:

[[outputs.file]]
  files = ["/var/log/telegraf/metrics.out"]
  rotation_max_size = "50MB"
  rotation_max_archives = 5
  data_format = "influx"

On SELinux-enforcing hosts, check for a denial before touching Unix permissions again:

sudo ausearch -m avc -c telegraf --start recent

Example Root Cause Analysis

A team used the file output to tee metrics into /var/log/telegraf/metrics.out for a downstream log shipper. Collection worked for weeks, then every night at 03:00 the output began logging permission denied until someone restarted the service. The directory was owned by telegraf, so the initial suspicion was SELinux — but ausearch showed nothing.

The culprit was logrotate: a /etc/logrotate.d/telegraf entry rotated metrics.out with a create 0640 root root line, so each night the recreated file was owned by root. The running Telegraf process, holding no write access to the new inode, failed until restart. Changing the directive to create 0640 telegraf telegraf and adding a postrotate systemctl kill -s HUP telegraf block fixed it permanently. The lesson: a file output that dies on a schedule is almost always logrotate recreating the file with the wrong owner.

Prevention Best Practices

• Create /var/log/telegraf with install -d -o telegraf -g telegraf in provisioning so ownership is never left to chance.
• Match any logrotate create directive to telegraf telegraf, and HUP or restart Telegraf in postrotate.
• Prefer Telegraf’s built-in rotation_max_size/rotation_max_archives over external logrotate to keep ownership consistent.
• Use files = ["stdout"] as a quick isolation test to separate plugin problems from filesystem permissions.
• On SELinux hosts, write only to labeled paths or add the correct file context instead of disabling enforcement.
• Add sudo -u telegraf touch <path> to post-deploy checks so an unwritable output is caught before metrics are lost.

Quick Command Reference

# Confirm the service user and target ownership
systemctl show -p User telegraf
ls -ld /var/log/telegraf

# Definitive write test as the service user
sudo -u telegraf touch /var/log/telegraf/metrics.out && echo writable

# Fix directory and file ownership
sudo install -d -o telegraf -g telegraf -m 0755 /var/log/telegraf
sudo chown telegraf:telegraf /var/log/telegraf/metrics.out

# Isolate the plugin by writing to stdout
telegraf --config /etc/telegraf/telegraf.conf --test --debug

# Check SELinux denials
sudo ausearch -m avc -c telegraf --start recent

Related Guides

• Telegraf tail input permission denied
• Telegraf could not write to outputs
• Telegraf docker.sock permission denied

More fixes in the Telegraf guides.

Conclusion

Error writing to outputs.file: ... permission denied means the telegraf user cannot create or open the configured path — almost always because the parent directory is owned by root or logrotate recreated the file with the wrong owner. Confirm the service user, test the write with sudo -u telegraf touch, and fix directory ownership to telegraf:telegraf. Isolate plugin issues with files = ["stdout"], align logrotate’s create directive, and check SELinux on enforcing hosts, and the file output will persist metrics reliably.