Linux File Permissions: Use chmod Without Breaking Access

A permission error on Linux can be tempting to “fix” with chmod 777. That usually grants far more access than needed—and can leave files writable or executable by every local user.

A safer approach is to check the current permissions, identify who needs access, and change only the relevant bits.

Read the permission string first

Use ls -l to inspect a file:

ls -l deploy.sh

A result might look like this:

-rw-r--r-- 1 alice staff 220 Sep 7 09:14 deploy.sh

The first character indicates the file type (- for a regular file, d for a directory). The next nine characters are permissions in three groups: owner, group, and others. In this example, the owner can read and write; the group and others can read.

For a directory, use -d to inspect the directory itself rather than its contents:

ls -ld project

Choose between numeric and symbolic modes

With numeric mode, each permission has a value:

• Read (r) = 4
• Write (w) = 2
• Execute (x) = 1

Add the values for each class—owner, group, others—to make a three-digit mode. For example, 6 means read and write (4 + 2), while 5 means read and execute (4 + 1).

chmod 644 notes.txt
chmod 600 secrets.env
chmod 755 deploy.sh

644 gives the owner read/write access and everyone else read access. 600 restricts reading and writing to the owner. 755 gives the owner full access and lets the group and others read and execute.

Those are common patterns, not universal defaults. Choose a mode based on what the file is and who needs to use it.

Symbolic mode is handy when you want to adjust one permission without replacing the rest:

chmod u+x deploy.sh   # add execute for the owner
chmod go-w notes.txt  # remove write from group and others
chmod a+r report.txt  # add read for everyone

Here, u, g, and o refer to the owner, group, and others; a means all three. + adds a permission, - removes it, and = sets permissions for the selected class.

Directories work differently from files

Running chmod 755 project changes permissions on project itself. It does not change the files inside it. On a directory:

• Read lets you list entry names.
• Write lets you add, remove, or rename entries.
• Execute lets you traverse the directory and reach entries by name.

That execute bit is easy to overlook: without it, a user may be unable to access files inside the directory, even if those files themselves allow reading.

A directory can also be writable in ways that surprise people. If a user has write access to a directory, they may be able to remove or rename entries inside it regardless of who owns those files. The sticky bit, used on directories such as /tmp, is an important exception to that behavior.

Be cautious with recursive changes

chmod -R applies one mode throughout a directory tree. That can cause trouble if you use a directory mode on every file or a file mode on every directory. For example, recursively setting everything to 755 makes ordinary files executable; setting everything to 644 removes directories’ execute permission.

If you need separate modes for files and directories, target them separately with find:

find ./project -type d -exec chmod 755 {} \;
find ./project -type f -exec chmod 644 {} \;

These examples give directories 755 and regular files 644; choose values that fit your access requirements. For more on the risks and safer patterns, see this guide to recursive chmod changes.

Before running a recursive command, check the path carefully. A mistaken target can affect far more than intended. GNU chmod also supports --preserve-root as a guard against recursively targeting /:

chmod -R --preserve-root 755 "$TARGET_DIR"

That guard does not make a blanket mode appropriate for a mixed tree. Separating files from directories is still important.

Verify the result—and check ownership

After changing a file, inspect it again:

ls -l notes.txt

For a directory’s own permissions:

ls -ld project

If the mode looks right but access still fails, check ownership too. chmod changes what the owner, group, and others are allowed to do; chown changes which user and group those labels refer to. They solve different problems.

Avoid using chmod 777 as a general troubleshooting step. It grants read, write, and execute access to everyone, which may let another local user or process modify or replace the file. If you're diagnosing access to SSH-managed files, compare the settings with this guide to SSH key permissions.

The useful habit is simple: inspect first, make the narrowest change that solves the access problem, and verify the exact path afterward.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.