Linux Permissions and Ownership Explained Without Jargon

10 Aug 2026

Linux permissions are often made to sound more complicated than they really are.

At their core, permissions answer three simple questions:

Who owns this file?
Who is allowed to use it?
What are they allowed to do?

Once those three ideas are clear, commands such as chmod, chown and chgrp become much easier to understand.

This guide explains Linux permissions and ownership in plain English, with practical examples you can use on desktops, servers and shared systems.

Why Permissions Matter

Every file and folder on Linux has rules attached to it.

Those rules stop one user from accidentally changing another user’s files, prevent applications from accessing data they do not need and protect important parts of the operating system.

Without permissions, any user or program could potentially:

Delete system files
Read private documents
Change application settings
Replace scripts
Access backups
Modify website files
Interfere with other users

Permissions are not an optional extra. They are one of the basic ways Linux keeps users, applications and system files separated.

The Three Types of People Linux Thinks About

Linux divides access into three groups.

1. The owner

This is the user who owns the file.

For example, if Carl creates a document, Carl will usually become its owner.

2. The group

A group is a collection of users.

For example, a group called marketing might contain several staff members who all need access to the same folder.

3. Everyone else

This means any user who is not the owner and is not covered by the file’s group permissions.

Linux applies permissions in that order:

Owner
Group
Everyone else

The Three Basic Permissions

Each file or folder can allow three actions.

Read

Read permission means you can view the contents.

For a file, this means opening or reading it.

For a directory, it means seeing the names of files inside it.

Read is shown as:

Write

Write permission means you can change something.

For a file, this means editing or overwriting it.

For a directory, it means creating, deleting or renaming items inside it.

Write is shown as:

Execute

Execute permission means something can be run or entered.

For a file, this usually means it can be run as a program or script.

For a directory, it means you can enter it and access items inside it.

Execute is shown as:

How to View Permissions

Use:

ls -l

Example:

-rw-r----- 1 carl marketing 2048 Aug 1 09:30 report.txt

This line contains several pieces of information:

-rw-r-----

These are the permissions.

carl

This is the owner.

marketing

This is the group.

report.txt

This is the file name.

Reading the Permission String

Take this example:

-rw-r-----

The first character tells you what kind of item it is.

means a normal file.

A directory would begin with:

The remaining nine characters are split into three groups:

rw- r-- ---

These represent:

owner group everyone else

So:

rw-

means the owner can read and write.

r--

means the group can read only.

---

means everyone else has no access.

A Simple Permission Example

Suppose you see:

-rwxr-x---

Break it into three parts:

rwx r-x ---

This means:

The owner can read, write and execute.
The group can read and execute.
Everyone else has no access.

Files and Folders Behave Differently

The same letters apply to files and directories, but their meaning changes slightly.

File permissions

For a file:

r means read the file.
w means change the file.
x means run the file.

Directory permissions

For a directory:

r means list the names inside it.
w means add, remove or rename items inside it.
x means enter the directory and access its contents.

This difference is important.

A user may be able to see a file name but still be unable to open it if the directory does not allow execute access.

Changing Permissions With

chmod

The command used to change permissions is:

chmod

The name stands for “change mode”.

There are two main ways to use it:

Letter-based permissions
Number-based permissions

The letter-based method is usually easier to understand at first.

Add a Permission

Give the owner execute permission:

chmod u+x script.sh

Here:

means user, which refers to the owner.

means add.

means execute.

Remove a Permission

Remove write access from the group:

chmod g-w report.txt

Here:

means group.

means remove.

means write.

Give Everyone Read Permission

Use:

chmod a+r document.txt

Here:

means all.

Set Permissions Exactly

Give the owner read and write permission, the group read permission and everyone else no access:

chmod u=rw,g=r,o= report.txt

The letters mean:

u — owner
g — group
o — others
a — all users

Understanding Number Permissions

You may have seen commands such as:

chmod 755 script.sh

or:

chmod 644 document.txt

These numbers are just a shorter way to express the same permissions.

Each permission has a value:

read = 4

write = 2

execute = 1

Add the values together.

For example:

read + write = 4 + 2 = 6

read + execute = 4 + 1 = 5

read + write + execute = 4 + 2 + 1 = 7

What Does

755

Mean?

