chmod in depth: symbolic and numeric permissions, folder permissions and who can delete a file

By Ravindra Bagale, trainer · LinkedIn · Last updated: 8 October 2026

1. Quick recap: the ten characters

Why. Every chmod you type changes some of these ten characters, so you need to read them in one glance.

What. On Amazon Linux, a new file and a new folder made by ec2-user look like this:

[ec2-user@ip-172-31-xx-xx ~]$ ls -l
total 4
-rw-rw-r--. 1 ec2-user ec2-user 6 Jan  5 10:15 my.txt
drwxrwxr-x. 2 ec2-user ec2-user 6 Jan  5 10:15 ravi

Reading -rw-rw-r-- from the left:

1. -: the type. - is a file, d is a directory.
2. rw-: the user (owner), the first name, ec2-user.
3. rw-: the group, the second name. A group can have many members, for example ravi and ramesh.
4. r--: others, every other user on the server.

The trailing . is Amazon Linux's SELinux marker; ignore it. Owners, groups, adduser and the first chmod u-w demo are in Linux users, groups, sudo and file permissions. This chapter goes deeper.

2. Symbolic chmod: who, + or -, and which permission

Why. Sometimes you want to change exactly one thing, like "let the group write", and leave everything else as it is. Letters do that.

What. A symbolic mode has three parts, written together with no spaces:

1. who: u user (owner), g group, o others, a all three.
2. what to do: + give, - take away, = set exactly (anything not listed is removed).
3. which permission: r, w, x.

Worked examples. Each one starts again from -rw-r--r--:

chmod u+x my.txt     →  -rwxr--r--
chmod g+w my.txt     →  -rw-rw-r--
chmod o-r my.txt     →  -rw-r-----
chmod a+x my.txt     →  -rwxr-xr-x
chmod u-w my.txt     →  -r--r--r--
chmod u=rw,go=r my.txt  →  -rw-r--r--

1. u+x: the owner may now run it.
2. g+w: group members may now change it.
3. o-r: others can't even read it any more.
4. a+x: everyone may run it.
5. u-w: even the owner can't save changes (the owner can still chmod it back).
6. =: sets those bits exactly. Handy to "reset" a file to rw-r--r--.

3. Many changes in one command

Why. Typing chmod three times for three small changes is slow. You can do them in one go.

How. Two ways:

1. Commas between separate changes, with no space after the comma.
2. Several letters in one place: go for group and others, wx for write and execute.

Again starting from -rw-r--r-- each time (checked on the box):

chmod u+x,g+w my.txt   →  -rwxrw-r--
chmod g+wx my.txt      →  -rw-rwxr--
chmod go+x my.txt      →  -rw-r-xr-x
chmod ug+x my.txt      →  -rwxr-xr--
chmod ugo+x my.txt     →  -rwxr-xr-x
chmod a+x my.txt       →  -rwxr-xr-x

ugo and a mean the same thing. And chmod 664 my.txt followed by chmod o-r,g-w my.txt gives -rw-r-----.

A space after the comma breaks the command:

chmod u+x, g+w my.txt
chmod: invalid mode: ‘u+x,’
Try 'chmod --help' for more information.

4. chmod +w and +x with no u, g or o

Why. You'll often see chmod +x script.sh with no letter before the +. Who gets the permission then?

What. With no u, g, o or a, chmod gives the permission to everyone except where your umask blocks it. The umask is the same setting that decides the permissions of new files (more in section 12).

See it. As ec2-user (umask 0002) on a read-only file:

umask
0002
chmod 444 my.txt
chmod +w my.txt
ls -l my.txt
-rw-rw-r--. 1 ec2-user ec2-user 6 Jan  5 10:15 my.txt

The umask 0002 blocks w only for others, so the owner and group got w. As root (umask 0022) the same chmod +w gives only -rw-r--r--, because 0022 blocks the group too.

To give w to everyone, say so with a:

chmod 444 my.txt
chmod a+w my.txt
ls -l my.txt
-rw-rw-rw-. 1 ec2-user ec2-user 6 Jan  5 10:15 my.txt

chmod +x follows the same rule, but these umasks only block w, so chmod +x my.txt on -rw-r--r-- gives -rwxr-xr-x, x for everyone.

Taking away works the same way, and chmod warns you when the umask kept some bits:

chmod 666 my.txt
chmod -w my.txt
chmod: my.txt: new permissions are r--r--rw-, not r--r--r--

