Linux command: chmod

Sooner or later, every Linux user meets a wall of letters like -rwxr-xr-x and a piece of advice that sounds like a magic spell: "just run chmod 755 on it". The command chmod is how you change who is allowed to read, write, and run a file. Once you understand it, that wall of letters turns into a simple, readable sentence.

2. Where the Name Comes From

The name chmod is short for change mode.

chmod  =  CHange MODe

The word "mode" is the old Unix term for a file's permission bits. You will meet the same word in related places: the st_mode field in the stat system call holds exactly these bits, and the C library function that chmod calls is also named chmod(). The command is a thin wrapper around that one system call.

Like its neighbours cp (copy), mv (move), and rm (remove), the name was kept short because early Unix was typed on slow teletype terminals where every character was printed onto paper. The habit stuck, and fifty years later chmod is still chmod.

4. Simple Use Cases

4.1 Making a Script Executable

This is the single most common reason people reach for chmod. You wrote a shell script, but the system refuses to run it:

$ ./backup.sh
bash: ./backup.sh: Permission denied

The file has no execute permission yet. Add it with the +x form (short for "add execute"):

$ chmod +x backup.sh
$ ./backup.sh
Backup finished.

That is the whole fix. chmod +x turns a plain text file into a runnable command.

4.2 The Symbolic Form: Who, Operator, What

The letters you just used are part of a small, readable language. A symbolic mode has three parts:

