Linux File Permissions for Beginners

If you are new to Linux, file permissions can look like a secret code.

You run ls -l, see something like -rwxr-x---, and it feels dense at first.

The good news is that the model is small. Once you understand who the permission applies to, what the letters mean, and how to change them, most permission problems become much easier to read and fix.

This guide is written for beginners, but I also added short notes that professionals can use as a quick refresh.

Why Linux permissions matter

Permissions answer a simple question:

• Who can read this file?
• Who can change it?
• Who can run it?

Linux uses permissions to protect system files, private data, scripts, shared folders, and production servers.

If the permissions are too open, other users or processes may change things they should not touch.

If the permissions are too strict, even the right user gets Permission denied.

That is why learning the basics of rwx, ownership, and chmod is worth it very early.

Reading ls -l output

Start with a real example:

$ ls -l deploy.sh
-rwxr-x--- 1 charaf devops 842 Apr 30 09:15 deploy.sh

Here is what each part means:

The important part for most beginners is this block:

-rwxr-x---

You can split it like this:

- | rwx | r-x | ---
  owner  group  others

That means:

• The owner can read, write, and execute.
• The group can read and execute.
• Others have no access.

What r, w, and x mean

The letters are short, but they do slightly different things for files and directories.

Two details matter a lot here:

• A text file does not need x unless you want to run it.
• A directory usually needs x to be useful. Without it, you may know the directory exists but still not be able to enter it.

Professional refresh: deleting a file is controlled mainly by the parent directory permissions, not the file's own write bit. If delete behavior looks strange, inspect the directory first.

User, group, and others

Linux checks permissions in three buckets:

• User: the owner of the file
• Group: users who belong to the file's group
• Others: everyone else on the system

For example, look at this file:

-rw-r-----

This means:

• Owner: rw- -> can read and write
• Group: r-- -> can only read
• Others: --- -> no access

That pattern is very common for files that should stay private except for one team or service account.

To see who you are and what groups you belong to, these commands help:

whoami
id
groups

If you are checking a directory itself, use ls -ld so Linux shows the directory permissions instead of listing the directory contents.

ls -ld project/

Common permission strings you will often see

Here are a few examples that are worth learning by sight:

You do not have to memorize all of them at once. The main goal is to get comfortable splitting the string into owner, group, and others.

Changing permissions with chmod

chmod means change mode.

It is the command you use to change permission bits on a file or directory.

There are two common ways to use it:

• symbolic mode
• numeric mode

Both are worth knowing.

Method 1: symbolic mode

Symbolic mode is very readable, so it is great when you are learning.

The common letters are:

• u for user
• g for group
• o for others
• a for all

The common operators are:

• + to add a permission
• - to remove a permission
• = to set permissions exactly

Examples:

chmod u+x backup.sh
chmod g-w report.txt
chmod o-r secret.txt
chmod a+r notes.txt
chmod u=rw,g=r,o= todo.txt

What they do:

• chmod u+x backup.sh adds execute permission for the owner
• chmod g-w report.txt removes write permission from the group
• chmod o-r secret.txt stops others from reading the file
• chmod a+r notes.txt gives read permission to everyone
• chmod u=rw,g=r,o= todo.txt sets the exact permissions to owner read/write, group read, others none

If you only need a small change, symbolic mode is usually the clearest choice.

Method 2: numeric mode

Numeric mode is shorter and very common in real systems.

Each permission has a number:

You add the numbers for each group:

• 7 = 4 + 2 + 1 = rwx
• 6 = 4 + 2 = rw-
• 5 = 4 + 1 = r-x
• 4 = r--
• 0 = ---

So:

chmod 644 notes.txt

means:

• owner: 6 -> rw-
• group: 4 -> r--
• others: 4 -> r--

More useful examples:

chmod 600 ~/.ssh/id_ed25519
chmod 644 article.md
chmod 755 script.sh
chmod 700 private-dir
chmod 750 team-folder

These are common patterns:

One easy mistake: 644 works for a regular file, but it is usually wrong for a directory because directories usually need x to be usable.

Changing ownership with chown

Permissions tell Linux what each class can do.

Ownership tells Linux which user and group the file belongs to.

Use chown to change the owner:

sudo chown alice notes.txt

Use this form to change owner and group together:

sudo chown alice:developers deploy.sh

And this form works recursively on everything inside a directory:

sudo chown -R alice:developers project/

Be careful with -R. Recursive ownership changes are powerful, but they can also affect many files very fast.

In most Linux systems, changing the owner usually needs sudo or root privileges.

Changing group with chgrp

If you only need to change the group, use chgrp.

sudo chgrp developers shared-report.txt
sudo chgrp -R www-data public/uploads/

This is useful when a file should stay with the same owner but needs to be shared with a different team or service.

You can also change the group with chown by leaving the owner blank:

sudo chown :developers shared-report.txt

That is handy when you want one command style for both owner and group changes.

Beginner-friendly examples

Make a script executable

You wrote a shell script called backup.sh and want to run it directly.

chmod u+x backup.sh
./backup.sh

If the script should be runnable by other users too, you might use:

chmod 755 backup.sh

Keep a private key private

SSH keys should be readable only by the owner.

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

If these permissions are too open, SSH may refuse to use the key.

Share a directory with a team

You have a folder that only you and your group should access.

sudo chown alice:developers shared/
chmod 750 shared/

That gives full access to alice, read and execute to the developers group, and no access to others.

Fix a simple "Permission denied" error

When you hit a permission problem, check things in this order:

ls -l file.txt
ls -ld parent-directory/
id

This tells you:

• the file permissions
• the parent directory permissions
• your current user and groups

That small checklist solves a surprising number of permission problems.

Tips and best practices

• Start with the least privilege you need, then open access only if there is a real reason.
• Avoid chmod 777 as a quick fix. It often solves the symptom by making the file writable by everyone, which is usually too open.
• Be careful with recursive commands like chmod -R and chown -R. Always pause before running them on large directories.
• Remember that file permissions and directory permissions are related but not identical.
• Use groups for team access instead of moving ownership around between individual users all the time.
• For web apps and shared systems, treat 644 for files and 755 for directories as common starting points, not as a universal rule.
• Inspect first, change second. ls -l, ls -ld, and id should become habit.

Quick refresh notes for professionals

If you already know the basics and just want the details that often matter in production, keep these in mind:

• Unlink and rename are controlled by the parent directory, so file bits alone do not explain all delete behavior.
• Default permissions come from both the creating program and the current umask.
• For shared team directories, setgid can keep new files in the same group: chmod 2775 shared/.
• For shared scratch directories, the sticky bit limits deletes to owners and root: chmod +t shared-tmp/.
• If the classic owner/group/others model is too coarse, use ACLs with tools like getfacl and setfacl.

Professional refresh: chown user:group file is often all you need. Use chgrp when you want to make the group change explicit or keep command intent very obvious for readers.

A quick cheat sheet

Final mental model

When you look at Linux permissions, think in this order:

1. Who is the access for: owner, group, or others?
2. What can they do: read, write, execute?
3. How do I adjust it: chmod, chown, or chgrp?

If you can answer those three questions, the permission string stops looking mysterious and starts feeling predictable.

And when something still feels off, inspect before changing:

ls -l
ls -ld .
id

That is a much better habit than guessing, and far better than reaching for 777.