DevOps Engineer

chmod for DevOps engineers: 755, 644, 600, and the permissions that matter

Last updated 2026-06-24

Use 755 for scripts and directories, 644 for configs and static files, 600 for SSH keys and secrets. Never use 777 in production. These three values cover most everyday permission decisions.

Octal Notation

755

Symbolic Notation

-rwxr-xr-x

Command Line Example

chmod 755 filename

Or apply recursively to all files and directories inside a folder:

chmod -R 755 foldername/

chmod 755 pre-set on the configurator. Toggle individual read/write/execute bits or compare 644 and 600.

Edit in the full tool

DevOps engineers reach for chmod daily in Dockerfiles, CI/CD pipelines, and server provisioning scripts. The three permissions that cover most cases: 755 for executable scripts and directories, 644 for config files and static assets, and 600 for SSH private keys and secrets.

Why this matters for you

In a Dockerfile, RUN chmod 755 /entrypoint.sh is the usual way to make an entrypoint executable. Config files mounted into containers should be 644 so the app can read them but not accidentally overwrite them. SSH refuses to use a private key that others can access and throws a 'permissions too open' error, so set keys to 600 or stricter. Avoid 777 in production. It lets any user change the file, and audits flag it.

Reading the three digits

Each digit adds up read (4), write (2) and execute (1). The first digit is the owner, the second is the group, and the third is everyone else. So 755 gives the owner 7 (4 + 2 + 1, all three) and everyone else 5 (4 + 1, read and execute). 644 gives the owner read and write and everyone else read only. 600 locks the file to its owner.

Execute means something else on a directory. It lets a user enter the directory and reach the files inside. A directory set to 644 shows its file names to others but won't let them open anything, which is why web roots and app folders use 755.

Defaults, containers and Git

New files get their mode from your umask. The common default of 022 removes write access for group and others, so new files start at 644 and new directories at 755. With BuildKit, COPY --chmod=755 in a Dockerfile sets the mode while copying, which saves a separate RUN chmod layer.

Check who owns the file, too. A 600 key owned by root can't be read by an app that runs as a non-root user. Git only stores the execute bit, so a script committed as 100755 checks out executable and other mode changes are ignored. If a script loses its execute bit in CI, run git update-index --chmod=+x on it and commit.

Verdict

Start with 755, 644 or 600 depending on whether the file runs, gets read, or holds a secret. Use 777 only as a last resort, since it lets any user change the file.

Open the CHMOD Configurator

Frequently asked questions

Why does SSH say my private key permissions are too open?

OpenSSH refuses a private key that the group or other users can access. Run chmod 600 on the key (400 also works) and make sure your user owns it. Keep the .ssh directory itself at 700.

What's the difference between chmod 644 and 664?

664 also lets the file's group write to it. That helps in a shared folder where a team edits the same files, but 644 is the safer default when only the owner should change the file.

Is chmod 777 ever OK?

Rarely. It lets any user on the system change or replace the file, which is why audits flag it. If a process can't write somewhere, fix the owner or group with chown, or grant group write, instead of opening it to everyone.