chmod  u+x  file
       |||
       ||`--- what:     r (read), w (write), x (execute)
       |`---- operator: + add, - remove, = set exactly
       `----- who:      u (user), g (group), o (others), a (all)

You read u+x as "for the user, add execute". A few everyday examples:

$ chmod u+x  file      # let the owner run it
$ chmod g-w  file      # take write away from the group
$ chmod o-r  secret    # hide it from everybody else
$ chmod a+r  page.html # everyone may read it (a = all)

When you leave out the "who", as in the bare chmod +x from the previous example, it means "all", but limited by your umask (the default-permission mask of your shell). To avoid surprises, spell out the class you mean: chmod a+x is always unambiguous.

4.3 Changing Several Classes at Once

You can list several changes, separated by commas, in one command:

$ chmod u+rwx,go-w notes.txt   # owner gets all; group and others lose write
$ ls -l notes.txt
-rwxr--r--  1 peter staff  1234 May 28 17:02 notes.txt

The = operator is stricter than + and -: it sets a class to exactly what you name and clears the rest for that class. So chmod g=r file makes the group's permission read-only, no matter what it was before, and leaves the owner and others untouched.

6. Advanced Use Cases

6.1 Changing a Whole Tree: -R

The -R flag (short for recursive) applies the mode to a directory and everything inside it:

$ chmod -R 755 /var/www/site

This is powerful and, used carelessly, harmful. The trap is that files and directories need different permissions. A directory needs execute (x) so you can enter it, but a plain data file usually should not be executable. Running chmod -R 755 makes every file executable, and chmod -R 644 strips the execute bit off every directory, which then locks you out of them.

6.2 The Capital X: Execute Only Where It Makes Sense

GNU chmod solves that trap with a special permission letter, capital X. It adds execute only to directories and to files that already have at least one execute bit. Plain data files are left alone.

$ chmod -R u=rwX,go=rX /var/www/site

Read that as: give the owner read and write everywhere, plus execute only where it belongs; give the group and others read, plus execute only where it belongs. This one command sets a sane, safe permission scheme across an entire website in a single pass. A quick demonstration of the difference:

$ ls -l
-rw-rw-r--  1 peter staff    0 ... plain.txt   # a data file, no execute
drwx------  2 peter staff 4096 ... sub         # a directory

$ chmod a+X plain.txt sub
$ ls -l
-rw-rw-r--  1 peter staff    0 ... plain.txt   # unchanged: still not executable
drwx--x--x  2 peter staff 4096 ... sub         # changed: directory now enterable

6.3 Copying Permissions: --reference

Instead of naming a mode, you can tell chmod to copy the mode of another file with --reference:

$ chmod --reference=working.conf broken.conf

Now broken.conf has exactly the same permissions as working.conf. This is handy when one file in a directory behaves and another does not, and you want them to match without reading the numbers by hand.

6.4 The Special Bits: setuid, setgid, and Sticky

Beyond the nine ordinary bits there are three special bits, written as a fourth octal digit in front of the mode. They are what make parts of Linux work.

The classic setuid example is passwd. An ordinary user must update the system password file, which only root may write. Setuid lets the program run as its owner, root, just for that job:

$ ls -l /usr/bin/passwd
-rwsr-xr-x  1 root root 59976 ... /usr/bin/passwd

Notice the s where the owner's x would be. That s is the setuid bit sitting on top of the execute bit. You set it by putting a 4 in front of the mode:

$ chmod 4755 myprog       # rwsr-xr-x  (setuid)
$ chmod 2775 shared/      # rwxrwsr-x  (setgid directory)
$ chmod 1777 /tmp         # rwxrwxrwt  (sticky, world-writable)

The sticky bit is why /tmp works. Everyone may write there, but the trailing t means you can only delete your own files, not other people's. Without it, any user could wipe another user's temporary files.

The special bits are the quiet machinery of a multi-user system: setuid lets you change your own password, setgid keeps a shared project's files in one group, and the sticky bit stops /tmp from turning into a demolition site.

One reading detail: if the execute bit underneath is missing, the letter shows as a capital S or T instead of lower case. So rwSr--r-- means setuid is set but the file is not actually executable, usually a mistake worth a second look.

8. Best Practices

• Prefer the least permission that works. Start restrictive. 600 for private files and 700 for private directories are safer defaults than opening things up "just in case".
• Never chmod 777 to fix a problem. It almost never is the real fix, and it lets every user on the machine change your file. If something cannot be read, the issue is usually ownership (chown) or a missing directory x bit, not a lack of world access.
• Use capital X for recursive changes. chmod -R u=rwX,go=rX dir gives directories their execute bit and leaves data files non-executable, avoiding the -R trap.
• Reach for symbolic modes to nudge, octal to set. +x and g-w change one thing; 644 and 755 declare the whole mode.
• Remember SSH is strict. OpenSSH refuses to use a private key or ~/.ssh directory that others can read. chmod 600 ~/.ssh/id_ed25519 and chmod 700 ~/.ssh are the standard fixes.
• Read the manual when unsure. The habit that marks a professional is not memorising every bit; it is typing man chmod the moment a question comes up.

$ man chmod                              # the full manual page
$ chmod --help                           # a quick summary (GNU)
$ info coreutils 'chmod invocation'      # the verbose GNU manual

10. Summary

The chmod command is small, but it controls the entire question of "who is allowed to do what" on a Linux system.

• chmod means "change mode". It edits the permission bits that ls -l shows, and it has been part of Unix since 1971.
• Every file carries read, write, and execute permissions for three classes: owner, group, and others.
• Symbolic modes adjust one thing at a time: u+x, g-w, a+r, and = to set exactly.
• Octal modes set everything at once. Read is 4, write is 2, execute is 1; add them per class. 644, 755, and 600 cover most daily needs.
• Use -R to change a tree, but pair it with capital X so data files do not all become executable.
• The special bits setuid, setgid, and sticky (a fourth digit: 4, 2, 1) power tools like passwd and the shared /tmp directory.
• On directories, a numeric chmod will not clear the setgid bit; use chmod g-s for that.
• Your umask sets the permissions of files you have not created yet; it turns bits off, so think masking, not subtraction.
• When the mode bits are not enough, ACLs (setfacl / getfacl, shown by a + in ls -l) and capabilities (getcap / setcap) take over.
• chmod only writes the bits. The kernel enforces them on every access, and root ignores them.
• When in doubt, type man chmod.

This is the quick reference worth keeping:

chmod +x file            make a file executable
chmod u+x file           add execute for the owner only
chmod g-w file           remove write from the group
chmod 644 file           rw-r--r--  a normal readable file
chmod 755 file           rwxr-xr-x  a script or directory
chmod 600 file           rw-------  a private file (SSH keys)
chmod 700 dir            rwx------  a private directory
chmod -R u=rwX,go=rX dir safe recursive: execute only on dirs
chmod g-s dir            remove the setgid bit from a directory
chmod 1777 dir           rwxrwxrwt  world-writable, sticky (like /tmp)
chmod --reference=A B    give B the same mode as A

Permissions are one of those topics that look intimidating until the pattern clicks, and then they feel obvious. If a server of yours keeps handing out "Permission denied" or "403 Forbidden" errors, or you are not sure a setuid program should really be there, it often pays to have someone check the whole permission and ownership picture properly, before a quick chmod 777 turns a small problem into a security one.