If you’ve ever fixed a permission error by randomly typing chmod 777 and hoping for the best… yeah, that’s the mistake we need to talk about.

On a VPS, sloppy file permissions and bad umask settings can quietly open things up for other users or processes in ways you really don’t want. The good news: once you understand the basic model, Linux permissions are actually pretty logical.

This guide walks through what owner/group/other really mean, how permissions are written, how chmod fits in, and how umask controls default permissions for new files.

Understanding Who Can Access a File: Owner, Group, Other

Linux is built as a multi-user system, even if you’re the only human using your VPS.

Every file and directory is owned by exactly one user. Alongside that, each file is also associated with one group. Other users on the system who are not the owner and not in that group are treated as “others”.

So each file has three permission categories:

• Owner permissions – what the owning user can do
• Group permissions – what members of the owning group can do
• Other permissions – what everyone else on the system can do

Even on a small VPS, you’ll typically have many system users created for services and applications, not just your login.

You can see all users defined on your system by viewing the /etc/passwd file:

cat /etc/passwd

Each line there describes a user. The first field on each line is the username. Many of them belong to services and system components rather than real people.

Why this matters: when you set permissions, you’re not just thinking “me vs internet”, you’re thinking “owner vs group vs everyone else on this box”.

Types of Permissions and How They’re Written

Linux permissions define what each category (owner, group, other) can do with a file or directory.

There are three basic types of permission:

• Read
• Write
• Execute

There are two main ways to describe them:

• Alphabetic notation (like rwxr-x---)
• Octal notation (like 750)

You’ll see both in error messages, ls output, and documentation, so it helps to be comfortable with each style.

Alphabetic Notation: rwx and Friends

Alphabetic notation is the human-readable way permissions are shown.

When you run:

ls -l

you’ll see lines that start with something like:

-rwxr-xr--  1 user group  1234 Jul  1 12:00 example.sh

Ignore the first character for a moment (that one indicates file type). The next nine characters are permissions, in three groups of three:

• First 3: owner permissions
• Next 3: group permissions
• Last 3: other permissions

Each set of three characters follows this pattern:

• r – read
• w – write
• x – execute
• - – permission not granted

So in -rwxr-xr--:

• Owner: rwx → read, write, execute
• Group: r-x → read, execute
• Others: r-- → read only

For directories, x means “can enter / traverse this directory”, so it’s very common to see directories with x set where files might not have it.

Once you can read this alphabetic form, it’s easy to see at a glance who can do what.

Octal Notation: 644, 755, 777 and Friends

Octal notation is the numeric way of representing the same thing.

Each permission type has a number:

• Read = 4
• Write = 2
• Execute = 1

You add them up for each category (owner, group, other).

So for one user/group/other triple:

• rwx = 4 + 2 + 1 = 7
• rw- = 4 + 2 + 0 = 6
• r-x = 4 + 0 + 1 = 5
• r-- = 4 + 0 + 0 = 4
• --- = 0

Then you put the three numbers together in order: owner, group, other.

Examples:

• 644 → owner read/write, group read, other read
• 755 → owner read/write/execute, group read/execute, other read/execute
• 700 → owner read/write/execute, group and other no permissions

This is the same information you see in alphabetic notation, just compressed into numbers. Tools like chmod can use either style.

Changing Permissions with chmod (The Basics)

Once you can read permissions, the next logical step is to change them when needed.

The chmod command changes file and directory permissions. It supports both alphabetic and octal notation.

Alphabetic style looks like this conceptually:

chmod u+r file      # give owner (user) read
chmod g-w file      # remove write from group
ochmod o+x file      # add execute to others

And octal style:

chmod 644 file      # set explicit permissions
chmod 755 script.sh

The alphabetic form is nice when you want to adjust just one piece (like “add execute for owner only”). The octal form is good when you want to set everything in one shot and you already know the numeric combination you want.