Split it into three numbers:

7 5 5

These represent:

owner group everyone else

So:

7 = read + write + execute

5 = read + execute

That gives:

rwxr-xr-x

This is common for directories and executable scripts.

What Does

644

Mean?

Split it into:

6 4 4

That means:

6 = read + write

4 = read

The result is:

rw-r--r--

This is common for ordinary files.

Common Permission Numbers

600

rw-------

Only the owner can read and write.

Useful for:

Private keys
Credential files
Personal configuration
Sensitive documents

Example:

chmod 600 private-key

644

rw-r--r--

The owner can read and write. Everyone else can read.

Useful for:

Normal text files
Public configuration files
Website content

700

rwx------

Only the owner has access.

Useful for:

Private directories
Personal scripts
Sensitive application folders

755

rwxr-xr-x

The owner can make changes. Everyone else can enter or run but not modify.

Useful for:

Public directories
Scripts
Application folders

770

rwxrwx---

The owner and group have full access. Everyone else has none.

Useful for shared team folders.

Changing the Owner With

chown

The command for changing ownership is:

chown

To change the owner of a file:

sudo chown carl report.txt

To change both the owner and group:

sudo chown carl:marketing report.txt

This means:

Owner becomes carl
Group becomes marketing

Change Only the Group

Use:

sudo chown :marketing report.txt

Or use:

sudo chgrp marketing report.txt

Both can change the group.

Changing Ownership Recursively

To change an entire directory and everything inside it:

sudo chown -R carl:marketing /srv/reports

The -R means recursive.

This applies the change to:

The directory
Every subdirectory
Every file inside

Be very careful with recursive ownership changes.

A command aimed at the wrong path could change thousands of files and break applications or system services.

Check the path before pressing Enter.

Changing Permissions Recursively

You can also use chmod -R:

sudo chmod -R 755 /srv/website

However, this is often a bad idea.

Files and directories usually need different permissions.

For example:

Directories may need 755.
Files may need 644.

Setting every file to 755 gives execute permission to documents, images and configuration files that do not need it.

A better approach is:

find /srv/website -type d -exec chmod 755 {} \;

Then:

find /srv/website -type f -exec chmod 644 {} \;

This gives directories and files suitable permissions separately.

Why “Permission Denied” Happens

A permission-denied message means the current user is not allowed to perform the requested action.

Example:

Permission denied

Possible causes include:

The file belongs to another user.
The group permissions do not allow access.
The directory above it blocks access.
The file is read-only.
The script is not executable.
The filesystem is mounted read-only.
A security system such as SELinux or AppArmor is blocking access.
The current user needs administrative privileges.

Do not automatically solve every permission problem with sudo.

First check who owns the file and which permissions are set.

Troubleshooting a Permission Problem

Start with:

ls -l filename

For a directory:

ls -ld directory

The -d option shows the directory itself rather than its contents.

Example:

drwxr-x--- 2 root developers 4096 Aug 1 10:00 project

This means:

Owner: root
Group: developers
Owner has full access.
Group can read and enter.
Everyone else has no access.

Check your current user:

whoami

Check your groups:

groups

or:

If your user is not in the required group, that may explain the problem.

Add a User to a Group

To add a user to an existing group:

sudo usermod -aG developers carl

The important option is:

-aG

This means append the user to the group.

Do not use -G by itself unless you intend to replace the user’s existing supplementary groups.

The user usually needs to log out and back in before the new group membership takes effect.

You can check membership with:

groups carl

Create a Shared Group Folder

Suppose several users need to work in:

/srv/shared

Create a group:

sudo groupadd sharedteam

Add users:

sudo usermod -aG sharedteam carl

sudo usermod -aG sharedteam alice

Create the directory:

sudo mkdir -p /srv/shared

Set the owner and group:

sudo chown root:sharedteam /srv/shared

Set suitable permissions:

sudo chmod 2770 /srv/shared

The result is similar to:

drwxrws---

The 2 at the start enables the set-group-ID bit on the directory.

This helps new files inherit the directory’s group instead of each user’s personal group.

What Is the Set-Group-ID Bit?

On a shared directory, the set-group-ID bit makes new files and folders inherit the group of the parent directory.

Without it, a file created by Carl might belong to Carl’s normal group instead of the shared team group.

