🚨 Linux Error Guide: 'Permission denied' and 'Input/output error' — Fix Unreadable Files

Overview

“Unable to read a file” on Linux surfaces as a few distinct errors, and the distinction matters because the fixes are completely different. A permissions problem looks like this:

$ cat /var/log/secure
cat: /var/log/secure: Permission denied

A failing disk or corrupt filesystem block looks like this — the file exists and you have permission, but the read itself fails at the hardware/filesystem layer:

$ cat /data/archive.tar
cat: /data/archive.tar: Input/output error

Permission denied is a policy decision (mode bits, ownership, ACLs, SELinux). Input/output error (EIO) is a real read failure — bad sectors, a dying drive, or filesystem corruption. Reading garbled bytes with no error is usually an encoding issue, not a read failure at all.

Symptoms

• cat, less, grep, or an application reports Permission denied opening a file it needs.
• Input/output error appears mid-read, sometimes only on certain files or after a certain offset.
• dmesg fills with I/O error, dev sdX or EXT4-fs error messages when the file is touched.
• A file opens but its contents look like <9A><FF> mojibake — a character-encoding mismatch, not a read error.
• The same file reads fine as root but fails for the service user.

Common Root Causes

• Insufficient permissions — the file’s mode denies read to your user/group (e.g. -rw------- owned by another user).
• Missing directory execute bit — a parent directory lacks x for you, so the path can’t be traversed to reach the file.
• ACLs or SELinux — an ACL denies read, or an SELinux label blocks the process even though mode bits look fine.
• Failing disk / bad sectors — the underlying block device returns EIO; the file is physically unreadable in places.
• Filesystem corruption — metadata or extents are damaged, so the kernel refuses the read with Input/output error.
• Encoding mismatch — the bytes read fine but are in a different charset (UTF-16, Latin-1) than the tool assumes.

Diagnostic Workflow

First separate a permissions problem from a hardware/filesystem problem. Inspect ownership, mode, and ACLs:

ls -l /var/log/secure                 # owner, group, mode bits
namei -l /var/log/secure              # permissions along the ENTIRE path (find missing x)
getfacl /var/log/secure 2>/dev/null   # extra ACL entries

If SELinux is enforcing, check labels and denials:

getenforce
ls -Z /var/log/secure
sudo ausearch -m avc -ts recent 2>/dev/null | tail

If it’s an Input/output error, go straight to the kernel log and disk health:

dmesg -T | grep -iE 'i/o error|EXT4-fs error|blk_update|medium error' | tail
sudo smartctl -a /dev/sda | grep -iE 'reallocated|pending|health'

Detect an encoding issue (read succeeds but text looks wrong):

file /data/notes.txt                  # e.g. "UTF-16 Unicode text"
iconv -f UTF-16 -t UTF-8 /data/notes.txt | head

Example Root Cause Analysis

A monitoring agent running as user telegraf logged Permission denied reading a metrics file it had read for months. Ownership looked correct:

$ ls -l /var/data/metrics.db
-rw-r--r-- 1 telegraf telegraf 4.1M Jul 7 09:12 /var/data/metrics.db

The file’s own mode allowed read, so the problem had to be higher in the path. namei -l exposed it:

$ namei -l /var/data/metrics.db
 dr-x------  root  root  data          # <- missing group/other execute

A recent hardening script had reset /var/data to 700 root:root, removing the execute (traverse) bit for everyone else. Without x on the directory, telegraf could not reach the file inside it, producing Permission denied on the file even though the file’s own bits were fine. Restoring traverse access fixed it:

sudo chmod o+x /var/data          # allow path traversal without exposing listing

Had dmesg instead shown I/O error, dev sda, the correct response would have been to back up the data immediately and replace the failing disk, not adjust permissions.

Prevention Best Practices

• Grant service users read via group membership and correct directory x bits rather than broad chmod 777.
• After running hardening or chmod -R scripts, verify the full path with namei -l, not just the target file.
• Monitor SMART attributes (smartctl, smartd) so failing disks are replaced before EIO corrupts reads.
• Watch dmesg/journalctl -k for I/O error and EXT4-fs error and alert on them.
• Keep tested backups so an unrecoverable Input/output error means restore, not data loss.
• Normalize text files to UTF-8 on ingest and record the expected encoding to avoid mojibake.

Quick Command Reference

ls -l <file>                             # owner, group, mode
namei -l <path>                          # permissions along the whole path
getfacl <file>                           # ACL entries
ls -Z <file>; getenforce                 # SELinux label and mode
dmesg -T | grep -i 'i/o error'           # disk / filesystem read failures
sudo smartctl -a /dev/sdX                # drive health
file <file>; iconv -f UTF-16 -t UTF-8 f  # detect / convert encoding

Conclusion

“Unable to read a file” is really two very different problems wearing one description. Permission denied is policy — check the file’s mode, every parent directory’s x bit with namei -l, ACLs, and SELinux. Input/output error is physical — check dmesg and SMART, then back up and replace the disk. And garbled-but-readable content is just an encoding mismatch for iconv. Identify which category you’re in first, and the correct fix follows immediately.