File Permissions in Linux Explained for Beginners (2026)

Linux file permissions are read, write, and execute rights stored on every file and folder, assigned to three groups of people: the owner, the owning group, and everyone else. These rights decide who can open a file, change it, or run it as a program. Understanding them is the difference between a command that works and a stubborn Permission denied.

Linux file permissions are a set of read (r), write (w), and execute (x) rights assigned to three categories — the owner, the group, and everyone else — on every file and directory. They control who can view a file, modify it, or run it.

This guide takes the practical route: real terminal output first, then the rules behind it. By the end you will read a permission string without guessing, change it safely, and know when to reach for ownership instead of permissions.

Table of Contents

• What Are File Permissions in Linux?
• How Do I Read Linux File Permissions?
• The file type character
• The permission string
• The remaining fields
• Do File Permissions Mean the Same Thing for Folders?
• What Do the Owner, Group, and Others Mean?
• How Do Numeric and Symbolic Permissions Work?
• Symbolic mode spells out who and what
• How Do I Change Linux File Permissions?
• Create the file and hit the error
• Read the current state
• Fix it and verify
• What to set for common situations
• Use recursion carefully
• umask sets what you get by default
• Permission denied: a short checklist
• Command cheat sheet
• How Do File Ownership and Special Permissions Differ?
• Frequently Asked Questions
• What does chmod 777 mean in Linux?
• What does chmod 444 mean?
• What are the 7 types of files in Linux?
• How do I set a sticky bit in Linux?
• How do I remove write permission for everyone except the owner?
• What is the difference between chown and chmod?
• Conclusion

What Are File Permissions in Linux?

Every file and directory in Linux carries a mode. The mode decides, for each of three categories, whether that category can read, write, or execute.

Three categories, always in the same order: owner (the user who created the file, unless ownership was changed), group (the users who share a group name with the file), and others (everybody else on the system).

Three rights in each category: r for read, w for write, x for execute. Nine possible rights per file, and a single missing letter is often the reason something will not run.

The rest of file permissions in Linux, explained for beginners, comes down to two skills: reading that string correctly and changing it on purpose.

To answer the question that sends most beginners looking: chmod 777 gives read, write, and execute rights to the owner, the group, and everyone else. It is the most permissive setting possible. It also means any account on the machine, including a compromised web service, can edit your files. It is a diagnostic smell, not a fix.

Permissions matter because they are the primary access control on the machine. Set too tight and legitimate work fails. Set too loose and private keys, configuration files, and source code become readable and editable by anyone who gets an account.

How Do I Read Linux File Permissions?

Run ls -l in any directory and you get the long listing. Here is a real line:

-rw-r-----  1 sam  developers  4820 Sep 28 09:14 report.txt

Ten characters and five more fields. Here is what each one means.

The file type character

The first character says what kind of thing this is, not anything about access.

Character	Meaning	Example
–	Regular file	notes.txt
d	Directory	projects/
l	Symbolic link	latest -> v2.1
p	Named pipe (FIFO)	app_events
s	Socket	web.sock
c	Character device	/dev/null
b	Block device	/dev/sda1

The permission string

The next nine characters are three triplets in fixed order: owner, group, others. Each triplet is up to three letters — r, w, x — and always in that order.

rw- r-----
|   |    |
|   |    └── others:  read only
|   └─────── group:   read only
└─────────── owner:   read and write, no execute

Read it right to left as a sentence: others can read it, the group can read it, the owner can read and write it.

The remaining fields

In the sample line, 1 is the link count, sam is the owner, developers is the group, 4820 is the size in bytes, and the rest is the modification date and time.

stat report.txt gives you the same information with more detail, including the file type in words and the permissions in octal. Handy when you want the number rather than the letters.

Do File Permissions Mean the Same Thing for Folders?

No, and this trips up more beginners than the numbers do. On a directory, the same three letters describe different actions.

Right	On a file	On a directory
r (read, 4)	Open and view the contents	List the names inside (ls)
w (write, 2)	Edit, truncate, or delete the file	Create files, rename files, delete entries inside
x (execute, 1)	Run the file as a program	Enter the directory and reach files inside it

That third row explains the classic stumble for anyone moving over from Windows. A directory with r but no x can be listed but not entered. ls succeeds, cd fails with permission denied.

The x bit on a directory is a traversal bit. Without it, the names are visible but the contents behind them are unreachable.

What Do the Owner, Group, and Others Mean?

The owner is a single user. The group is a named set of users, and one group is the owning group of the file. Others is everyone not caught by the first two categories.

Linux uses the first matching category. If you own the file, your owner rights apply and the group and others columns are ignored. Only when you are not the owner does the group column get checked, using any group you belong to.

