chmod Calculator – Unix File Permission Calculator

What are Linux File Permissions?

Every file and directory on a Linux system has three sets of permissions attached to it. The first applies to the owner, the second to a group, and the third to everyone else on the system. Within each set there are three permission types: read lets the contents be viewed, write lets changes be made, and execute lets the file be run as a program. Getting permissions right is a basic requirement for securing any Linux server. An incorrectly permissioned file can expose configuration data, allow unauthorized writes, or let untrusted code run. You can view the current permissions on any file by running ls -la in your terminal.

How to Use chmod

The basic syntax is chmod followed by the permission value and then the filename. You can express permissions as a three digit octal number like 755 or using symbolic notation like u+x to add execute permission for the owner only. To apply the same permissions to every file inside a directory recursively, add the -R flag. On a web server you would typically run chmod 644 on all HTML and config files and chmod 755 on all directories so the web server process can read files and navigate directories without being able to write to them.

Understanding Octal Permission Notation

Each octal digit maps directly to a group of three permissions. Read is worth 4, write is worth 2, and execute is worth 1. You add those values for whichever permissions you want. Full permissions is 4 plus 2 plus 1 which equals 7. Read and write with no execute is 4 plus 2 which equals 6. Read only is just 4. No permissions is 0. So 755 means the owner has 7 for full access, and both group and others have 5 for read plus execute. Using a chmod calculator removes the mental arithmetic entirely and shows you the symbolic notation and the ready-to-run command at the same time.

Common chmod Examples for Web Servers

Web servers like nginx and Apache need to read your files but should never write to them during normal operation. The standard setup is 644 on all files and 755 on all directories. Files with 644 let the server process read them while blocking writes. Directories with 755 let the server navigate into them. Setting files to 777 gives the server process write access, which is a serious security exposure because a compromised script or malicious upload could overwrite any reachable file. Setting up a new server? Use our gitignore generator to create a gitignore file for your project, and check out our Docker run to Compose converter if you are containerising that server.

Why chmod 777 Shows Up in Dockerfiles (and the UID Fix)

chmod 777 in a Dockerfile almost always traces back to one specific cause: a UID mismatch, not a genuine need for world-writable files. Linux doesn't check usernames, it checks numeric user and group IDs. Bind mount a host directory into a container with something like -v ./data:/app/data and the files keep their host ownership. If your host user is UID 1000 but the process inside the container runs as UID 999, or as a different UID entirely, the container has no write access to those files from its own perspective. chmod 777 makes the permission denied error disappear by removing ownership checks from the directory entirely, not by fixing the mismatch that caused it.

The real fix is matching the UIDs instead of disabling permissions. Build the image with a UID and GID that match the host user, passed in at build time with an ARG and --build-arg UID=$(id -u) --build-arg GID=$(id -g), and files created by the container end up owned by you on the host with no chmod needed. When you don't need host-side access to the files at all, because they're application state or a database's data directory, use a named Docker volume instead of a bind mount. Named volumes are managed entirely by Docker and sidestep the UID problem since there's no host ownership to conflict with. If you don't control the image, changing the host directory's ownership to match the container's expected UID with a one-line chown works too.

Any of these three is a meaningfully smaller blast radius than 777, which opens the directory to every user, process, and container sharing that filesystem, not just the one that needed access. It's the kind of fix that costs nothing extra to type up front and is genuinely cheaper than the alternative: a security review eighteen months later asking why /app is world writable in production. Once the UIDs are matched, or you've decided the directory genuinely needs a shared permission, the calculator above gives you the exact octal or symbolic value for that specific case instead of reaching for 777 because it was the first thing that worked.