The key point: chmod changes permissions of existing files and directories. It doesn’t control what permissions new files get when they’re created. That’s where umask comes in.

What Umask Does: Default Permissions for New Files

umask is all about defaults.

Every time a user or process creates a file or directory, the system starts from a set of default permissions, then applies the user’s umask to remove permissions from that default.

The umask doesn’t grant permissions. It subtracts them.

So you can think of it like this:

• Start with a base “max” permission set
• Subtract the bits specified in the umask
• Whatever remains becomes the permissions on the new file or directory

Because it affects newly created files, setting umask correctly is important for:

• Keeping sensitive data from being readable by other users on the system
• Allowing just enough access for sharing files within a group
• Preventing you from accidentally creating world-readable or world-writable files

How Umask Works with Permissions

While the original guide doesn’t spell out the internals step by step, the important idea is straightforward:

• umask is expressed in the same octal-style permission bits
• Those bits are masked out (removed) from the default permission set when a file or directory is created

For example, if you imagine some base permission and then think “I want to make sure group and others don’t get write permission by default”, you’d set your umask to remove those write bits.

So, instead of going back afterward and running chmod on every new file, you set the umask so new files are created in a safer state right away.

It’s like setting your screwdriver torque correctly so you don’t strip every screw; fix the default, not every individual result.

Configuring Umask Safely on a VPS

On a VPS, it’s easy to forget that multiple users exist because most of them are system accounts.

That’s why you want a umask that’s reasonably strict by default. The exact value you choose depends on how your system is used and who needs to share files, but the process to work with umask always follows the same pattern.

1. Check the current umask

From your shell, just run:

umask

You’ll see an octal-style output. This is the mask that’s applied whenever you create files.

2. Decide your security vs sharing needs

Before changing anything, think about:

• Are you the only user who needs to access your files?
• Do you have multiple human users who need to share files in a group?
• Are there services that write files which might be accessible to others on the system?

Because the umask takes away permissions from the default, a stricter umask means:

• New files will be less accessible to group and others
• You’ll need to deliberately add permissions for sharing when needed

A more relaxed umask does the opposite: easier sharing, but more risk if other users or processes exist on the system.

3. Apply umask in the right place

umask can be set in shell startup files so it applies automatically when you log in or start a shell.

On a VPS, that typically means adding or editing in your shell’s config files (like the ones that control your login shell). Where exactly you set it will depend on how your environment is set up and which shell you use.

The main idea is:

• Set umask where it runs early for your login
• Keep it consistent so new files behave the same way each time

4. Test new file creation behavior

After changing umask, create some test files and directories as that user.

Then run:

ls -l

Look at the permissions for:

• New regular files you create
• New directories you create

Confirm that owners, groups, and others see the level of access you expect.

If you see that new files are too open or too restrictive, adjust the umask and test again.

A Word of Caution When Tweaking Umask

Changing your umask might feel harmless, but it can have system-wide effects if you do it in the wrong place.

The original guide specifically calls out a word of caution around this. The big points to keep in mind:

• umask affects all newly created files for that user (or context)
• A too-permissive umask can make sensitive files readable or writable by other users
• A too-strict umask can break collaboration or cause confusion when services expect broader access

So, before you commit a change:

• Think about which user or service you’re changing umask for
• Avoid editing global configs unless you’re sure of the impact
• Prefer testing in your own user account first

If a service is creating files that are too open or too locked down, handle that for that service specifically instead of blindly changing umask for the whole system.

Quick Recap and Next Step

On a VPS, permissions are your basic safety net. Every file has owner, group, and other permissions, and you can read them in alphabetic (rwxr-xr--) or numeric (like 755) form.

chmod changes permissions on existing files; umask controls what new files get by default by masking out permission bits.

Set umask thoughtfully, test how new files are created, and be cautious about making wide changes that affect many users or services.

Need more help? Check the latest CrushEdge posts.