Understanding Linux File Permissions (chmod and chown)

Three Classes, Three Permission Types

Every file and directory on a Linux server carries exactly three permission classes — owner, group, and other — and exactly three permission types per class: read, write, and execute. That is nine yes/no switches total, and the entire permission system, no matter how it is written on screen, is just those nine switches turned on or off.

Each permission type also has a fixed numeric value: read is 4, write is 2, execute is 1. Add the values that apply within one class and you get a single digit for that class — read and write together is 6, read and execute together is 5, all three is 7, none of them is 0. A file's full permission set is just three of those digits stacked in order: owner, then group, then other.

Reading and Setting Octal Permissions

`chmod 644 file` is the standard permission for a regular web file: rw-r--r--, meaning the owner can read and write it while the group and everyone else can only read it. `chmod 755 file` is the standard for a directory or an executable script: rwxr-xr-x, meaning the owner has full control while the group and other can read and execute but not write.

The `ls -la` output above breaks down into recognizable pieces: the first character is the file type (`-` for a regular file, `d` for a directory, `l` for a symlink), the next nine characters are the owner, group, and other permission triads in order, and the two names that follow the size are the owning user and owning group. Learning to read that one line on sight covers most day-to-day permission troubleshooting.

Symbolic Permissions as an Alternative

Symbolic notation changes one class and one permission type at a time instead of rewriting the whole set of three digits, which makes it the faster option when only a single bit needs to move. `u`, `g`, and `o` stand for owner, group, and other; `+`, `-`, and `=` add, remove, or set a permission exactly; and `r`, `w`, `x` name the permission itself.

Octal and symbolic notation are two views of the same nine switches, not two different systems — `chmod 755 file` and `chmod u=rwx,g=rx,o=rx file` produce an identical result. Use octal when setting a permission set from scratch, and symbolic when nudging one class of an existing file without touching the rest.

Why Directories Need the Execute Bit

The execute bit means something different on a directory than it does on a file, and that difference is exactly why directories are typically 755 while regular files are typically 644. On a file, execute means "run this as a program." On a directory, execute controls whether a user can traverse into it and stat the entries inside it — read a file's metadata, open it, or list it by name — even when the read bit is also set.

This is the source of a common mix-up: applying `644` to an entire site directory tree with a single recursive command leaves every directory unable to be traversed, breaking the site outright. Directories need the execute bit to be usable at all; files almost never need it unless they are scripts or binaries meant to be run directly.

Changing Ownership with chown and chgrp

`chown` changes who owns a file, and it can update the owning user, the owning group, or both in a single command. `chown user file` changes only the owner, `chgrp group file` changes only the group, and `chown user:group file` changes both at once — which is the form that comes up most often after files land on a server owned by the wrong account.

That exact command is the standard fix after uploading files as a different system user than the one the web server runs as — for example, uploading over SFTP as a `deploy` account while PHP-FPM runs as `www-data`. Without the ownership correction, the web server can often still read the files but fails silently on anything that needs to write: cache directories, upload folders, and update routines all depend on the process owner actually owning what it's trying to modify.

Getting Permissions Right Without Guessing

Three special bits sit above the standard nine switches and rarely come up outside shared-write scenarios: setuid (4000) runs a program as its owner rather than the user who launched it, setgid (2000) makes new files inside a directory inherit that directory's group, and the sticky bit (1000) restricts deletion inside a directory to each file's own owner. `chmod 2775 shared-uploads` is the practical case worth remembering — it keeps every file dropped into a shared upload folder under the same group, so multiple users can write to it without constantly re-running `chgrp` by hand.

What permissions should never become is a shortcut: `chmod -R 777` makes every file and directory world-writable, and it is a security hole, not a fix, no matter how quickly it makes an error message disappear. Any process on the server, including one running as an unrelated compromised account, can then modify those files freely. The correct response to a permission error is to identify the exact owner and the exact class that needs the exact permission — not to open every door at once.

CloudStick's Advanced File Manager, available on the Basic plan and above, sets permissions and ownership through checkboxes in the dashboard instead of requiring the octal codes and `chown` syntax above to be typed correctly over SSH every time. It also starts from a better position than most setups: every website on a CloudStick server gets its own isolated system user, so files are created with correct ownership from the moment a site is provisioned, rather than needing a `chown -R` cleanup after the fact.