5. Numeric chmod: r = 4, w = 2, x = 1

Why. Letters change one thing at a time. A number sets all nine bits at once, exactly. That's why you'll see chmod 755, chmod 644 and chmod 600 in almost every guide.

What. Three digits: the first for the user, the second for the group, the third for others. Each digit is a sum:

1. r = 4
2. w = 2
3. x = 1

So 7 = 4 + 2 + 1 = rwx, 6 = 4 + 2 = rw-, 5 = 4 + 1 = r-x, and 3 = 2 + 1 = -wx.

6. Decoding a number

How. Take one digit at a time, and split it into 4, 2 and 1:

1. Is 4 in it? Then r, else -.
2. Is 2 in what's left? Then w, else -.
3. Is 1 left? Then x, else -.

Worked example: 645.

1. 6 = 4 + 2 → rw- for the user.
2. 4 = 4 → r-- for the group.
3. 5 = 4 + 1 → r-x for others.

So chmod 645 my.txt gives -rw-r--r-x. Here are more, each checked with chmod and ls -l on the box:

755 -> -rwxr-xr-x
645 -> -rw-r--r-x
714 -> -rwx--xr--
514 -> -r-x--xr--
555 -> -r-xr-xr-x
000 -> ----------
777 -> -rwxrwxrwx
444 -> -r--r--r--
644 -> -rw-r--r--
600 -> -rw-------
400 -> -r--------

7. Building a number from a need

Why. At work nobody says "chmod 714". They say "the owner needs everything, the group should only run it, others may only read it". You turn that into a number.

Worked example 1. The need: user rwx, group --x, others r--.

1. User: 4 + 2 + 1 = 7.
2. Group: 1.
3. Others: 4.
4. Answer: chmod 714 my.txt.

Worked example 2. Same as above, but take away the user's write.

1. User: 4 + 1 = 5.
2. Group and others don't change: 1 and 4.
3. Answer: chmod 514 my.txt.

Three quick ones to try in your head:

1. "Only the owner may read and write" → 6, 0, 0 → 600.
2. "Owner everything, group read and run, others nothing" → 7, 5, 0 → 750.
3. "Everyone may read, nobody may change it" → 4, 4, 4 → 444.

8. Special numbers: 555, 000, 777 and 444

What.

1. 555 = r-x for all: everyone may read and run, nobody may change it.
2. 000 = nothing for anybody.
3. 777 = everything for everybody.
4. 444 = read-only for everybody.

000 is not a trap for the owner. The owner can't read the file, but can always chmod it back, and root still reads it:

chmod 000 my.txt
cat my.txt
cat: my.txt: Permission denied
sudo cat my.txt
hello
chmod 644 my.txt
cat my.txt
hello

777 is a bad habit on a server. Any user, or any program that gets broken into, can change a 777 file, for example a script that root runs later. If a file "doesn't work", find the bit that's missing instead of opening everything. A good repair after a 777 is chmod 644 (or chmod 444 if nobody should change it).

9. Numbers or letters?

When to use which:

1. Numbers when you know the final result you want: chmod 644 index.html. All nine bits are set, whatever they were before.
2. Letters when you want one change and want the rest left alone: chmod u+x my.sh.

For example, on a file that is -rw-rw-r--, chmod u+x gives -rwxrw-r--, but chmod 744 gives -rwxr--r--: the number also removed the group's w.

10. Root-owned files: sudo chmod

Why. A file made with sudo belongs to root, and that changes who may chmod it.

See it. Root writes a small script:

sudo nano a.txt
ls -l a.txt
-rw-r--r--. 1 root root 36 Jan  5 10:15 a.txt

The file holds two lines, #!/bin/bash and echo "Hello from a.txt". Now try it as ec2-user:

chmod 777 a.txt
chmod: changing permissions of 'a.txt': Operation not permitted
./a.txt
-bash: ./a.txt: Permission denied

1. chmod is refused because only the owner (root) or root via sudo may change the mode.
2. ./a.txt is refused because nobody has x yet.

Fix it the right way, with 755, not 777:

sudo chmod 755 a.txt
ls -l a.txt
-rwxr-xr-x. 1 root root 36 Jan  5 10:15 a.txt
./a.txt
Hello from a.txt

Root skips the r and w checks, but not this one: to run a file, at least one x bit must be set. On a 666 file even root gets Permission denied.

11. The 766 vs 776 question

Why. The board said that for this root-owned a.txt, 766 doesn't let ec2-user run it but 776 does. Let's work it out instead of believing it.

