DevOpsBeginner

Linux Filesystem Hierarchy & Permissions

Why /etc, /var, /usr, and /opt exist as separate, standardized directories under the Filesystem Hierarchy Standard, and how chmod's octal mode and umask actually decide a new file's permissions.

Updated 2026-07-243 min read

On this page

Overview

The Filesystem Hierarchy Standard defines where files belong on a Unix-like system, /etc for host-specific configuration, /var for logs and other data that grows continuously, /usr for installed, largely read-only programs and libraries, /opt for add-on software packages, so that the same paths mean the same thing across distributions and tools can rely on it. On top of that structure, every file and directory carries a permission mode, three octal digits for owner/group/other read-write-execute bits, plus an optional fourth digit for setuid, setgid, and the sticky bit, and every newly created file's actual permissions are the requested mode with the current umask's bits turned off, unless a default ACL on the parent directory overrides that entirely.

Quick Reference

Directory	Purpose
`/etc`	Host-specific configuration
`/var`	Logs, caches, and other continuously-changing data
`/usr`	Installed programs, libraries, and documentation
`/opt`	Add-on application software packages
`/home`	User home directories

Permission bit	Value	Meaning on a file	Meaning on a directory
read (r)	4	View contents	List entries
write (w)	2	Modify contents	Create/remove entries
execute (x)	1	Run as a program	Traverse (`cd` into it)

Syntax

bash

chmod 755 deploy.sh       # rwxr-xr-x - owner full, group/others read+execute
chmod 644 config.yaml     # rw-r--r-- - owner read+write, group/others read-only
chown deploy:deploy app/  # change owner and group

Examples

bash

# umask 022 turns off write for group/others on every new file -
# a requested 0666 becomes 0644, a requested 0777 becomes 0755.
umask 022
touch newfile   # ends up 0644, not 0666

setgid on a shared directory keeps group ownership consistent

Setting the setgid bit on a directory (chmod 2775 shared/) makes every new file created inside inherit the directory's group, instead of the creating user's primary group, which is what actually keeps a shared team directory's group ownership consistent over time.

Visual Diagram

How a file's final permissions are decided

Common Mistakes

Assuming a requested mode like 0666 in application code is the permission a new file will actually get, without accounting for the process's umask.
Using chmod -R 777 to "fix" a permissions problem, which removes all access control rather than granting the specific access actually needed.
Storing application configuration outside /etc or mutable data outside /var, breaking the assumption other tools (backup scripts, package managers) rely on.
Forgetting that a default ACL on a parent directory overrides the umask entirely, then being confused when new files don't have the permissions the umask alone would predict.

Performance

Filesystem hierarchy placement is a management/organizational concern, not a runtime performance one; the practical performance angle is mounting /var or /tmp on separate, appropriately-fast storage when I/O patterns justify it.
Permission checks (the read/write/execute bits, plus ACLs if present) are evaluated by the kernel on every file access but are computationally negligible compared to the I/O itself.

Best Practices

Follow the FHS placement conventions (/etc for config, /var for variable data, /opt for add-on packages) so other tools and administrators can find things predictably.
Set an explicit, deliberate umask (commonly 022 or 027) rather than relying on whatever a shell or service happens to default to.
Grant the minimum permission bits actually needed; reach for a specific chmod, not a blanket 777.
Use setgid on shared team directories so new files consistently inherit the right group, instead of manually fixing group ownership after the fact.

Interview questions

What is the Filesystem Hierarchy Standard, and why does it matter that /etc, /var, and /usr are separate directories rather than one flat structure?

The FHS is a specification for where files belong on a Unix-like system, so that any compliant distribution places configuration, variable data, and installed software in predictable locations regardless of vendor. Separating them matters operationally: /etc holds host-specific configuration that should be backed up and version-controlled, /var holds logs, caches, and other data that grows and changes constantly and often lives on its own disk or partition for capacity/IO reasons, and /usr holds installed programs and libraries that are typically read-only at runtime and can be shared or mounted the same way across many machines. Collapsing them into one flat structure would make it much harder to back up only what matters, mount storage with the right characteristics per use case, or reason about what's safe to wipe and reinstall.

What do the three digits in a chmod octal mode like 644 or 755 actually mean, and what does a leading fourth digit add?

Each of the three digits is a sum of read (4), write (2), and execute (1), in order for the owner, the group, and everyone else; 644 means the owner gets read+write (4+2), while group and others get read-only (4). 755 means the owner gets read+write+execute (4+2+1), and group/others get read+execute (4+1), the common mode for an executable or a directory that others need to traverse. An optional leading fourth digit sets setuid (4), setgid (2), and the sticky bit (1); setuid/setgid make a program run with its owner's or group's privileges rather than the caller's, and the sticky bit on a directory (classically 1777 on /tmp) restricts file deletion to each file's own owner even though the directory itself is world-writable.

A process creates a file requesting mode 0666, but the file ends up with permissions 0644. What decided that, and would the outcome change if the parent directory had a default ACL?

The process's umask is what changed the requested mode: umask 022 turns off the write bit for group and others from any requested mode, so 0666 (rw-rw-rw-) becomes 0666 & ~022 = 0644 (rw-r--r--). The umask is applied by the kernel at file/directory creation time, not by the application deciding to be conservative. If the parent directory has a default ACL set, that changes the outcome: default ACL inheritance takes precedence over the umask entirely, so the new file's permissions would instead be derived from the ACL, not from applying umask to the requested mode.

References

DevOpsIntermediate

Linux Users, Groups & sudo

How /etc/passwd and /etc/shadow split identity from password storage, why a UID (not a username) is what the kernel actually checks, and how a sudoers rule's who/where/as-whom/what structure grants privileges.

Updated 2026-07-24

3 min read

DevOpsBeginner

Linux Fundamentals

The core command-line building blocks - navigation, permissions, processes, networking, and services - that every other Linux topic on this site (filesystem hierarchy, storage, users, networking) assumes you already have.

Updated 2026-07-24

7 min read

DevOpsIntermediate

Linux Logging & Monitoring with journald

Why journald's default "auto" storage mode can quietly discard logs across a reboot on a fresh system, and how journalctl's unit and priority filters actually narrow down a live incident.

Updated 2026-07-24

3 min read

DevOpsIntermediate

Linux Networking

How ip and ss replaced ifconfig and netstat as the modern tools for interfaces and sockets, what TCP socket states like LISTEN and TIME-WAIT actually mean, and how nftables organizes firewall rules into tables and chains.

Updated 2026-07-24

3 min read

Guide