LiveChat 
Support 
How to Change File Permissions in Linux (chmod Explained)
If you have ever seen a “Permission denied” error on a Linux server, you have run into the permission model that controls who can read, write, and execute every file and directory on the system. Knowing how to change file permissions in Linux with the `chmod` command is one of the most fundamental skills for anyone managing a website, application, or server. This guide walks through the model from the ground up, shows both ways to use `chmod`, and explains the permission sets you will actually use in practice.
Key Takeaways
• Linux permissions are split into three actions — read (r), write (w), and execute (x) — applied to three classes: owner, group, and others.
• Use `chmod` to change permissions, either with symbolic notation (`chmod u+x file`) or octal/numeric notation (`chmod 755 file`).
• Common sets: 644 for regular files, 755 for directories and executables, 600 for private files like SSH keys.
• Avoid `chmod 777` — it makes a file world-writable and is a serious security risk; fix ownership with `chown` instead.
• For recursive changes, prefer `find` to apply different permissions to files and directories.
What does the Linux permission model actually mean?
Every file and directory in Linux has permissions for three classes of users:
- Owner (user, `u`) — the account that owns the file.
- Group (`g`) — a set of users who share group membership.
- Others (`o`) — everyone else on the system.
For each class, three permission types can be granted or denied:
- Read (`r`) — view file contents, or list a directory.
- Write (`w`) — modify a file, or add/remove files in a directory.
- Execute (`x`) — run a file as a program, or enter (`cd` into) a directory.
A key detail people miss: on directories, `x` means the ability to *traverse* into the directory, not run it. A directory needs both `r` and `x` to be genuinely usable.
How do I read the output of ls -l?
Run `ls -l` to see permissions in long format:
“`bash ls -l myfile.txt -rwxr-xr-x 1 alice developers 2048 Jun 20 10:30 myfile.txt “`
The permission string `-rwxr-xr-x` breaks down into four parts:
| Segment | Value | Meaning |
|---|---|---|
| Type | `-` | Regular file (`d` = directory, `l` = symlink) |
| Owner | `rwx` | Owner can read, write, execute |
| Group | `r-x` | Group can read and execute, not write |
| Others | `r-x` | Others can read and execute, not write |
A dash (`-`) in any position means that permission is not granted. Here, the owner `alice` has full control, while the `developers` group and everyone else can read and execute but not modify the file.
How do you change permissions with chmod symbolic notation?
Symbolic notation is the most readable way to adjust permissions because you specify exactly what to add, remove, or set. The format is `chmod [class][operator][permission] file`.
The operators are:
- `+` adds a permission.
- `-` removes a permission.
- `=` sets permissions exactly, clearing anything not listed.
The classes are `u` (user/owner), `g` (group), `o` (others), and `a` (all three).
“`bash chmod u+x script.sh # give the owner execute permission chmod g-w report.txt # remove write permission from the group chmod o=r notes.txt # set others to read-only (clears w and x for others) chmod a+r public.html # give everyone read permission chmod u+x,g-w deploy.sh # combine multiple changes with a comma “`
Symbolic notation shines when you want to flip a single bit — for example, making a shell script executable with `chmod u+x` — without touching the rest of the permissions.
How does octal (numeric) chmod notation work?
Octal notation sets all permissions for all three classes at once using a three-digit number. Each digit represents one class — owner, group, others, in that order — and is the sum of the permission values:
- Read (`r`) = 4
- Write (`w`) = 2
- Execute (`x`) = 1
Add the values for each class to get its digit. For example, `rwx` = 4 + 2 + 1 = 7, and `r-x` = 4 + 0 + 1 = 5. So `-rwxr-xr-x` becomes 755.
This table maps the most common octal codes to their symbolic equivalents and typical use:
| Octal | Symbolic | Owner / Group / Others | Common use |
|---|---|---|---|
| 777 | `rwxrwxrwx` | full / full / full | Dangerous — avoid (world-writable) |
| 755 | `rwxr-xr-x` | full / read+exec / read+exec | Directories, executables, scripts |
| 750 | `rwxr-x—` | full / read+exec / none | Private executable, group access only |
| 644 | `rw-r–r–` | read+write / read / read | Regular files (HTML, config, text) |
| 640 | `rw-r—–` | read+write / read / none | Config readable by group only |
| 600 | `rw——-` | read+write / none / none | Private files, SSH keys, secrets |
| 400 | `r——–` | read / none / none | Read-only private file |
“`bash chmod 644 index.html # standard regular file chmod 755 /var/www/app # standard directory or executable chmod 600 ~/.ssh/id_rsa # lock down a private SSH key “`
Which permission sets should I use for what?
A few defaults cover the vast majority of real-world cases:
- 644 for regular files — the owner can edit; everyone else can read. Ideal for web pages, configuration files, and documents.
- 755 for directories and executables — the owner has full control; others can enter directories and run programs. Web roots like `/var/www` typically use this.
- 600 for private files — only the owner can read or write. This is required for SSH private keys; tools like OpenSSH will refuse to use a key that is readable by others.
Why is chmod 777 dangerous?
`chmod 777` grants read, write, and execute to everyone — owner, group, and others. The critical problem is the write bit for “others”: it makes the file world-writable, meaning *any* user or process on the system can modify, replace, or delete it.
This matters because `777` is one of the most common “lazy fixes” on the internet. Someone hits a permission error, searches for a solution, and finds a forum reply saying “just run `chmod 777`.” It makes the error go away — and quietly opens a serious security hole. On a shared server or any internet-facing machine, a world-writable script or upload directory is an open invitation for an attacker to inject malicious code that the server will then execute.
The real fix is almost never to open a file to the whole world. A permission error usually means the file is owned by the wrong user. The correct approach is two steps:
- Set correct ownership with `chown` so the right user or service account owns the file.
- Apply least-privilege permissions — `644` for files, `755` for directories — so each class has only the access it genuinely needs.
If your web server runs as `www-data` and cannot write to an uploads folder, the answer is to make `www-data` own that folder (`chown www-data uploads`), not to let every account on the box write to it.
How do you change ownership with chown?
Permissions decide *what each class can do*; ownership decides *who belongs to each class*. The `chown` command changes the owner and, optionally, the group of a file.
“`bash chown alice file.txt # change owner to alice chown alice:developers file.txt # change owner to alice and group to developers chown :developers file.txt # change only the group chown -R www-data:www-data /var/www/site # recursively for a web root “`
Because ownership and permissions work together, most “permission denied” problems are solved by correcting ownership with `chown` and then applying sensible permissions with `chmod` — not by loosening permissions for everyone.
How do you change permissions recursively the right way?
The `-R` flag applies `chmod` to a directory and everything inside it:
“`bash chmod -R 755 /var/www/site “`
There is a well-known gotcha here. Files and directories need different permissions: directories need the execute (`x`) bit to be traversable, but regular files generally should not be executable. Running `chmod -R 755` makes every file executable too, and `chmod -R 644` strips the `x` bit off directories and breaks access to them.
The correct technique is to use `find` to target files and directories separately:
“`bash
find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \; “`
This applies 755 to directories (`-type d`) and 644 to files (`-type f`) in one pass, which is exactly what a typical web project wants.
What are the special permission bits?
Beyond `rwx`, Linux has three special bits, set with an optional fourth leading octal digit:
- Setuid (`4xxx`) — a program runs with the owner’s privileges rather than the caller’s. Used by trusted system binaries like `passwd`; rarely needed in your own files.
- Setgid (`2xxx`) — on a directory, new files inherit the directory’s group. Useful for shared team folders so everyone keeps consistent group ownership.
- Sticky bit (`1xxx`) — on a shared directory, only a file’s owner can delete or rename it, even if others can write to the directory. This is why `/tmp` (mode `1777`) lets everyone create files but stops users from deleting each other’s.
“`bash chmod 2775 /shared/team # setgid so new files inherit the group chmod 1777 /shared/upload # sticky bit on a shared writable directory “`
Use these sparingly and deliberately — setuid in particular can be a security risk if applied to the wrong binary.
Manage Linux file permissions with DarazHost hosting
Getting permissions and ownership right is far easier when you have the right level of access to your server. With DarazHost VPS and dedicated server plans, you get full root and SSH access, so you can run `chmod`, `chown`, and `find` exactly as shown above to lock down files with least-privilege permissions and correct ownership. That level of control is essential for hardening SSH keys to `600`, setting web roots to `755`/`644`, and avoiding insecure `777` shortcuts.
If you are on shared hosting, DarazHost’s cPanel File Manager lets you adjust permissions through a simple interface — set the numeric value or tick the read/write/execute checkboxes without touching the command line. Every plan runs on secure, well-configured infrastructure, backed by 24/7 support that can help you diagnose a stubborn permission or ownership issue instead of resorting to risky workarounds.
Frequently asked questions
What does chmod 755 mean? `chmod 755` sets a file or directory so the owner has full read, write, and execute access (`7` = 4+2+1), while the group and others have read and execute but not write (`5` = 4+0+1). It is the standard permission for directories and executable scripts.
What is the difference between 644 and 755? 644 (`rw-r–r–`) gives the owner read and write, and everyone else read-only — ideal for regular files. 755 (`rwxr-xr-x`) adds the execute bit for all classes, which is needed for directories (to enter them) and executable programs.
Is chmod 777 ever safe to use? Almost never. 777 makes a file world-writable, meaning any user can modify it — a serious security risk. The proper fix for a permission error is to correct ownership with `chown` and apply least-privilege permissions (`644` for files, `755` for directories), not to open the file to everyone.
How do I make a shell script executable? Run `chmod +x script.sh` (or the more precise `chmod u+x script.sh` to grant execute to the owner only). You can then run it with `./script.sh`.
What is the difference between chmod and chown? `chmod` changes permissions — what reading, writing, and executing each class is allowed to do. `chown` changes ownership — which user and group the file belongs to. They work together: ownership defines the classes, and permissions define what each class can do.
