Linux File Permissions Explained for Self-Hosting

If you have spent any time self-hosting, you have seen this error: Permission denied. It happens when a Docker container cannot write to a volume, when a script refuses to run, or when an application cannot read its own configuration file. Understanding Linux file permissions fixes these problems in seconds instead of hours. Here is how they work, referenced from GNU coreutils 9.11 documentation.

The Three Permission Types

Every file and directory has three permission types:

Numbers add together: 7 (4+2+1) means full read, write, and execute. 5 (4+1) means read and execute. 6 (4+2) means read and write but not execute.

The Three Permission Levels

Permissions apply at three levels, shown in the output of ls -l:

-rwxr-x---  1 user  group  4096 Aug 10 14:30 script.sh
 ─┬─ ─┬─ ─┬─
  │   │   └── Others (everyone else): --- (no permissions)
  │   └────── Group members: r-x (read and execute, no write)
  └────────── Owner: rwx (read, write, execute)

The first character indicates the file type: - for a regular file, d for a directory, l for a symbolic link. The next nine characters are three groups of three: owner permissions, group permissions, and others permissions.

Common Permission Patterns for Self-Hosting

Docker Volumes: 755 for directories, 644 for files

# Fix a Docker volume with wrong permissions
chmod -R 755 /opt/stacks/nextcloud/
chmod -R 644 /opt/stacks/nextcloud/config/*.php

Docker containers often run as a specific user ID (UID). When the container cannot write to a mounted volume, check the UID:

# Find what UID the container runs as
docker exec nextcloud id
# Output: uid=33(www-data) gid=33(www-data)

# Fix ownership to match
chown -R 33:33 /opt/stacks/nextcloud/

SSH Private Keys: 600

chmod 600 ~/.ssh/id_rsa

SSH refuses to use keys that are readable by anyone other than the owner. If you copy SSH keys and they stop working, the permissions are almost certainly wrong.

Scripts: 755

chmod 755 deploy.sh
./deploy.sh    # now you can run it

A script needs execute permission to run. New files default to 644 (no execute). Add execute with chmod +x.

Configuration Files with Secrets: 600

chmod 600 .env

.env files contain database passwords and API keys. They should be readable only by the owner. Anyone else on the system should not be able to read them.

Symbolic vs. Numeric Mode

chmod supports both symbolic and numeric notation. Numeric is common in tutorials because it is unambiguous:

chmod 755 file    # numeric: sets exact permissions
chmod +x file     # symbolic: adds execute permission, keeps everything else
chmod g+w file    # symbolic: adds write permission for the group
chmod o-rwx file  # symbolic: removes all permissions for others

Use numeric when you know exactly what you want. Use symbolic when you want to modify existing permissions without touching the rest.

The Sticky Bit and Docker Socket

The Docker socket at /var/run/docker.sock is how Docker commands communicate with the Docker daemon. Its permissions control who can manage containers:

ls -l /var/run/docker.sock
# Output: srw-rw---- 1 root docker 0 Aug 10 14:30 /var/run/docker.sock

Only root and members of the docker group can use it. Adding your user to the docker group gives you Docker access without sudo:

sudo usermod -aG docker $USER
# Log out and back in for this to take effect

The docker group has root-equivalent access on the system. Only add trusted users to it.

If permissions and ownership errors are eating into your productive hours, VPS1 manages your server. We configure the correct permissions from day one. No chmod guessing. No permission denied.