Users are recorded in /etc/passwd, groups in /etc/group, each with a numeric UID and GID behind the name. id shows your own UID, GID, and every group you belong to — run it before you assume you are not in the owning group.

A concrete case. Sam creates report.txt, and Sam’s primary group is developers. The file comes out owned by sam developers. Priya is also in developers, so the group column applies to her. Everyone else falls under others, and a dash there means no access at all.

This is why group-based access beats blanket permissions. A shared project folder set to 770 gives Sam and the whole developers group full access and nobody else anything, which is what you want and costs nothing in security.

How Do Numeric and Symbolic Permissions Work?

Linux can express the same permissions two ways: letters, or an octal number. The number is just a sum of three fixed values.

Read is worth 4, write is worth 2, execute is worth 1. Add the values up for each triplet and you have three digits.

So rwx is 4 plus 2 plus 1, which is 7. rw- is 4 plus 2, which is 6. r-- is just 4. r-x is 4 plus 1, which is 5.

Write the sums out and you get the number you type after chmod:

Command	Symbolic	Plain meaning	Typical use
chmod 644	-rw-r–r–	Owner reads and writes, everyone else reads	Config files, documents, source code
chmod 600	-rw——-	Only the owner reads or writes	SSH private keys, secrets, tokens
chmod 700	-rwx——	Owner does everything, nobody else anything	Private directories, a personal bin folder
chmod 755	-rwxr-xr-x	Owner controls it, everyone else reads and runs	Scripts, web root directories
chmod 775	-rwxrwxr-x	Owner and group full, others read and execute	Shared project folders with a group
chmod 770	-rwxrwx—	Owner and group full, others nothing	Team folders, private databases
chmod 444	-r–r–r–	Everyone can read, nobody can change it	Locking a file against edits
chmod 777	-rwxrwxrwx	Everyone can do anything	Almost never — avoid it

Note the ordering. 770 means owner-group-others. 707 is a different, and almost certainly wrong, thing. People mix them up when guessing at numbers instead of adding up the letters.

Symbolic mode spells out who and what

Symbolic chmod names the category instead of assigning a whole triplet. The letters are u for user (owner), g for group, o for others, and a for all three. The operators matter: + adds a right, - removes one, and = sets the triplet to exactly what you list.

chmod u+x script.sh     # owner can run it
chmod g-w notes.txt     # group loses write
chmod o+r notes.txt     # others gain read
chmod a=r notes.txt     # everybody gets read, and nothing else
chmod o-w notes.txt     # remove write from everybody but the owner

The last one answers a question that shows up constantly: removing write permission for everybody except the owner. chmod o-w notes.txt strips write from others only, leaving the owner’s rights alone. chmod 644 notes.txt reaches the same end state by setting all three triplets at once.

One habit worth building early: symbolic operators add and remove, they do not set. chmod u+x on a file that already has u+rw gives you u+rwx, not just execute.

How Do I Change Linux File Permissions?

Here is the whole loop, from nothing to a working result. You need a shell, which you have on Linux or in WSL on Windows.

Create the file and hit the error

mkdir -p ~/lab
cd ~/lab
echo "hello" > run.sh
./run.sh
bash: ./run.sh: Permission denied

The file exists, the content is correct, and the shell still refuses. That message almost always means the x bit is missing, not that the file is broken.

Read the current state

ls -l
-rw-r--r-- 1 sam sam 6 Oct  3 10:02 run.sh

Owner has rw, everyone else has r, and no category has x.

Fix it and verify

chmod u+x run.sh
ls -l
-rwxr--r-- 1 sam sam 6 Oct  3 10:02 run.sh
./run.sh
hello

Watch the listing change after every chmod. That before-and-after moment is where the concept usually clicks for people who came from Windows, where executability is an extension and an ACL rather than a bit in a mode string.

What to set for common situations

Situation	Command	Why
Run a shell script	chmod 755 script.sh	Owner controls it, anyone can run it
Keep a file truly private	chmod 600 secrets.env	Owner only, group and others blocked
Share a folder with your team	chmod 770 project/ and set the group	Team in, everybody else out
Web root folder	chmod 755 /var/www/site	Web server can traverse it
Web content files	chmod 644 index.html	Server reads, visitors never write
SSH private key	chmod 600 ~/.ssh/id_ed25519	SSH refuses anything more open

For a shared team folder that stays correct as people add files, the setgid bit does the work for you:

sudo chgrp -R developers /srv/project
sudo chmod 2770 /srv/project

The leading 2 sets setgid on the directory, so anything created inside automatically inherits the group instead of the creator’s own group. New files stay group-writable without anyone thinking about it.

Use recursion carefully

