🚨 Linux Error Guide: 'cannot create file: Permission denied' — Fix Write EACCES on Linux

Overview

Trying to write a file and being refused is the EACCES/EPERM family of errors. The shape depends on which tool hit the wall, but the meaning is the same — the write was blocked:

cannot create file 'report.txt': Permission denied
bash: report.txt: Permission denied
touch: cannot touch 'report.txt': Permission denied
tee: /etc/nginx/nginx.conf: Permission denied

Note the redirect trap: with sudo echo x > /etc/file, the shell (running as you) opens the file for writing before sudo ever runs — so it still fails with Permission denied.

Symptoms

• touch, cp, editors, or > redirection fail with Permission denied on write while reads may still work.
• sudo command > /root/file fails even though you used sudo.
• Writes fail on a specific mount only (e.g. an NFS share or a container volume) but work elsewhere.
• chmod/chown themselves fail with Operation not permitted on a file you appear to own.
• Application logs show EACCES: permission denied, open '...' or IOError: [Errno 13].

Common Root Causes

• Directory lacks write+execute for you — creating a file needs write and execute (w+x) on the parent directory, not on the file. This is the single most common cause.
• Wrong ownership — the file or directory is owned by another user (often root or a service account) and your user has no matching permission bit.
• Read-only mount — the filesystem is mounted ro (bad fstab option, remounted read-only after errors, or a read-only container layer). Distinct message: Read-only file system.
• Immutable attribute — the file has the +i (immutable) chattr flag; even root cannot write until it is cleared. Distinct message: Operation not permitted.
• Full disk or quota — ENOSPC/EDQUOT sometimes surfaces as a write failure.
• The sudo redirect trap — the redirection is performed by the unprivileged shell, not by the elevated command.
• MAC policy (SELinux/AppArmor) — the DAC bits allow it but SELinux/AppArmor denies the write; check ausearch/dmesg.

Diagnostic Workflow

Look at the parent directory, not just the file — write permission there is what governs creating and deleting files:

ls -ld /target/dir          # need d rwx for your user/group on the DIRECTORY
ls -l  /target/dir/file     # ownership + mode of the file itself
id                          # your uid/gid and supplementary groups

Check whether the filesystem is mounted read-only:

mount | grep ' /target '
findmnt -no OPTIONS /target/dir | tr ',' '\n' | grep -x 'ro'

Check for the immutable attribute when writes fail with Operation not permitted:

lsattr /target/dir/file     # an 'i' in the flags means immutable

Rule out a full disk and quotas:

df -h /target/dir; df -i /target/dir
quota -s 2>/dev/null

If DAC looks correct, check MAC denials:

sudo dmesg | grep -iE 'denied|avc'
sudo ausearch -m avc -ts recent 2>/dev/null | tail

Example Root Cause Analysis

A deployment script run as the deploy user fails with bash: /var/www/app/cache/build.json: Permission denied, even though deploy owns build.json. Ownership of the file is a red herring. Running ls -ld /var/www/app/cache shows drwxr-xr-x root root — the directory is owned by root and grants only read+execute to others, no write. Creating or replacing a file requires write on the containing directory, which deploy does not have.

The fix was to give the directory the correct owner rather than loosening the file:

sudo chown deploy:deploy /var/www/app/cache
# or, for a shared writable dir, add group write + setgid:
sudo chmod 2775 /var/www/app/cache

The core lesson: on Linux, the permission to create, rename, or delete a file lives on the parent directory, not the file. When a write is denied, check ls -ld of the directory first — it resolves the majority of Permission denied write failures.

Prevention Best Practices

• Set ownership and mode on directories deliberately; use chmod 2775 (setgid + group write) for shared write directories so new files inherit the group.
• Never use sudo cmd > file; use cmd | sudo tee file (or sudo tee -a to append) so the privileged process does the writing.
• Prefer fixing ownership (chown) over blanket chmod 777, which is a security hazard and hides the real problem.
• Mount application data read-write intentionally and audit fstab; watch for filesystems that remount ro after I/O errors (a failing disk signal).
• Document any chattr +i immutable files so operators know to chattr -i before edits.
• In containers, write to declared volumes, not the read-only image layers, and align the container UID with the volume owner.

Quick Command Reference

ls -ld /dir                       # write+exec on the DIRECTORY governs file creation
id                                # who am I, which groups
findmnt -no OPTIONS /dir          # is it mounted ro?
lsattr file                       # immutable (+i) attribute
sudo chattr -i file               # clear immutable
sudo chown user:group /dir        # fix ownership (preferred)
sudo chmod 2775 /dir              # shared writable dir (setgid + group write)
cmd | sudo tee /etc/file          # correct privileged write (not sudo >)

Conclusion

Permission denied on a write is the kernel’s EACCES, and on Linux the deciding factor for creating a file is write+execute on the parent directory — check ls -ld there before touching the file itself. Rule out the specific variants by their distinct messages: Read-only file system points at a mount, Operation not permitted points at an immutable +i attribute or MAC policy, and No space left on device is a full disk masquerading as a permissions issue. Fix with the least-privilege change — correct ownership or setgid group-write directories — and avoid the sudo > redirect trap by piping through sudo tee.