Skip to content
Webmaster Tools
Dev utilitiesChmod Calculator640 (rw-r-----)

chmod 640 (rw-r-----)

chmod 640 lets the owner read and write, the group read, and nobody else anything. What rw-r----- means and how to use it to share secrets with one service.

Command
chmod 640 file
Open in the chmod calculator

What it means

chmod 640 gives the owner read and write access, gives the file's group read-only access, and shuts everyone else out. In ls -l it shows as -rw-r-----.

Who Digit Read Write Execute Symbolic
Owner (u) 6 yes yes no rw-
Group (g) 4 yes no no r--
Others (o) 0 no no no ---

The symbolic equivalent:

chmod u=rw,g=r,o= app.conf

Why it's useful

640 is the answer to a common problem: a file holds secrets, you (or root) manage it, and one service needs to read it. With chmod 600 only the owner can read it, so the service fails. With chmod 644 every user on the machine can read it. 640 sits in between: put the service's user in the file's group, and only that group gets read access.

sudo chown root:www-data /etc/myapp/secrets.env
sudo chmod 640 /etc/myapp/secrets.env
ls -l /etc/myapp/secrets.env
# -rw-r----- 1 root www-data 512 Oct  5 10:00 /etc/myapp/secrets.env

Now the web server (running as www-data) can read the file, can't change it, and other users can't see it.

On a file vs a directory

On a file, 640 works as described. On a directory, it's not useful: without execute (x) nobody can enter it or open what's inside, not even the owner. The directory version of this idea is chmod 750, which lets the group enter and list the directory but keeps others out.

Typical uses

  • App config with passwords read by a service account: database credentials, .env files, API tokens.
  • TLS private keys shared with a service group. Debian and Ubuntu, for example, ship an ssl-cert group for services that need to read keys in /etc/ssl/private.
  • System files read by a privileged group. On Debian and Ubuntu, /etc/shadow is 640 root:shadow, so tools in the shadow group can check passwords without being root. Other distributions use different modes for it.
  • Log files that an admin group should read but not the whole system.

The group has to be right

640 only does what you want if the file's group is the right one, and the service's user is actually a member of it.

id www-data                       # which groups does the service user have?
sudo usermod -aG ssl-cert postgres  # add a user to a group

Group changes only apply to new processes, so restart the service after adding its user to a group. Also make sure every directory on the path lets the group through (at least x), or the service can't reach the file at all.

Recursive pitfalls

Don't run chmod -R 640 on a config directory. It removes execute from the directories and locks the service out. Set files and directories separately:

sudo find /etc/myapp -type d -exec chmod 750 {} +
sudo find /etc/myapp -type f -exec chmod 640 {} +

Editors and deploy tools

Some tools write a new file and rename it over the old one, and the new file gets the default mode (often 644) and your user's group. After an edit or deploy, check with ls -l that the file is still 640 and still in the right group. Config management tools (Ansible's mode: "0640", for example) let you pin both.

  • chmod 600: owner only, for secrets nobody else needs.
  • chmod 644: readable by everyone, for non-secret files.
  • chmod 660: the group can also write.
  • chmod 750: the matching directory mode.

Try changing a bit in the chmod calculator to see the octal and symbolic forms update together.