Who is ec2-user here? The file is root root. ec2-user isn't the owner, and isn't in the group root, so it gets the others bits, the last digit.

1. 766: others = 6 = rw-. No x.
2. 776: others = 6 = rw-. Still no x.

So both are denied. Tested on the box with a real root root file:

sudo chmod 766 a.txt
./a.txt
-bash: ./a.txt: Permission denied
sudo chmod 776 a.txt
./a.txt
-bash: ./a.txt: Permission denied

776 only works when the file's group is one that ec2-user belongs to, because then ec2-user gets the middle digit, 7:

sudo chown root:ec2-user a.txt
sudo chmod 776 a.txt
./a.txt
Hello from a.txt
sudo chmod 766 a.txt
./a.txt
-bash: ./a.txt: Permission denied

The same idea explains 700 and 770: 700 lets only root run it (sudo ./a.txt), and 770 works for ec2-user only if the group is ec2-user. One more detail: bash must also read a script. With 711 (x but no r for others) you get /bin/bash: ./a.txt: Permission denied.

12. Which numbers to use

A short list to remember:

You met chmod 400 already in Inside an EC2 server, when you locked your .pem key on a Mac: SSH refuses a private key that others can read.

And your defaults on Amazon Linux? New files and folders made by ec2-user come out a bit more open for the group:

umask
0002
touch new.txt
mkdir newdir
ls -ld new.txt newdir
-rw-rw-r--. 1 ec2-user ec2-user 0 Jan  5 10:15 new.txt
drwxrwxr-x. 2 ec2-user ec2-user 6 Jan  5 10:15 newdir

1. Files start from 666 and folders from 777.
2. The umask 0002 removes w for others → 664 files and 775 folders.
3. Root's umask 0022 also removes the group's w → 644 and 755.

This is safe on Amazon Linux because each user has a private group of their own.

13. Folder permissions: r, w and x mean something else

Why. A folder is a list of names. Its permissions protect that list, not the contents of the files in it. That's why the same letters mean different things.

What.

1. r on a folder: list the names inside (ls).
2. w on a folder: create, delete and rename entries inside (touch, mkdir, cp into it, mv, rm), and only together with x.
3. x on a folder: enter it (cd) and use paths through it, like cat ravi/a.txt.

Reading or editing a file that already exists is about the file: cat needs the file's r, saving changes needs the file's w, and both need x on the folder to reach it. The folder's w isn't needed.

14. One folder, five modes

How. Make a folder with two files, then change its mode and watch what breaks. All outputs below are from the box:

mkdir ravi
echo hello > ravi/a.txt
touch ravi/aa.txt

Example 1: 700 (rwx------). You can list it, enter it and create in it. Everything works.

Example 2: 600 (rw-------), no x.

chmod 600 ravi
cd ravi
-bash: cd: ravi: Permission denied
ls -l ravi
ls: cannot access 'ravi/a.txt': Permission denied
ls: cannot access 'ravi/aa.txt': Permission denied
total 0
-????????? ? ? ? ?            ? a.txt
-????????? ? ? ? ?            ? aa.txt

r lets ls read the names, but without x it can't look at the files, so you get question marks. cat ravi/a.txt fails too.

Example 3: 700 again.

chmod 700 ravi
cd ravi
pwd
/home/ec2-user/ravi

Example 4: 300 (-wx------), no r.

chmod 300 ravi
cd ravi
ls
ls: cannot open directory '.': Permission denied
touch new.txt
cat a.txt
hello

cd works (x), ls fails (no r), but touch works (w + x) and a name you already know still opens.

Example 5: 200 (-w-------), w without x.

chmod 200 ravi
touch ravi/n2.txt
touch: cannot touch 'ravi/n2.txt': Permission denied
rm ravi/aa.txt
rm: cannot remove 'ravi/aa.txt': Permission denied

w alone does nothing. Creating and deleting need w and x. (With 100, x only, cat ravi/a.txt works but ls ravi and touch fail.)

15. A folder without w: chmod 555

What. 555 (r-x for all) lets you enter and list, but nothing can be added, removed or renamed:

chmod 555 ravi
cd ravi
touch rr.txt
touch: cannot touch 'rr.txt': Permission denied
mkdir tata
mkdir: cannot create directory ‘tata’: Permission denied
rm aa.txt
rm: cannot remove 'aa.txt': Permission denied
cp a.txt b.txt
cp: cannot create regular file 'b.txt': Permission denied
mv a.txt c.txt
mv: cannot move 'a.txt' to 'c.txt': Permission denied

