How to Change File Permissions in Linux: Chmod in Action

One wrong permission change can lock you out of a server, break a deployment, or expose a private config file to every user on the box. If you work in Linux every day, change permissions Linux is not a side topic; it is basic Linux file security and core permission management.

This guide shows how the chmod command works in real situations. You will see the difference between numeric and symbolic modes, how permissions behave on files versus directories, and how to avoid the mistakes that cause the most trouble in production.

We will also cover recursive changes, special permission bits, and practical troubleshooting. If you need to create a user account in Linux, add a user to a group in Linux, or manage a shared project folder, these concepts tie together fast.

Permission mistakes are usually access mistakes, not syntax mistakes. The command may be correct, but the wrong target, wrong directory, or wrong ownership makes the result look broken.

Understanding Linux File Permissions

Linux file permissions are built around three actions: read, write, and execute. Read lets you open a file, write lets you modify it, and execute lets the system treat it as a program or script.

These permissions apply to three categories of users: owner, group, and others. The owner is the account that owns the file, the group is a shared access bucket, and others means everyone else on the system. This is where permission management starts to matter, because the same file can be private, team-shared, or world-readable depending on those bits.

How ls -l displays permissions

Run ls -l and you will see a string like -rw-r--r--. The first character shows the file type, and the next nine characters are the permissions. In this example, the owner can read and write, the group can read, and others can read.

The file type matters because a directory uses the same permission letters, but the meaning changes. For a directory, read means you can list names, write means you can create or delete entries, and execute means you can enter or traverse it. That is why a directory without execute permission can look visible but still be inaccessible.

• – regular file
• d directory
• l symbolic link
• x execute permission, or traverse permission on a directory

Ownership and permissions work together, but they are not the same thing. Changing permissions with chmod does not change ownership. If the wrong user owns the file, you need chown, not the chmod command. That distinction matters in every Linux system admin task.

How chmod Works

chmod changes the permission bits on files and directories. It does not change the owner, it does not change the group by itself, and it does not fix application-level security policies. What it does is control who can read, modify, or execute a file at the filesystem level.

Permission changes take effect immediately for future access checks. If a process already has a file open, the new permissions may not stop that process right away. For example, a running script or service can keep using an open file handle even after permissions are tightened.

Basic syntax and common mistakes

The general syntax is simple: chmod [options] mode file. The mode can be numeric, such as 644, or symbolic, such as u+x. You can apply it to one file, a batch of files, or recursively with -R.

chmod 644 report.txt
chmod u+x script.sh
chmod -R 755 /var/www/html

Two mistakes come up constantly. First, people confuse chmod with chown. Second, they use broad permissions like 777 when they really need ownership, group access, or a smaller mode. Broad access hides the underlying problem and weakens Linux file security.

Using Numeric Mode With chmod

Numeric mode is the fastest way to set a complete permission pattern. It uses three bits for each category: read is 4, write is 2, and execute is 1. Add them together to get the final value for owner, group, or others.

That is why 7 means read, write, and execute; 6 means read and write; 5 means read and execute; and 4 means read only. A full mode like 755 means owner gets 7, group gets 5, and others get 5.

Common numeric permission patterns

644	Owner can read and write; everyone else can read. Common for text files, data files, and configs that should not be executable.
755	Owner can read, write, execute; group and others can read and execute. Common for shell scripts and public directories.
600	Owner can read and write only. Good for private documents and sensitive keys.
700	Owner can read, write, execute only. Good for private scripts or folders.

Use numeric mode when you know the exact end state. It is clearer for standard patterns and faster when you are applying the same permission template repeatedly. A private SSH key, for example, should not be readable by group or others, so chmod 600 id_rsa is a common control.

For executable scripts, chmod 755 deploy.sh makes the file runnable while keeping it readable to others. For a text report, chmod 644 report.txt keeps it editable by the owner without turning it into a program by mistake.

Recursive numeric changes with caution

Recursive mode applies permissions to a directory and everything under it. That is useful for a controlled tree, but dangerous on mixed content. If you run chmod -R 755 across a directory that contains private keys, databases, and scripts, you may create a security problem fast.

chmod -R 755 /srv/project

Use recursion only when the entire tree should share the same rule. For larger sets, find and stat give you more precise permission management. That matters in web roots, application directories, and Linux system admin workflows where file types differ inside one tree.

