Linux File Permissions Explained for Beginners

Linux File Permissions Explained for Beginners

Kevin Wu
August 27, 2026· 8 min read

Linux file permissions answer two questions: which class of user is acting, and which action that class may perform. The basic model has three classes—owner, group, and other—and three permission bits—read, write, and execute. The meaning of execute changes for a directory, which is why copying a file’s mode onto a folder can produce surprising results.

Key Takeaways

  • Read the permission string as type, owner, group, and other.
  • For a directory, x means traverse or access entries, not “run the folder.”
  • Use the narrowest permissions that support the actual users and task.
  • Never use chmod 777 as a universal fix; it grants write access to everyone.

For a broader evidence-first approach, see Device and App Troubleshooting Guide.

What do owner, group, and other mean in Linux file permissions?

Every ordinary Linux file and directory has an owning user and an owning group. Basic permission bits apply in three sets:

  • Owner: the user account that owns the object.
  • Group: users who are members of the object’s owning group.
  • Other: everyone else on the system who is neither matched as owner nor through the owning group.

Ubuntu’s file manager documentation describes separate permissions for the owner, the owning group, and all other users.[1] The system chooses the applicable class for the current access check; it does not combine “other” permissions with a more specific owner or group match to make a broader set.

Ownership and permissions are related but different. Changing the group can change which users match the group class. Changing the mode changes the actions allowed to each class. Do not change both at once unless you understand which one is actually wrong.

How do you read an rwx permission string?

A long listing may show something like:

-rw-r-----

Read it from left to right:

  1. - means a regular file. A directory normally starts with d.
  2. rw- is the owner’s permission set.
  3. r-- is the group’s permission set.
  4. --- is the permission set for other users.

Ubuntu’s documentation uses this same type-plus-three-triplets structure.[2] A dash means that permission bit is not set.

The string tells you the basic discretionary permissions, not every access-control layer. Access control lists, mandatory access-control systems, mount options, immutable flags, application rules, and network-file-system policy can still allow or deny an action.

What do r, w, and x mean for files?

For a regular file:

  • Read (r) allows reading its contents.
  • Write (w) allows modifying or truncating its contents.
  • Execute (x) allows asking the system to execute it as a program or script, subject to the file format, interpreter, mount options, and other controls.

Write permission on a file is not the same as permission to delete it. Deletion normally changes the containing directory entry, so directory permissions are decisive. Conversely, removing write permission from a file helps prevent modification but does not necessarily stop a user who can replace or delete the directory entry.

An execute bit also does not prove a downloaded program is safe. Verify its source before making it executable or running it. For Linux software-source choices, see how APT repositories, Snap, Flatpak, and AppImage differ.

What do permissions mean for directories?

Directory permissions describe access to names and entries:

  • Read (r) allows listing names in the directory.
  • Write (w) allows creating, deleting, or renaming entries, usually when traverse permission is also available.
  • Execute (x) allows traversing the directory and accessing an entry by name, subject to that entry’s own permissions.

Ubuntu’s graphical permission labels reflect these combinations: listing files differs from accessing files, and creating or deleting files is a broader directory capability.[1]

This creates important cases:

  • r without x may reveal names but prevent normal access to their metadata or contents.
  • x without r may allow access to a known filename while preventing a directory listing.
  • w and x on a directory may allow deletion or replacement of entries even when their files are not writable.

When diagnosing a path, check every parent directory. A readable file cannot be reached through a parent directory the user cannot traverse.

How do numeric chmod modes work?

Each permission has a numeric value:

  • read = 4;
  • write = 2;
  • execute = 1.

Add the values separately for owner, group, and other. For example:

ModeOwnerGroupOtherTypical interpretation
600read + writenonenoneprivate user file
640read + writereadnoneowner edits, group reads
644read + writereadreadbroadly readable non-secret file
700allnonenoneprivate directory or executable
750allread + executenonegroup can read and traverse
755allread + executeread + executepublicly traversable directory or executable

These are examples, not prescriptions. 644 is inappropriate for a secret, and 755 is inappropriate for a private directory. The correct mode depends on the object and users.

Symbolic changes can be easier to review because they state intent. For example, chmod u+x script.sh adds execute only for the owner, while chmod 640 report.txt replaces the basic mode with an explicit value. Before running either, confirm the path and current ownership.

Why is chmod 777 a bad fix?

Mode 777 grants read, write, and execute to owner, group, and every other local user. On a directory, that can allow other users or processes to create, replace, rename, and delete entries. It may hide the original ownership or service-identity error while creating a broader security problem.

Instead, ask:

  1. Which account runs the application?
  2. Which object does it need to read, write, create, or traverse?
  3. Should access belong to one owner or a controlled group?
  4. Are parent-directory permissions the real blocker?
  5. Is another layer, such as a mount option or access-control list, involved?

Fix the narrow mismatch. Do not recursively change a large tree until you have reviewed symbolic links, special files, application expectations, and a rollback plan.

What are ownership, umask, and Linux special permissions?

New objects begin with an application-requested mode modified by the process’s umask, which removes selected default permission bits. This helps explain why two applications create files with different modes in the same directory.

Linux also supports special bits such as set-user-ID, set-group-ID, and the sticky bit, plus access control lists. They matter for shared directories and executables but are beyond the basic three-digit model. If a permission string includes unfamiliar characters or a listing indicates an ACL, inspect the exact system documentation rather than flattening the mode.

Changing ownership with privileged tools can affect services, package management, backups, and user access. Avoid recursively assigning everything to your personal account as a shortcut.

A safe permission troubleshooting checklist

  1. Identify the exact user or service account performing the failed action.
  2. Record the file type, owner, group, basic mode, and parent path.
  3. Decide whether the required action is read, write, execute, create, delete, or traverse.
  4. Check every parent directory’s traverse permission.
  5. Look for ACLs, mount flags, sandboxing, or security policy if basic bits appear correct.
  6. Make the smallest ownership, group, or mode change.
  7. Test as the actual account, then verify unrelated access did not expand.
  8. Document and revert temporary diagnostic changes.

Summary

Linux permissions become manageable when you separate user class from action and remember that directory x means traversal. Read the full path, choose the narrowest needed mode, and investigate ownership and other access layers. Broad modes such as 777 are not a substitute for understanding the failing access.

FAQ

What does -rw-r--r-- mean?

It is a regular file whose owner can read and write, while group members and other users can only read.

What does x mean on a directory?

It allows traversal and access to entries by name, subject to their own permissions. It does not mean “execute the folder.”[2]

Can I delete a read-only file?

Possibly. Deletion is controlled mainly by the containing directory’s permissions, not only the file’s write bit.

Is 755 always correct for directories?

No. It allows all users to read and traverse. Private or shared project directories may need a narrower mode.

Why can’t I open a readable file?

A parent directory may lack traverse permission, or an ACL, mount option, sandbox, or security policy may block access.

Should scripts always be executable?

No. Add execute only when the file is intended to run, its source is trusted, and the execution path is understood.

Is chmod 777 safe temporarily?

It can expose writable access and hide the real cause. Use a narrowly scoped diagnostic change and revert it rather than granting everyone full access.


Sources:

  1. Ubuntu Help — Set file permissions — https://help.ubuntu.com/stable/ubuntu-help/nautilus-file-properties-permissions
  2. Ubuntu Help — Files list columns preferences — https://help.ubuntu.com/stable/ubuntu-help/nautilus-list.html

Sources checked 27 August 2026.


Related Articles:

Start your 3-day free trial

Sign up to experience all premium features at no cost.

*Available only to new users. Each user is limited to one trial.

Linux File Permissions Explained for Beginners | AethoVPN