Fix Fluentd’s “unreadable, it is excluded” warning

When in_tail reports that a file is “unreadable” and will be examined again, start with access permissions. The warning means Fluentd cannot read that path under its current process identity. A malformed JSON line is a separate parsing problem.

Check access as the service user

On Linux, inspect both the file and the directories leading to it:

ls -l /path/to/file.log
namei -l /path/to/file.log

The Fluentd account needs read permission on the file and search permission on every parent directory. Identify the actual account in your service definition; it may be fluent, fluentd, or td-agent on an older installation. Root being able to run head does not establish that the service can read it.

For example, test an installation that runs as fluent:

sudo -u fluent test -r /path/to/file.log

Prefer a narrowly scoped group or ACL over making every log world-readable. If the log already belongs to an appropriate application group, add the service account to that group:

sudo usermod -aG appgroup fluent

Restart the service after changing supplementary group membership so the process receives its new groups. A simple permission or ACL change can generally be picked up at the next path refresh without a restart.

Check rotation and path selection

Inspect the newly created file after rotation, not only the old inode Fluentd had open. Configure the application's logger or logrotate create settings to preserve readable ownership and mode. Otherwise the problem returns at the next rotation.

When tailing wildcard paths, follow_inodes true can help track rotation correctly in supported versions, but it does not grant permissions. Use a persistent pos_file, and exclude archives or temporary files that do not belong in the stream:

exclude_path ["/var/log/app/*.gz", "/var/log/app/*.tmp"]

Also inspect broken symlinks, missing mounts, and container mount paths. SELinux, AppArmor, or a systemd sandbox can deny access even when ordinary Unix permissions look correct.

Separate reading from parsing

Once a file is readable, inspect a small sample under the service account. Binary data or the wrong encoding may then cause parsing or encoding errors; those do not explain this permission-specific warning by themselves. Configure an appropriate parser and encoding after fixing access.

Will Fluentd retry automatically?

The warning indicates the path will be reconsidered on a later scan. Verify that new lines are actually delivered after the fix. If group membership, service sandboxing, or container mounts changed, a restart or container replacement may be necessary; “no restart required” is not a universal rule.

Reference: Fluentd's tail input documentation.