chmod -R 755 ~/lab walks every subdirectory and rewrites the mode of everything it finds. That is occasionally what you want, and it is how people end up with world-readable SSH keys inside a copied directory tree.

Two safer habits. First, be more specific than you think you need to be — target the file, not the tree. Second, when you do need -R, keep numbers narrow: 644 for files and 755 for directories rather than one blanket value.

If you already ran chmod -R 777 somewhere, that is reversible, but the system did not record what the modes used to be. You restore safe values with chmod -R u=rwX,go=rX on a file tree and chmod -R u=rwx,g=rx,o=rx on a directory tree. Then check anything sensitive in there for damage.

umask sets what you get by default

Every time a file is created, its base mode starts at 666 for files and 777 for directories, then your umask is subtracted from it. The umask is the set of rights new files do not get.

umask
0022

touch new.txt && ls -l new.txt     # -rw-r--r--  (644)
mkdir newdir && ls -ld newdir     # drwxr-xr-x  (755)

The arithmetic is simple subtraction: 666 minus 022 gives 644, and 777 minus 022 gives 755. The default umask on most desktop and server distributions is 022.

This answers a question that comes up often on forums: why does umask 0000 still not make new files executable? Because the base mode for files is 666, which has no x to begin with. A file only becomes executable when you or your umask situation explicitly adds that bit. To make scripts land executable automatically, some people set a group default ACL with setfacl -d -m g:x on the target folder.

Permission denied: a short checklist

When something refuses to work, work down this list instead of reaching for 777.

1. Read the mode with ls -l and check the failing category’s triplet.
2. Confirm every directory in the path has the x bit. You need it on the parent folder, not just the file.
3. Check ownership with id and ls -l. If the file belongs to root and you are not, permissions alone will not help.
4. Decide whether this needs root. sudo solves privilege, chmod solves access — different problems.
5. For scripts, check the shebang line points at an interpreter that exists.
6. If the mode looks correct and root still fails, suspect SELinux or AppArmor. Those denials look like permission denied and no amount of chmod will fix them.

Command cheat sheet

Command	What it does	Needs sudo
ls -l	Show mode, owner, and group	No
chmod 644 file	Set permissions numerically	Only for files you do not own
chmod u+x file	Add or remove rights by name	Only for files you do not own
chmod -R 755 dir	Apply to a whole tree	Usually yes
chown sam:developers file	Change owner and group	Yes
chgrp developers file	Change group only	Yes
umask / umask 022	Show or set the default mask	No
stat file	Detailed metadata and octal mode	No
find . -perm 777	Find files with loose permissions	For a full audit, yes
getfacl / setfacl	Read and write POSIX access control lists	For files you do not own, yes

How Do File Ownership and Special Permissions Differ?

chmod changes the mode. chown changes who the file belongs to. Keeping those separate solves half of all permission confusion.

chown sam:developers report.txt sets the owner and the group in one go. chown sam report.txt changes only the owner, chgrp developers report.txt changes only the group.

Changing ownership almost always needs root, so sudo chown is the normal form. That is also why ownership is the better answer than a wide chmod when a service account needs to write into a directory. Hand the directory to the service’s group, keep the mode at 770, and no permissions get loosened.

Three extra bits sit above the rwx triplets.

setuid on a file runs it with the permissions of the file’s owner, which is how passwd lets a normal user change a password. You see it as an s in place of the owner’s x. Reach for it rarely.

setgid on a file runs it with the owning group’s permissions. On a directory, which is the more useful case, it forces new files to inherit the directory’s group. That is the shared team folder recipe from earlier, set with a leading 2 or 3 in octal.

The sticky bit on a directory lets anyone create and delete entries, but only the owner of an entry can remove it. That is exactly how /tmp behaves, and it is why a shared temp directory shows up as drwxrwxrwt. Set it with chmod +t folder or chmod 1777 folder when you genuinely need a world-writable folder and cannot avoid it.

Two further layers exist beyond modes. POSIX ACLs let you grant rights to specific users or groups without inventing a new group for one person, read with getfacl and written with setfacl. SELinux on RHEL-family systems and AppArmor on Debian-family systems sit even higher and can deny access that the mode bits permit. Neither is something to disable because of a permission error.

Frequently Asked Questions

Conclusion

Start with four steps and you will handle most Linux permission problems. Look at the file with ls -l. Work out whether the problem is the mode or the ownership, since chmod and chown fix different things. Grant the narrowest access that does the job, usually 644 for a file, 755 for a directory, 600 for anything private, and 770 for a team folder. Then look again and confirm the change landed.

File permissions in Linux only look arbitrary until you see each letter as a decision someone made about a person. Once you can read that string fluently, the mode stops being magic numbers and becomes a dial you set on purpose.