Using Symbolic Mode With chmod

Symbolic mode is the better choice when you want to adjust permissions incrementally. Instead of replacing the whole mode, you target a class of users: u for owner, g for group, o for others, and a for all.

The operators are straightforward. + adds a permission, – removes one, and = sets the exact permission set for the targeted class. This is why symbolic mode is often safer for ongoing changes: you can add execute permission without disturbing existing read bits.

Practical symbolic examples

chmod u+x script.sh
chmod go-r file.txt
chmod a=rw report.txt

chmod u+x script.sh adds execute permission only for the owner. chmod go-r file.txt removes read access from group and others. chmod a=rw report.txt sets read and write for everyone, although that is rarely a good choice outside of a temporary collaboration folder.

Symbolic mode is especially useful when a file already has a sensible baseline. If a deployment script is already readable, chmod +x adds execution without resetting the rest of the permissions. That makes symbolic mode ideal when you want to avoid accidentally removing unrelated permissions.

It also helps when you are tightening access. Removing world access from a sensitive file can be as simple as chmod o-rwx secrets.txt. That style fits real incident response and routine hardening work.

Changing Permissions on Files

Different file types call for different permissions. A text document usually needs read and write for the owner and read-only for everyone else. A shell script needs execute permission to run. A configuration file usually needs to be readable by the service account and writable only by administrators.

The most common pattern is simple: data files use 644, executable scripts use 755, and private files use 600. That distinction is central to Linux file security because it keeps ordinary content readable while restricting files that should not be edited or executed by everyone.

Examples for scripts and sensitive files

To make a script executable, use:

chmod +x backup.sh

If you want a file protected from accidental edits, remove write access for non-owners or even for the owner if the file should be treated as read-only:

chmod 444 handbook.txt
chmod 600 vault.key

444 makes the file readable by everyone and writable by nobody. That is useful for reference documents or static content, but not for files that need routine updates. 600 is a better fit for secrets, private notes, and credential material.

Use 644 for a report, 755 for a runnable script, and 600 for a private document. That simple split covers a large percentage of day-to-day permission work on Linux servers and desktops, including a desktop environment Linux workstation where users store local configs and scripts.

Changing Permissions on Directories

Directories behave differently from files, and this is where many permission problems start. On a directory, read means you can list file names, write means you can create or remove entries, and execute means you can enter the directory and access items inside it.

If a user can read a directory but not execute it, they may see names but still fail when opening them. If a user can execute but not read, they can traverse the directory if they know the filename, but they cannot list contents. That difference matters in shared folders and web directories.

Common directory settings

• 755 for shared directories that many users need to traverse and read
• 700 for private folders that only one user should access
• 750 for team folders where the group needs access but others do not

For collaboration, directories usually need execute permission for group members, even when files inside are read-only. That is why adding a user to a group in Linux often goes hand in hand with setting directory modes correctly. Ownership and group design solve access more cleanly than reaching for 777.

Overly permissive directories create real risk. A world-writable application folder can let an untrusted user replace scripts, drop malicious files, or interfere with services. This is especially dangerous in any environment that uses Linux ssh command access for remote administration, because one exposed directory can become a foothold.

Recursive Permission Changes

The -R option applies a chmod command to a directory tree recursively. This is useful when you need to normalize permissions for a project checkout, a web root, or a shared application folder. It is also one of the easiest ways to create a mess if you are not careful.

chmod -R u+rwX,g+rX,o-rwx /srv/app

The uppercase X in symbolic mode is useful because it adds execute permission only to directories and already-executable files. That is often safer than forcing every file to become executable, which is a common mistake with chmod -R 755.

When recursion is appropriate

1. Fixing a project directory after copying files from another system
2. Preparing a web root so scripts run and static assets remain readable
3. Resetting a shared folder where files need consistent group access

Always verify recursive changes after you run them. ls -l is fine for a quick check, but stat gives you precise mode data, and find lets you inspect only certain file types. If you need to see the full path permissions one layer at a time, namei -l /path/to/file is one of the best troubleshooting tools available.

In environments where a project tree contains logs, secrets, uploads, and code together, a controlled approach is better than one broad recursive rule. That is the difference between healthy permission management and cleanup work after a mistake.

Special Permission Bits and Advanced Cases

Linux also supports three special permission bits: setuid, setgid, and the sticky bit. These are not everyday settings, but they matter in shared systems, privileged executables, and directories with many users.

