CHMOD 755 vs 644 vs 600: Permissions Explained with Examples

Reviewed September 3, 2026 · Maintained by William

Unix permission numbers are three groups of bits: owner, group and others. Read permission contributes 4, write contributes 2 and execute contributes 1.

755

7 = rwx
5 = r-x
5 = r-x
=> rwxr-xr-x

This is common for directories and executable scripts that should be writable only by the owner but traversable/readable by others.

644

6 = rw-
4 = r--
4 = r--
=> rw-r--r--

This is a common mode for ordinary public web files: owner can modify; group/others can read; nobody gets an execute bit.

600

6 = rw-
0 = ---
0 = ---
=> rw-------

This is appropriate for many private files that only the owner should read/write, assuming ownership is correct.

Why directories need execute permission

On a directory, execute means traversal/search. A directory with read but no execute permission can produce surprising results: names may be listed, but entries cannot be accessed normally.

Do not “fix” everything with chmod -R 777

World-writable permissions are rarely the right answer to an ownership or service-user problem. Recursive changes also treat files and directories the same, even though they often need different execute bits.

Ownership and ACLs still matter

Mode 644 does not tell you who the owner is. Access Control Lists can also add permissions not visible in the simple mode. Permission calculators explain the bit pattern; they cannot infer your server’s correct ownership model.

Use the CHMOD Calculator or Unix Permission Converter to inspect modes, then confirm the intended owner/group before applying changes.

References

Read each digit as three permission bits

Traditional Unix mode digits represent read (4), write (2) and execute (1) for owner, group and others. Add the values for each class. For example, 7=4+2+1 means read/write/execute and 5=4+1 means read/execute.

755 = rwxr-xr-x
644 = rw-r--r--
600 = rw-------

Why 755 is common for directories and executables

On a directory, execute means “traverse/search” rather than “run this directory.” A web root directory often needs traversal for the web-server process, while write access should remain limited. On a script or binary, execute has its familiar meaning. This is why copying file-mode advice to directories without understanding the execute bit creates confusing access failures.

Why 644 is common for ordinary public files

With 644, the owner can edit the file while group and others can read it. That can be appropriate for public static assets or source files when directory ownership and web-server configuration are correct. It is not a universal hosting rule: shared hosting, deployment users, containers and ACLs can change the right ownership/mode combination.

Why 600 is appropriate for many secret files

600 allows only the owner to read/write the file. It can be suitable for private keys or local credential files when the process that needs the file runs as that owner. If a service runs under a different account, blindly changing to 600 can break the service. Fix ownership and service design rather than making a secret world-readable.

Do not use chmod as the only access model

Effective access also depends on file ownership, group membership, parent-directory permissions, ACLs, mount options, containers and mandatory access-control systems such as SELinux/AppArmor. A calculator can translate mode bits but cannot see those environmental controls.

Safer troubleshooting

  • Use ls -l or stat to inspect current mode and owner before changing anything.
  • Identify the user/group under which the application actually runs.
  • Change the narrowest permission needed rather than jumping to 777.
  • Test the affected request/job immediately after the change.
  • Record intentional exceptions in deployment documentation.

The CHMOD Calculator can translate symbolic and octal values, while the Unix Permission Converter helps read existing modes. They cannot determine whether a specific production service should receive that access.

About the review

This guide is maintained by William. Technical claims are checked against primary or authoritative references where applicable. See How We Test CodeNimbleTools for the site-wide review and correction process.