From Files to Permissions: The Linux Mental Models Every DevOps Engineer Must Master
I am a Student pursuing a Master's in Computer application. I have experience in making Frontend projects. I worked on React, and JavaScript and currently learning Node for Backend. In his free time, he likes to contribute to open source. Apart from that he is also a Technical Blogger.
Most DevOps failures don’t happen because someone doesn’t know Kubernetes or Terraform.
They happen because someone misunderstands how Linux actually works underneath.
If you’re running containers, deploying services, or debugging production servers, you are interacting with the Linux filesystem, users, permissions, and privilege boundaries constantly.
This guide connects several foundational topics together:
Linux filesystem structure
Users and groups
File permissions (
chmod)File ownership (
chown)sudoand privilege escalationUsing Multipass as a local DevOps lab
The goal is not memorization — it’s building mental models you can rely on in production.
Linux Is One Giant Tree (The Filesystem Mental Model)
Unlike Windows, Linux does not use multiple drives like C:\, D:\, etc.
Everything exists inside a single unified directory tree that starts at the root directory:
/
Think of it like a city map.
/
├── bin
├── etc
├── home
├── var
├── usr
└── tmp
Each directory has a specific responsibility.
Understanding this structure makes debugging systems dramatically easier.
/bin – Essential User Commands
/bin contains fundamental commands needed for basic system operation.
Examples:
/bin/ls
/bin/cat
/bin/bash
/bin/mkdir
These commands must exist even if the system boots in minimal mode.
Try:
ls /bin
You’ll see the essential tools every Linux system depends on.
/sbin – System Administration Tools
sbin contains commands intended for system administrators.
Examples:
/sbin/reboot
/sbin/ip
/sbin/mkfs
Many of these commands require root privileges.
Example:
which reboot
Output:
/usr/sbin/reboot
/etc – System Configuration
The /etc directory stores configuration files for the entire system.
Examples:
/etc/passwd
/etc/ssh/sshd_config
/etc/nginx/nginx.conf
/etc/fstab
If something behaves incorrectly, /etc is usually where the configuration lives.
Example:
cat /etc/os-release
Shows details about the Linux distribution.
/home – User Workspaces
Each user gets their own directory inside /home.
Example:
/home/nikhil
/home/devops
This is where personal files, SSH keys, and local configuration live.
Example:
ls /home
/var – Changing Data
/var contains files that change frequently.
Examples:
/var/log
/var/lib
/var/cache
Important for DevOps:
/var/log
Most application logs live here.
Example:
ls /var/log
/usr – Installed Software
This directory contains user-level programs and libraries.
/usr/bin
/usr/lib
/usr/share
Example:
ls /usr/bin | grep python
/tmp – Temporary Files
Temporary files that may be cleared during reboot.
Example:
touch /tmp/testfile
Many applications use /tmp for intermediate processing.
Users and Groups: Linux’s Security Model
Linux is fundamentally a multi-user operating system.
Every process runs as a user, and every user belongs to groups.
Why this matters:
Security isolation
Permission control
Resource ownership
You can inspect users with:
cat /etc/passwd
Groups are stored in:
cat /etc/group
Creating Users and Groups
Example:
sudo adduser devuser
Create a group:
sudo groupadd devops
Add a user to a group:
sudo usermod -aG devops devuser
Verify group membership:
groups devuser
Linux File Permissions (chmod)
Every file in Linux has three permission layers:
Owner
Group
Others
Each layer can have:
r = read
w = write
x = execute
Example:
-rwxr-xr--
Breakdown:
Owner → rwx
Group → r-x
Others → r--
Check permissions:
ls -l
Example output:
-rw-r--r-- 1 nikhil devops 200 Mar 10 script.sh
Numeric Permission System
Permissions also use numeric values.
Read = 4
Write = 2
Execute = 1
Example:
7 = 4+2+1 = rwx
5 = 4+1 = r-x
4 = read
Setting permissions:
chmod 755 script.sh
Meaning:
Owner → rwx
Group → r-x
Others → r-x
This is common for executable scripts.
File Ownership (chown)
Every file belongs to a user and group.
Example:
nikhil devops script.sh
Change ownership:
sudo chown devuser script.sh
Change user and group:
sudo chown devuser:devops script.sh
Recursive ownership change:
sudo chown -R devuser:devops project/
This is extremely common in Docker volumes and deployment directories.
sudo: Controlled Root Access
The root user has full control over the system.
Instead of logging in as root, Linux uses sudo.
Example:
sudo apt update
This temporarily runs the command with root privileges.
Permissions are defined in:
/etc/sudoers
Best practice in production:
Never run services as root unless absolutely required.
Practicing All of This with Multipass
Instead of experimenting on your main machine, use Multipass to create disposable Linux environments.
Launch a VM:
multipass launch --name devops-lab
Access the VM:
multipass shell devops-lab
List instances:
multipass list
Delete when finished:
multipass delete devops-lab
multipass purge
This is essentially a local cloud sandbox.
You can safely test permissions, users, and system configuration.
Practical Lab: Simulating a DevOps Deployment
Let’s simulate a typical scenario.
Create a new user:
sudo adduser deploy
Create an application directory:
sudo mkdir /opt/myapp
Assign ownership:
sudo chown deploy:deploy /opt/myapp
Set permissions:
chmod 755 /opt/myapp
Now the deploy user can manage the application safely without root access.
This pattern appears in:
Docker containers
CI/CD pipelines
application deployments
system services
Common Mistakes DevOps Engineers Make
1. Running Everything as Root
This is dangerous.
If a service gets compromised, attackers gain full system access.
Better approach:
Use dedicated service users.
2. Using chmod 777
Example:
chmod 777 file
This gives everyone full access.
It is usually a sign that someone doesn’t understand permissions.
3. Forgetting Group Permissions
Teams often share directories.
Instead of giving full access to everyone, use groups.
Example:
devops group → shared deployment directory
4. Recursive Permission Changes Without Thinking
Commands like:
chmod -R 777 /
can break a system or create massive security issues.
Always confirm directory paths before using -R.
The Real DevOps Insight Most Beginners Miss
DevOps tools like:
Docker
Kubernetes
CI/CD systems
Terraform
Cloud instances
all run on top of Linux primitives.
If you deeply understand:
filesystem layout
permissions
users
privilege boundaries
you can debug problems that most engineers struggle with.
For example:
A container failing to write logs often isn’t a Docker issue — it’s a filesystem permission issue.
Conclusion
Linux fundamentals are not beginner topics.
They are production survival skills.
If you understand:
how the filesystem is structured
how users and groups control access
how permissions and ownership work
how privilege escalation is managed
you gain the ability to debug real infrastructure problems instead of guessing.
The next practical step is simple:
Create a Multipass lab and practice:
creating users
assigning groups
changing permissions
simulating deployment directories
Spend an hour experimenting.