setuid lets a program run with the file owner’s privileges. setgid can make a program run with the file group’s privileges, and on directories it can help new files inherit the directory’s group. The sticky bit on a directory prevents users from deleting files they do not own, even if the directory is writable.

Where these bits show up

• s in the execute position can indicate setuid or setgid
• T or t can indicate the sticky bit on a directory
• These appear in ls -l output instead of a normal x

A common example is a shared upload directory where multiple users can write files, but only the file owner can delete them. Another is a controlled administrative executable that needs a specific privilege level. These are advanced cases, and they should be reviewed carefully because they carry security implications.

Common Use Cases and Best Practices

The safest permission pattern is usually the simplest one that still works. For a shell script, use 755 if multiple users need to run it. For a private file, use 600. For a shared team folder, use group ownership and a directory mode like 750 or 770 only when the business case is clear.

Use the principle of least privilege every time you change permissions. Give the minimum access needed to complete the task, and no more. This is especially important when you are working with private keys, config files, deployment scripts, and shared file systems.

Practical rules that hold up well

• Scripts: use 755 if they need to be runnable by others
• Personal files: use 600 or 640 depending on sharing needs
• Shared team folders: use groups first, then align directory permissions
• Public web assets: make content readable, but keep writable access limited
• Temporary collaboration: use broad access only for a short, controlled window

777 is usually a bad idea. It gives everyone read, write, and execute access, which is rarely needed and often dangerous. If something appears to require 777, the real issue is usually ownership, group design, or application configuration.

That is why Linux admins often pair chmod with groups, chown, and carefully planned access. If you are building a team workspace, add a user to a group in Linux instead of making the directory world-writable. That approach scales better and creates cleaner audit trails.

Broad permissions are a workaround, not a design. If you need 777, stop and check ownership, group membership, service user context, and the parent directories first.

If collaboration matters, verify access as another user. A quick switch with su - or a test login can show whether the permissions actually match the intended workflow. That is a better test than assuming the owner’s view reflects everyone else’s access.

Troubleshooting Permission Problems

When you see Permission denied, do not jump straight to chmod. Start with a structured check. First confirm the owner and mode with ls -l. Then verify the full path with namei -l. Next check identity with id, especially if group access is supposed to work.

It also helps to inspect exact metadata with stat. That shows the numeric mode, owner, and group in one place. If the file is supposed to be executable, confirm the x bit is actually present and that the script has a valid shebang line such as #!/bin/bash.

Permission troubleshooting checklist

1. Run ls -l on the file and parent directory
2. Run namei -l /full/path/to/file to check traversal permissions
3. Run id to confirm group membership
4. Run stat file to inspect exact mode and ownership
5. Check SELinux, AppArmor, and mount options such as noexec

Sometimes the issue is not permissions at all. SELinux can block access even when the mode looks correct. AppArmor can do the same. A filesystem mounted with noexec will prevent execution no matter what chmod +x says. That is why Linux file security includes both file permissions and system policy layers.

If you work with web assets or mounted shares, also inspect the mount options and the application user. A file owned by root with correct permissions may still fail if the service runs as another account. In those cases, ownership and group membership matter as much as the chmod command itself.

Conclusion

Changing permissions in Linux comes down to two models: numeric and symbolic. Numeric mode is best when you want a clean final state like 644, 755, or 600. Symbolic mode is better when you want to add or remove one permission without disturbing the rest.

Remember the big rule: file permissions and directory permissions behave differently. A directory’s execute bit controls traversal, and that detail explains a lot of “permission denied” errors. If you understand that distinction, you will troubleshoot faster and make fewer risky changes.

Use chmod intentionally. Check ownership first, use groups where they make sense, avoid 777, and verify recursive changes before moving on. That is how you keep permission management clean, predictable, and secure.

For more Linux admin fundamentals, training paths, and practical command-line skills, ITU Online IT Training covers the concepts that help you work faster without breaking access controls.

CompTIA®, Security+™, Cisco®, Microsoft®, AWS®, EC-Council®, ISC2®, ISACA®, and PMI® are trademarks of their respective owners.

Authoritative references used for this guide include GNU Coreutils chmod documentation, man7 chmod manual, Red Hat Enterprise Linux documentation and admin guidance, CIS Benchmarks, and NIST SP 800-53 for access control context.