Why Linux Permissions Matter When You Touch a Server
If you’re logging into a Linux cloud server for the first time, permissions can feel like a wall of cryptic letters and numbers.
It hits anyone who tries to manage a VPS, set up services, or host apps without understanding who owns what on the system.
Linux is a multi-user operating system.
That means everything around files and processes is tied to users, groups, and the permissions attached to them.
If you want to manage a server reliably, you need a basic mental model of that.
This guide walks you through:
– What Linux users are
– What groups are
– How user and group info is stored in /etc/passwd
– How this ties into ownership and permissions at a high level
No drama, just practical steps and checks you can run on your own server.
Step 1: Understand Linux as a Multi-User System
Before touching commands, lock in this idea: Linux is designed for more than one user at the same time.
Even if you are the only human using the VPS, the system itself runs many processes under different users.
That multi-user nature is why ownership and permissions exist in the first place.
They are the basic security layer at the file system level: who can read, write, or execute which file or directory.
For a safe mindset:
– Never assume you’re the only “user” that matters on the box
– Remember that services (like SSH, web servers, etc.) often run as their own users
– Accept that understanding users and groups comes before understanding permissions
If you skip this foundation, you end up doing things like chmod 777 everywhere and wondering why things break or become unsafe.
Step 2: Know the Two Types of Users
On Linux, there are only two main categories of users you need to think about:
- System users
- Regular users
System users
System users are mostly for non-interactive or background processes.
They exist so services and daemons can run under a specific identity instead of running everything as root.
Typical behavior:
– They don’t log in interactively
– They are created automatically by the OS or by packages
– They run things the system depends on (like SSH, background tasks, and so on)
When you first boot a new Linux server, you’ll see a bunch of these already set up.
That’s normal and usually not something you should delete or casually edit.
Regular users
Regular users are the accounts meant for humans.
You use them to log in to the server, open shells, and run commands interactively.
On a fresh cloud server, you will usually:
– Get a default non-root user (depending on the image/provider)
– Or create your own regular user and disable direct root login later
From a permissions point of view, these regular users will own your project files and run your daily commands.
Step 3: Safely Peek at All Users with /etc/passwd
All users on a Linux system are listed in one central place: /etc/passwd.
Despite the name, this file does not store actual passwords anymore on modern systems, but it does hold user account information.
You can see every user by printing this file.
On your server, run:
cat /etc/passwd
You’ll get many lines of output.
Each line represents one user on the system.
A typical line (from the source) looks like this:
sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
landscape:x:110:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:111:1::/var/cache/pollina...
You don’t need to memorize all the fields right now.
For practical use at this stage, just remember: the part before the first : is the username.
So in the sample lines above, the usernames are:
– sshd
– landscape
– pollinate
Those are all system users created for various services.
You might not have the exact same ones, but you will see similar patterns.
Step 4: Spot System Users vs Regular Users in /etc/passwd
When you run cat /etc/passwd, most of what you see on a new cloud server are system users.
These usually:
– Have names tied to a service (sshd, etc.)
– Use shells like /usr/sbin/nologin (meaning they’re not meant for interactive login)
– May have home directories under /var or special system paths
Regular users will generally look different:
– Username is something like ubuntu, debian, or whatever you created
– Home directory path looks like /home/username
– Shell is a real shell like /bin/bash or /bin/sh
Why this matters:
– Don’t delete or modify random system users just to “clean up” your server
– When dealing with permissions, you need to know if a file belongs to a system user or your regular user
If something belongs to sshd, for example, that’s part of the SSH service, not a personal account.
Step 5: Connect Users and Permissions Conceptually
The source tutorial focuses on understanding ownership and permissions, not changing them.
So we’ll stick to the basics here: how users relate to permissions at a high level.
Key idea: ownership + permissions = who can do what to a file or directory.
Each file or directory in Linux has:
– An owning user
– An owning group
– A set of permissions tied to those
Those ownership entries refer back to the users and groups you saw in /etc/passwd (and in the corresponding groups file, which the source implies but doesn’t detail).
So when you:
– Create a new file as your regular user → you become the owner
– Install a service that runs as a system user → that system user may own its config and runtime files
Later, when you read, edit, or troubleshoot permissions, you will always be asking: “which user is this, and what are its permissions on this file?”
Step 6: Practical Safety Tips Before You Touch Permissions
Even though this introduction is about viewing and understanding, not modifying, it’s still good to act carefully on a live server.
If you move from viewing to changing things later, keep these habits in mind.
1. Don’t edit /etc/passwd by hand unless you really know why.
This file is critical for login and system behavior.
Breaking it can lock you out.
2. Avoid changing system user accounts casually.
Users like sshd exist for a reason.
If you change their settings without understanding the service, you might stop that service from working.
3. Prefer a test or staging server for experiments.
If your VPS is running something important (websites, apps, etc.), practice user and permissions changes on a non-critical server first.
4. Always know which user you are logged in as.
Use:
whoami
That tells you which account you’re currently using.
When you later look at file ownership and permissions, you need this context.
Step 7: Check Your Understanding with Simple Exercises
To make this click, here are a few simple checks you can do on your server.
These won’t change anything; they just help you see what’s going on.
A. List all users
You already saw this, but repeat it and read slowly:
cat /etc/passwd
Scan for two things:
– System-style usernames tied to services
– Your regular login user, usually with a /home/... directory
B. Find your own entry in /etc/passwd
Run:
whoami
Note the username, then search for it in /etc/passwd:
grep "^$(whoami):" /etc/passwd
You’ll see the line that defines your user.
Even if you don’t parse every field, you now know: “this is how the system knows I exist.”
C. Notice non-interactive users
Look again at the sample from the source:
sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
The shell here is /usr/sbin/nologin.
That’s a big hint this user is for a service, not for you.
On your server, spot a few users that use nologin and mentally tag them as system accounts.
Step 8: Where to Go Next with Permissions
This article gives you the basic mental model: Linux is multi-user, users are defined in /etc/passwd, and permissions attach to users and groups.
The source mentions there are separate tutorials for:
– How to modify permissions (changing who can read/write/execute)
– How to use umask to control default permissions on new files
Before you dive into modifying anything, make sure you’re comfortable with:
– The idea that files and directories belong to specific users
– The difference between system and regular users
– Reading the usernames out of /etc/passwd
Once that feels natural, learning actual permission bits (rwx, numbers like 644, etc.) will make much more sense.
If this saved you time, bookmark CrushEdge for more fixes.
No Comments