How Linux permissions work (owner, group, others and numeric modes)

At the core of Linux file permissions are three actors: the owner, the group, and others. Every file or directory has three permission triplets—read (r), write (w), execute (x)—that control what each actor may do. Understanding which actor applies is the first step when you get a “permission denied” error.

The classic output of ls -l shows permissions like -rwxr-xr--. Think of these as three buckets: owner, group, and others. Numeric modes (e.g., 755, 644, 775) are a compact representation: read=4, write=2, execute=1; add them per bucket. For example, 755 = owner rwx (7), group rx (5), others rx (5).

Special bits matter too: setuid, setgid, and the sticky bit change execution behavior and directory deletion rights. Beyond standard permissions, you may also encounter Access Control Lists (ACLs), SELinux, AppArmor, or filesystem mount options (like ro) that override or supplement basic permission rules.

Diagnosing “permission denied” and EACCES errors

Start by asking: which user is trying to access the file and what are the file’s permissions? Use ls -l /path/to/file and stat /path/to/file to inspect owner, group, and permission bits. For directories, remember execute (x) means “enter” — you may have read but not execute on a directory and still get denied.

If permissions look correct but access is still denied, check for ACLs with getfacl /path/to/file. ACLs can grant or deny rights beyond the owner/group/others model. Also inspect mount options in /etc/fstab or output from mount — filesystems mounted with ro or with root-only write restrictions will reject writes despite permissive bits.

Security modules like SELinux or AppArmor often cause surprises. On SELinux-enabled systems, a denied access may be logged to /var/log/audit/audit.log. Use ausearch or sealert (or temporarily set SELinux to permissive for testing) to confirm. For containerized apps, also check user namespaces and bind mounts—UID mismatch between host and container is a very common source of EACCES.

Practical fixes: chown, chmod, chgrp and safe workflows

When you identify the root cause, pick the least-privilege fix. If a process needs write access to a directory, prefer adding the process user to the directory’s group and granting group write, instead of making the file world-writable. Example: to add user deploy to group web, use usermod -aG web deploy and then chmod g+w /var/www/site.

To change ownership, use chown. Example: to make www-data own a folder and its contents, run sudo chown -R www-data:www-data /var/www/site. Use recursion (-R) with caution: recursive chown on system directories like / or /usr can break your system. For files vs directories, you can limit recursion with find: find /var/www/site -type d -exec chown www-data:www-data {} +.

To change permission bits, use chmod. For a typical web directory where owner should read/write and group read/execute: chmod -R 750 /var/www/site. Need write for group? chmod -R g+w /var/www/site. Numeric example for files (644) and directories (755): find /var/www/site -type f -exec chmod 644 {} +; find /var/www/site -type d -exec chmod 755 {} +.

Advanced causes and fixes: ACLs, sticky bit, capabilities, NFS and Docker

ACLs: Use getfacl and setfacl to inspect and set fine-grained permissions. For example, grant write to user ci without changing ownership: setfacl -m u:ci:w /var/build. To remove: setfacl -x u:ci /var/build. Remember ACLs are additive—older tools may not show them.

Sticky bit: For shared directories like /tmp, the sticky bit prevents users from deleting others’ files. If you’re troubleshooting file deletion errors in shared dirs, check the sticky bit with ls -ld /path—you’ll see a t in the others’ execute position if set.

Network filesystems and containers often change the semantics of ownership. NFS can map UIDs between client and server; if UIDs don’t match, a file owned by UID 1000 on the server may appear owned by someone else on the client. Containers run processes as different UIDs; mount with userns-remap or adjust ownership on the host. In Docker, prefer using volumes with correct ownership or initialize them at container startup with an entrypoint that chowns safely.

Quick troubleshooting checklist and voice-search-friendly snippets

When you need a fast diagnosis, follow a compact checklist: check ls -l and stat; verify ACLs; check mount options; confirm SELinux/AppArmor; consider UID mapping for NFS/containers; apply least-privilege fix. This checklist is intentionally short so it works well as a voice search or featured snippet answer.

Voice-search friendly snippets (speak these or use them as one-line fixes):

# If file ownership is wrong
sudo chown -R user:group /path/to/target

# Grant group write without touching owner
sudo chmod -R g+w /path/to/target

# Safe recursive: set rw for owner, r for group, X for execute only on dirs
sudo chmod -R u=rwX,g=rX,o= /path/to/target

For a one-sentence featured-snippet answer: “Fix EACCES by identifying the user and file owner with ls -l, then adjust ownership with chown or permissions with chmod, and check ACLs and SELinux if the problem persists.” That line is short, direct, and tailored for voice assistants and snippet boxes.

Resources and references (with example backlinks)

Use authoritative guides and manpages when in doubt. For a practical walkthrough on ownership and permission commands, see a concise tutorial here: chown command usage Linux. For examples focused on permission fixes and EACCES troubleshooting, this resource covers common scenarios: permission denied error Linux.

If you prefer official references, consult man chmod, man chown, and distro docs for SELinux/AppArmor. Practical quick-start guides tend to be the most useful when you’re mid-incident and need to restore access safely.

FAQ