Linux file permissions and ownership explained for server admins

Linux file permissions and ownership control who can read, write, and execute files and directories, and for a server admin they are the first line of defense against accidental or malicious changes. This article explains the classic Unix permission model (owner/group/others and rwx bits), how to read and set them with chmod, chown, and umask, and how to avoid the most common mistakes that break services or expose data.

Background: why permissions matter on a server

On a single-user desktop, file permissions often go unnoticed. On a server, multiple users, daemons, and automated scripts share the same filesystem. A web server process, for example, needs to read static files but should not be able to modify your SSH keys. Without permissions, any user or process could read, alter, or delete anything, turning a small misconfiguration into a full compromise. The permission system is also how Linux keeps one user’s private files away from another, even when both have accounts on the same machine.

Every file and directory has an owner (a user) and a group. Permissions are then defined for three classes: the owner, the group, and everyone else (“others� or “world�). This three-tier model is simple, but it forces you to think about who really needs access and to what degree.

How the permission bits work

Each file has three permission triads, one for each class. Each triad contains three bits: read (r), write (w), and execute (x). When you run ls -l, you see them like this:

-rw-r--r-- 1 alice devs  2048 Apr 12 10:30 config.yaml

The first character is the file type (- for regular file, d for directory, l for symlink). The next nine characters are the permissions: rw- for owner, r-- for group, r-- for others. So the owner can read and write, the group can only read, and everyone else can only read.

For directories, the meaning shifts:

• Read on a directory lets you list its contents (names only).
• Write on a directory lets you create, rename, or delete files inside it (regardless of the file’s own permissions).
• Execute on a directory lets you traverse into it, i.e., access files inside if you know their names.

This is a common source of confusion: a file may be world-readable, but if its parent directory lacks execute permission, no one can actually open it.

Changing permissions with chmod

The chmod command changes permissions. You can use symbolic mode or numeric (octal) mode. Symbolic mode is intuitive:

chmod u+x script.sh   # add execute for the owner
chmod g-w config.yaml # remove write for the group
chmod o=r data.txt    # set others to read-only

Numeric mode uses three digits (or four with special bits). Each bit is a power of two: read=4, write=2, execute=1. Sum the values for each class. So chmod 750 file means owner=7 (rwx), group=5 (r-x), others=0 (—). This is the classic permission set for a directory that a group shares but that outsiders cannot enter.

Common numeric values:

• 600 – owner read/write, nothing else (good for private keys).
• 644 – owner read/write, group/others read (standard for web files).
• 700 – owner full, nothing else (good for private directories).
• 755 – owner full, group/others read+execute (standard for executables and public directories).
• 660 – owner and group read/write, others none (shared files).

Ownership: chown and chgrp

Ownership is set with chown. Only root can change the owner of a file. The syntax is:

chown alice file.txt        # change owner to alice
chown alice:devs file.txt   # change owner and group
chown :devs file.txt        # change only group

The group can be changed by the owner, but only to a group the owner belongs to. To change a file to a group the owner is not in, you need root.

When you move or copy files, ownership may change. Copying with cp creates a new file owned by the user running the command. Moving with mv within the same filesystem preserves the original owner. Archiving with tar preserves ownership only if you extract as root; otherwise files are owned by the extracting user.

Special bits: setuid, setgid, and sticky

Beyond the basic bits, three special permission bits exist. They are set with a fourth digit in numeric mode (e.g., chmod 4755) or with symbols (u+s, g+s, o+t).

• Setuid (4): when set on an executable file, the process runs with the file owner’s privileges, not the invoking user’s. This is how passwd lets normal users change their passwords. Setuid on a root-owned binary is a security risk if the binary is flawed.
• Setgid (2): on a directory, new files inside inherit the directory’s group instead of the creator’s primary group. This is essential for shared team directories. On an executable, it runs with the group’s privileges.
• Sticky bit (1): on a directory, only the file owner (or root) can delete or rename files inside, even if the directory is world-writable. The classic example is /tmp.

