🚨 Filebeat Error: 'config file ... can only be writable by the owner' — Cause, Fix, and Troubleshooting Guide

What this error means

Filebeat enforces strict permissions on its configuration file: it must not be writable by group or others, and it must be owned by the user running Filebeat (or root). If the permissions are too loose, Filebeat refuses to start:

Exiting: error loading config file: config file ("/etc/filebeat/filebeat.yml") can only be writable by the owner but the permissions are "-rw-rw-r--" (to fix the permissions use: 'chmod go-w /etc/filebeat/filebeat.yml')

This is a security guard: a world- or group-writable config could be tampered with to redirect logs or leak credentials. The check applies to filebeat.yml, module files, and anything loaded via filebeat.config.*. Filebeat exits immediately and prints the exact chmod to run. On some setups you also see an ownership variant (config file must be owned by the user running the beat).

How the agent reports it

• config file ... can only be writable by the owner but the permissions are "..." at startup.
• The message includes the exact chmod go-w fix.
• Or config file ("...") must be owned by the user running the beat (ownership variant).
• Started after an editor, deploy tool, or umask left the file group/other-writable.

Checking the agent configuration

Check the current mode and owner:

ls -l /etc/filebeat/filebeat.yml
stat -c '%A %U:%G' /etc/filebeat/filebeat.yml

Check module and dynamically-loaded configs too:

ls -l /etc/filebeat/modules.d/*.yml /etc/filebeat/inputs.d/*.yml 2>/dev/null

Agent configuration causes

• Group/other-writable file — e.g. 0664/0666 from a permissive umask or config-management run.
• Wrong owner — file owned by a user other than the one running Filebeat.
• Copied config that inherited loose permissions from another location.
• Mounted config in containers with world-writable bind-mount defaults.

Step-by-step resolution

Remove group/other write and set correct ownership:

chmod go-w /etc/filebeat/filebeat.yml       # exact fix Filebeat suggests
chmod 0600 /etc/filebeat/filebeat.yml        # or 0644 if only owner-writable is needed
chown root:root /etc/filebeat/filebeat.yml
systemctl restart filebeat

Apply the same to module and included configs:

chmod go-w /etc/filebeat/modules.d/*.yml

In containers, bake correct permissions into the image or fix the mount, or disable the check only if you understand the risk:

# Last resort in locked-down container envs (reduces safety):
filebeat -e --strict.perms=false

Safer agent defaults

• The check covers all loaded configs, not just filebeat.yml — fix modules.d/ too.
• --strict.perms=false disables a real security guard; prefer fixing permissions.
• A permissive umask in your deploy tooling will keep re-introducing this — fix the source.
• The ownership variant needs chown, not just chmod.

Related agent errors

• Filebeat Error Guide: ‘error loading config file … yaml: line X’
• Filebeat Error Guide: ‘Harvester could not be started … permission denied’
• Filebeat Error Guide: ‘data path already locked by another beat’