Fix Filebeat “data path already locked by another beat”

This error usually means another Beat instance already owns the same path.data. That directory contains persistent state, including Filebeat's registry. Each independently running instance needs its own data directory.

Identify the owner before changing files

On a systemd-based Linux host, inspect the service and running processes:

sudo systemctl status filebeat
pgrep -af filebeat

Read the startup log or service definition to find the effective path.data; do not assume a manually started process uses the package default. The error may name the lock file, commonly filebeat.lock in the data directory. Inspect that exact path:

sudo lsof /var/lib/filebeat/filebeat.lock

A typical cause is starting Filebeat manually while its service is already running. Stop the duplicate instance through the mechanism that started it, then restart the intended service if necessary. Avoid killing unrelated Beat processes or deleting the registry to fix a lock problem.

Give intentional instances separate state

filebeat -c /etc/filebeat/instance1.yml \
  --path.data /var/lib/filebeat-instance1 \
  --path.logs /var/log/filebeat-instance1

Use a different path.data for each concurrent instance. Separate configuration and log locations also make ownership easier to understand. Even with separate state, two instances reading the same files can send duplicate events.

Check container and Kubernetes storage

Two containers mounting the same data directory can collide. For a DaemonSet, inspect the actual volumes and rollout behavior: overlapping Pods on the same node can share the same hostPath. Naming a directory by node does not separate two instances on that node.

Preserve state across normal restarts, and prevent overlapping ownership rather than giving every restart an empty directory. An emptyDir may avoid a shared lock but loses state when the Pod is replaced, which can cause rereading and duplicates.

If no owner appears

Check permissions, container namespaces, service restart loops, and the exact path in the error. An empty lsof result alone is not proof that a lock is stale. Only consider removing a confirmed stale lock after all instances using that data path are stopped and the persistent state is backed up. Never remove a live instance's lock.

See Elastic's data directory layout and path configuration.