But the files inside can still change. a.txt is rw-rw-r--, so its owner can edit it:

echo more >> a.txt
cat a.txt
hello
more

nano a.txt saves fine too ([ Wrote 2 lines ]). Only a new file fails: nano new.txt shows [ Error writing new.txt: Permission denied ] when you save.

16. The puzzle: can ec2-user delete root's file?

The question. Root makes a file inside /home/ec2-user. The file is root root, rw-r--r--. Can ec2-user delete it without sudo? Most of the class said no.

The answer: yes. Deleting doesn't touch the file's contents. It removes a name from the folder's list, so it's decided by the parent folder, and ec2-user owns its home with rwx.

Proof 1. In your home:

ls -ld /home/ec2-user
drwx------. 3 ec2-user ec2-user 74 Jan  5 10:15 /home/ec2-user
sudo nano rootwala.txt
ls -l rootwala.txt
-rw-r--r--. 1 root root 10 Jan  5 10:15 rootwala.txt

Changing what's inside is refused, because that's the file's w, and only root has it:

echo more >> rootwala.txt
-bash: rootwala.txt: Permission denied

But deleting works. rm asks first, because you can't write the file; answer y:

rm rootwala.txt
rm: remove write-protected regular file 'rootwala.txt'? y
ls rootwala.txt
ls: cannot access 'rootwala.txt': No such file or directory

(For an empty file the question says regular empty file. rm -f skips the question.)

Proof 2. Same thing in a folder you made:

mkdir myfolder
cd myfolder
sudo nano folderwala.txt
rm folderwala.txt
rm: remove write-protected regular file 'folderwala.txt'? y

And a folder made by root? sudo mkdir rootwala makes a root root folder in your home. You can't create anything inside it (touch rootwala/x.txt → Permission denied), but while it's empty you can remove it with rmdir rootwala, because its name lives in your folder. If root has put a file inside, rm -r fails on that file.

17. The exception: the sticky bit on /tmp

Why. /tmp is a folder where every user may create files, so everyone has w and x on it. By the rule above, anyone could delete anyone's files there. The sticky bit stops that.

What. It shows as a t in place of the last x:

ls -ld /tmp
drwxrwxrwt. 25 root root 2220 Jan  5 10:15 /tmp

With the sticky bit, only the file's owner, the folder's owner or root may delete or rename a file, even if the file itself is rw-rw-rw-. Tested on the box with two users:

[ec2-user@ip-172-31-xx-xx ~]$ echo hi > /tmp/ec2.txt
[ec2-user@ip-172-31-xx-xx ~]$ chmod 666 /tmp/ec2.txt

[ravi@ip-172-31-xx-xx ~]$ rm /tmp/ec2.txt
rm: cannot remove '/tmp/ec2.txt': Operation not permitted

In a drwxrwxrwx folder without the t, the same rm by ravi works. You set the sticky bit with chmod +t folder or chmod 1777 folder.

18. "I can use sudo anywhere": only if you're allowed

What. ec2-user can run sudo because Amazon Linux sets it up that way. It's in the wheel group, and cloud-init adds a rule with no password:

sudo cat /etc/sudoers.d/90-cloud-init-users
...
ec2-user ALL=(ALL) NOPASSWD:ALL

A new user gets nothing like that:

sudo -l -U ravi
User ravi is not allowed to run sudo on ip-172-31-xx-xx.

So ravi can't use sudo unless an admin allows it, for example with sudo usermod -aG wheel ravi. The wheel rule (%wheel ALL=(ALL) ALL) also asks for ravi's own password, which a new user doesn't have until someone sets one with sudo passwd ravi.

19. Real-life tip: when EC2 Instance Connect keeps failing

20. Try at home

Recap

Samjla ka? Ghari ek folder banva, tyala 700, 600, 300 ani 555 deun bagha, ani root chi file delete karun bagha.

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. The user, folder and file names (ravi, ramesh, my.txt, a.txt, rootwala.txt and the rest) are examples for learning. Commands and messages were checked on the box with GNU coreutils, bash and nano using an ec2-user test account with umask 0002, and against the settings of an Amazon Linux 2023 server (umask 0002, home folder 700, /tmp drwxrwxrwt, the cloud-init sudoers rule, coreutils 8.32); the hostname in the prompt, the dates and the /tmp size in ls -l are illustrative.