Chmod for Files vs Directories: How Bits Differ

Read, write, and execute are interpreted by object type

A mode such as 755 is not inherently “a website permission.” It grants a set of capabilities to the owner, group, and everyone else, and those capabilities mean different things for files and directories. Use the chmod calculator to decode the bits, then evaluate the path and the user that needs access.

Why a readable directory may still be unusable

Read permission on a directory can reveal its entry names, but without execute/search permission a process normally cannot traverse to those entries or inspect their metadata. Conversely, execute without read can allow access to a known filename without allowing a full directory listing. Every parent directory in a path also needs search permission for the accessing user.

namei -l /srv/example/public/index.html
stat -c '%A %a %U:%G %n' /srv/example/public/index.html

These checks are more informative than repeatedly changing the final file. A perfectly readable index.html remains unreachable if the web-server user cannot traverse/srv/example.

Common modes are starting points, not universal answers

Avoid 777 as a debugging reflex. It gives every local user write permission and can hide the real problem: wrong ownership, wrong group membership, missing parent traversal, a read-only mount, an access-control list, or a mandatory security policy.

Recursive chmod needs separate rules for files and directories

Running chmod -R 755 tree makes every regular file executable. Runningchmod -R 644 tree removes search permission from directories and can make the tree impossible to traverse. GNU chmod provides capital X, which adds execute only to directories and to files that already have an execute bit.

# Owner can edit; everyone can read files and traverse directories
chmod -R u=rwX,go=rX /srv/example/public

# Equivalent explicit split when you want to inspect each class
find /srv/example/public -type d -exec chmod 755 {} +
find /srv/example/public -type f -exec chmod 644 {} +

Preview the target with find before adding -exec. Confirm mount points and symbolic links, and keep a record of original permissions for a large tree.

Permissions, ownership, ACLs, and service policy are separate layers

Mode bits answer only part of an access question. Check owner and group withstat, supplemental groups with id, and access-control lists withgetfacl where available. SELinux, AppArmor, container mounts, and read-only filesystems can deny an action even when the numeric mode appears permissive.

Test as the real service account, not merely as an administrator. For example,sudo -u www-data test -r path checks whether that account can read a path, while test -x directory checks traversal. Do not solve a service identity problem by granting access to everyone.

A safe change sequence

1. Identify the process user and the exact operation it needs: read, edit, create, delete, traverse, or execute.
2. Inspect every parent directory, then the target owner, group, mode, and ACL.
3. Choose the narrowest owner or group grant that satisfies the operation.
4. Apply the change to one explicit path; avoid recursive changes until the file classes are understood.
5. Test as the real account and verify that an unrelated account did not gain access.

Sources

• GNU Coreutils: Setting permissions — symbolic and numeric permission semantics.
• GNU Coreutils: chmod invocation — recursive operation, symbolic links, and command behavior.