Default permissions and umask

When you create a file, the system applies a default permission set, usually 666 for files and 777 for directories, then subtracts the umask value. The umask is a three-digit octal number that tells which bits to remove. A typical umask is 022, which removes write for group and others, resulting in files with 644 and directories with 755.

To see your current umask, run umask. To change it, run umask 027 (which gives files 640 and directories 750). For security-sensitive directories, a stricter umask like 077 is common, giving only the owner access.

Note that umask only affects new files; it does not change existing ones. Also, some programs (like scp or rsync) may override the umask based on their own settings.

Common problems and practical tips

Here are the permission mistakes server admins see most often:

• Web server can’t read files: The web server user (e.g., www-data on Debian/Ubuntu) needs read and execute on every directory in the path, and read on the file. If a parent directory is 700, the server gets “permission deniedâ€�. Fix with chmod o+x /path/to/dir or better, change the group and use 750.
• SSH private keys too open: OpenSSH refuses to use a private key if it is readable by group or others. The key must be 600 and its .ssh directory 700.
• Files created by root in a shared directory: If a script run by root writes to a shared folder, the files are owned by root and the group may not be able to edit them. Use setgid on the directory and add both users to the same group.
• Deleting a file you don’t own: In a world-writable directory without the sticky bit, any user can delete any file. Always use the sticky bit on shared writable directories.
• Permissions on symlinks: chmod on a symlink changes the target, not the link. The link itself always has 777; what matters are the target’s permissions.

Alternatives and advanced access control

The classic rwx model is coarse. When you need finer control, Linux offers two more layers:

• Access Control Lists (ACLs): setfacl and getfacl let you grant permissions to specific users or groups beyond the owner/group/others trio. For example, setfacl -m u:alice:rw /shared/file gives Alice read/write without changing the group. ACLs are supported on most filesystems (ext4, XFS, Btrfs) but may need to be enabled.
• SELinux / AppArmor: These are mandatory access control (MAC) systems that can restrict processes even when the traditional permissions allow access. They are complex but are enabled by default on many enterprise distributions (SELinux on RHEL/CentOS, AppArmor on Ubuntu). If a service gets “permission deniedâ€� despite correct file permissions, check SELinux with ls -Z and ausearch.

For most server tasks, the classic permissions are enough. Use ACLs when you need to share files with a few specific users, and reserve SELinux/AppArmor for high-security environments where you want to contain daemons.

Frequently Asked Questions

What does chmod 777 mean and why is it dangerous?

chmod 777 gives read, write, and execute to everyone. On a server, any user or process can modify or delete the file, which can lead to data loss or privilege escalation if the file is executable. Avoid it for anything that is not intentionally public and writable, like a temporary upload directory (and even then, use the sticky bit).

How do I make a file readable by a specific user without changing the group?

Use an ACL: setfacl -m u:username:r file. This grants read to that user only, without altering the file’s group or the permissions for others. Check with getfacl file.

Why can’t I delete a file even though the file permissions say I can write?

Deleting a file depends on the permissions of the directory that contains it, not the file itself. You need write and execute on the directory. If the directory is owned by someone else and you are not in the group, you cannot delete the file.

What is the difference between chown and chgrp?

chown changes the owner (and optionally the group), while chgrp changes only the group. Both require appropriate privileges; only root can change the owner. As a non-root user, you can change the group only to a group you belong to.

How do I set permissions so that a group can edit files but others cannot?

Set the group to a shared group and give the group read/write, and give others no access. For example, chown :devs file then chmod 660 file. For directories, use 770 and consider the setgid bit so new files get the same group.

Does changing permissions on a directory affect files inside it?

No. Permissions on a directory do not change the permissions of files inside it. To change permissions recursively, use chmod -R or chown -R, but be careful: this can break services if you accidentally remove execute from directories.

Related

• Can LLMs Inspect Their Own Thoughts? Evidence
• Weather Lock Screen: How It Works & How to Set It Up
• Easiest Way to Change Text Font Size on iPhone