Enable it with:

chmod g+s /srv/shared

Or numerically:

chmod 2770 /srv/shared

Check the result:

ls -ld /srv/shared

You may see:

drwxrws---

The s in the group execute position shows that the setting is enabled.

What Is the Sticky Bit?

The sticky bit is useful for directories where many users can create files, but users should not delete each other’s files.

The classic example is:

/tmp

Check it:

ls -ld /tmp

You may see:

drwxrwxrwt

The final t represents the sticky bit.

Without it, anyone with write access to the directory could potentially delete someone else’s files.

Enable it with:

chmod +t shared-directory

Or numerically:

chmod 1777 shared-directory

What Is

umask

When a new file or directory is created, Linux uses a setting called umask to decide which permissions should be removed from the default.

Check the current value:

umask

A common value is:

0022

This often results in:

New files being created as 644
New directories being created as 755

A more private value is:

0077

This normally results in:

New files as 600
New directories as 700

Set it temporarily:

umask 0077

This affects files created by the current shell after the change.

Permanent settings may be stored in shell profiles or system configuration, depending on the distribution.

Why New Files Are Not Executable

New files normally do not receive execute permission automatically.

This is deliberate.

A newly created text file should not become executable simply because it exists.

To make a script executable:

chmod +x script.sh

Then run it:

./script.sh

The script should also begin with an appropriate interpreter line, such as:

#!/usr/bin/env bash

Ownership After Using

sudo

A common mistake is running ordinary applications with sudo.

For example:

sudo text-editor document.txt

This may cause the file to become owned by root.

Later, the normal user cannot edit it.

Check:

ls -l document.txt

Correct the ownership:

sudo chown carl:carl document.txt

Avoid launching desktop applications or normal user tools with sudo unless there is a clear reason.

Website File Permissions

Website permissions often need to balance two requirements:

The web server must be able to read the site.
Only authorised users should be able to change it.

A common starting point is:

sudo chown -R deploy:www-data /var/www/example

Then set directories:

sudo find /var/www/example -type d -exec chmod 755 {} \;

And files:

sudo find /var/www/example -type f -exec chmod 644 {} \;

The correct user and group depend on the distribution and web server.

Possible web-server users include:

www-data

apache

nginx

Do not make a website directory 777 just to make an error disappear.

Why

777

Is Usually a Bad Fix

Permission 777 means:

rwxrwxrwx

Everyone can read, write and execute.

It is often used as a quick attempt to fix permission problems:

chmod 777 folder

This may appear to solve the immediate error, but it creates a much larger security problem.

Any local user or compromised service may be able to modify the content.

A safer approach is to determine:

Which user needs access?
Which group should own the files?
Does the application need read, write or execute access?
Can access be limited to one directory?

Then grant only the permissions required.

Files Owned by

root

Many system files are owned by root because ordinary users should not be able to change them.

Example:

-rw-r--r-- 1 root root 3028 Aug 1 08:00 /etc/example.conf

This usually means:

Root can read and write.
Everyone else can read.
Only root can modify the file.

Edit such files using an administrative editor:

sudo nano /etc/example.conf

Do not change ownership of system files merely to make editing easier.

Check Every Directory in a Path

A user may have permission on a file but still be unable to access it because one of the parent directories blocks access.

Use:

namei -l /srv/projects/client/report.txt

This shows the ownership and permissions of every part of the path.

Example:

f: /srv/projects/client/report.txt

drwxr-xr-x root root /

drwxr-xr-x root root srv

drwxr-x--- root developers projects

drwxrwx--- carl developers client

-rw-rw---- carl developers report.txt

If the user cannot enter /srv/projects, access to the file below it will fail even if the file itself appears readable.

Access Control Lists

Traditional owner, group and other permissions are sometimes too limited.

Suppose a file belongs to Carl and the finance group, but Alice also needs access without joining that group.

Access Control Lists, or ACLs, allow additional permissions for specific users or groups.

View ACLs with:

getfacl report.txt

Give Alice read access:

setfacl -m u:alice:r report.txt

Give a group read and write access:

setfacl -m g:auditors:rw report.txt

Remove Alice’s special entry:

setfacl -x u:alice report.txt

