Linux File Permissions Explained: chmod, chown and umask

Linux permissions decide who can read, change or execute a file. Every file has an owner, a group and permission bits for the owner, group and everyone else.

Key concepts

Read (r) allows viewing file contents; write (w) allows modification; execute (x) allows running a file or traversing a directory. The numeric values are 4, 2 and 1, so 755 means owner rwx, group r-x, and others r-x.

Practical example

chmod 644 notes.txt gives the owner read/write and everyone else read-only access. chmod 755 script.sh makes a script executable. chown alice:developers notes.txt changes its owner and group. umask 027 removes default permissions from newly created files.

Common pitfalls

Use the least access needed. Making everything 777 is not a fix: it allows every local user to modify the file. Remember that directory execute permission means permission to enter or traverse it.

Expanded practical guidance

A practical workflow

Start by recording the current state before changing anything. On Linux, tools such as id, stat, lsblk, systemctl, journalctl and free expose different parts of the system. Choose the command that answers one specific question instead of running a long list without a hypothesis. If a change affects boot, storage or permissions, keep a recovery path available and make one change at a time.

For example, when a service cannot read a file, check the service's actual user, the file owner, group membership and every parent directory's execute permission. A permission that looks correct on the file itself can still fail because a parent directory blocks traversal.

Operational considerations

Linux behavior varies across distributions, kernel versions and init systems. Check the manual page installed on the target machine and prefer distribution documentation for configuration paths. Avoid copying commands that overwrite configuration files without first checking whether the file is generated or managed by a package. For persistent changes, document the original value and why the new value is needed.

Automation should be safe to run more than once. Prefer commands that inspect state before modifying it, quote variables in shell scripts, and use absolute paths for scheduled jobs. When a command is destructive, test it against a temporary directory or use a dry-run option if the tool provides one.

How to verify the result

After making a change, test both the expected success case and a realistic failure case. Check logs around the time of the test, confirm the change survives a reboot when persistence matters, and verify that unrelated services still work. A short note containing the command, expected output and rollback procedure will make future maintenance much easier.

Useful follow-up practice is to create a small disposable Linux VM, reproduce the task there, and compare behavior with the production host. This lets you learn safely and discover distribution-specific differences before they affect important data.

Conclusion

The most reliable Linux administration comes from understanding the current state, making small reversible changes and checking the result. Keep notes for commands that affect storage, permissions or startup.

---

Article 1 of 100 — 100 technology blog posts in 100 days.