Calculate octal, symbolic, and text representation parameters for Linux chmod file permissions.
Unix file permissions control read, write, and execute access to files and directories for three principal categories: the file owner (user), the owning group, and all others. The chmod command (change mode) sets these permissions using either symbolic notation (r, w, x letters) or octal numeric notation. Understanding chmod is essential for any Linux/Unix system administrator, developer, or DevOps engineer working with file security configurations.
This calculator converts bidirectionally between octal notation (755, 644, 777) and symbolic notation (rwxr-xr-x) while explaining what each permission combination means and identifying common security implications. It handles all standard permission bits plus the special bits: setuid (4000), setgid (2000), and sticky bit (1000).
Each file or directory has three sets of permission bits, each containing three flags: read (r=4), write (w=2), execute (x=1). The three sets apply to: the file's owner user (u), the file's assigned group (g), and all other users (o). The nine permission bits are displayed in ls -l output as a 9-character string like rwxr-xr-- and converted to octal by treating each 3-bit group independently.
Octal 755 decodes as: 7=rwx (owner can read/write/execute), 5=r-x (group can read and execute, not write), 5=r-x (others can read and execute). This is typical for executable programs and shared scripts. Octal 644 = rw-r--r-- is standard for text files: owner can read and write, everyone else can only read. Octal 600 = rw------- restricts access to the owner only — appropriate for private key files and sensitive configuration.
Beyond the 9 standard bits, three special permission bits provide elevated capabilities. SUID (setuid, 4000): when set on an executable, the process runs with the file owner's privileges rather than the calling user's — used by commands like passwd and sudo that need root access for specific operations. A SUID binary owned by root has permissions 4755.
SGID (setgid, 2000) on an executable runs with the owning group's privileges. On a directory, newly created files inherit the directory's group rather than the creator's primary group — essential for shared project directories where all team members must own files as the project group. Sticky bit (1000) on directories prevents users from deleting files they don't own — critical for /tmp and shared directories where anyone can write but only owners should delete.
755 means: 7 (rwx) = owner can read, write, execute. 5 (r-x) = group can read and execute, not write. 5 (r-x) = others can read and execute, not write. This is the standard permission for executable programs, web server directories, and shared scripts — anyone can run it but only the owner can modify it.
chmod 644 (rw-r--r--): owner can read and write; group and others can only read. Appropriate for web-served files, shared configuration files, and documents that should be readable by all users but writable only by the owner. chmod 600 (rw-------): only the owner can read and write; no access for group or others. Required for SSH private keys, API credential files, and sensitive configuration.
SSH clients (and the ssh-agent) refuse to use private key files with overly permissive permissions as a security protection. If private key files were readable by other users (permissions 644 or 644), any user on the system could steal the key and impersonate you. Permission 600 (owner read/write only) prevents this. The error 'WARNING: UNPROTECTED PRIVATE KEY FILE!' appears when permissions are too open.
The sticky bit (chmod 1777, displayed as t in ls -l) on a directory prevents users from deleting or renaming files they don't own, even if they have write permission to the directory. The /tmp directory uses sticky bit (drwxrwxrwt) so all users can create files but cannot delete others' files. Without sticky bit, any user with directory write access could delete any file in it.
chmod -R 755 /path/to/directory recursively sets 755 on all files AND directories — but this is usually wrong, as files shouldn't be executable. A better approach uses find: find /path -type d -exec chmod 755 {} ; sets directories to 755, then find /path -type f -exec chmod 644 {} ; sets files to 644. This correctly separates directory traverse permissions from file read permissions.