ACLs are useful, but they can make permissions less obvious from a basic ls -l display.

A plus sign may indicate additional ACL entries:

-rw-r-----+

Use getfacl when you see that +.

Default ACLs for Shared Folders

A default ACL can make new files inherit extra permissions.

For example:

sudo setfacl -m d:g:sharedteam:rwx /srv/shared

This adds a default ACL for the group.

Also set the current directory ACL:

sudo setfacl -m g:sharedteam:rwx /srv/shared

Check it:

getfacl /srv/shared

Default ACLs can be useful for teams, but they should be documented because they are not always obvious to administrators checking only standard permission bits.

SELinux and AppArmor

Sometimes standard permissions look correct, but access is still denied.

This may be caused by an additional security system.

Common examples are:

SELinux
AppArmor

These systems can restrict what an application is allowed to access even when normal file permissions would permit it.

On SELinux systems, check the current mode:

getenforce

Possible results include:

Enforcing

Permissive

Disabled

Check recent denials:

sudo ausearch -m AVC -ts recent

On systems using AppArmor:

sudo aa-status

Do not disable SELinux or AppArmor automatically. They may be correctly blocking unsafe application behaviour.

Investigate the policy and file context instead.

Read-Only Filesystems

A file may show write permission but still be impossible to change if the filesystem itself is mounted read-only.

Check:

findmnt

Or for a specific path:

findmnt /path/to/file

Look for:

in the mount options.

A filesystem may become read-only because of:

Filesystem errors
Disk problems
A deliberate mount option
Recovery mode
Storage device faults

Changing file permissions will not solve a read-only filesystem.

Common Permission Mistakes

Using

sudo

for everything

This can create root-owned files in user directories and hide the real issue.

Setting

777

This gives far more access than most applications require.

Changing ownership of system files

This can break package updates, services and security assumptions.

Using

chmod -R

without checking

Recursive changes can alter thousands of files.

Giving execute permission to every file

Documents and configuration files usually do not need it.

Forgetting parent directory permissions

Access can fail higher up the directory path.

Forgetting group membership changes need a new login

The user may need to sign out and back in.

Ignoring ACLs

A file may have extra access rules not visible in the basic permission string.

Ignoring SELinux or AppArmor

Standard permissions may not be the only security layer involved.

A Safe Troubleshooting Order

When you see “Permission denied”, use this process.

1. Check the current user

whoami

2. Check group membership

3. Check the file

ls -l file

4. Check the directory

ls -ld directory

5. Check every directory in the path

namei -l /full/path/to/file

6. Check ACLs

getfacl file

7. Check the filesystem mount options

findmnt /full/path/to/file

8. Check application security controls

Review SELinux or AppArmor logs where applicable.

9. Change only what is necessary

Use chmod, chown, group membership or ACLs to make the smallest appropriate change.

10. Test as the actual user

For example:

sudo -u carl cat /path/to/file

This confirms whether the intended account now has access.

Practical Examples

Make a script executable

chmod +x backup.sh

Make a private file readable only by its owner

chmod 600 credentials.conf

Make a public document readable by everyone but editable only by the owner

chmod 644 guide.txt

Give a team access to a directory

sudo chown root:developers /srv/project

sudo chmod 2770 /srv/project

Correct a file accidentally owned by root

sudo chown carl:carl document.txt

Give one additional user read access

setfacl -m u:alice:r report.txt

Check why a file cannot be reached

namei -l /srv/project/reports/report.txt

Final Thoughts

Linux permissions become much easier once you stop thinking of them as mysterious numbers and start thinking in plain questions:

Who owns this?
Which group is it shared with?
Can the owner read, write or run it?
Can the group read, write or run it?
What can everyone else do?

The numbers are only shorthand.

644 means the owner can read and write while everyone else can read.

755 means the owner can do everything while everyone else can read and enter or run.

600 means the file is private.

The safest approach is always to give users and applications only the access they need. Avoid broad fixes such as 777, check ownership before changing permissions and make recursive changes only after confirming the exact path.

Need Help Fixing Linux Permission Problems?

Hamilton Group can help troubleshoot Linux file access, ownership errors, shared folders, application permissions and security controls.

We can identify why users or services are being denied access and correct the problem without weakening the security of the wider system.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT specialists.