The Real Reason Some Commands Need sudo and Others Don't

There’s a clear logic behind it, and once you see it, you’ll never be confused by a permission error again

Photo by Winston Chen on Unsplash

If you’ve spent any time in a Linux or Mac terminal, you’ve probably noticed the pattern.

Some commands just run. Others throw back a “permission denied” error the moment you try them. You add sudo in front, hit enter, type your password, and suddenly it works.

People treat sudo like a magic word. If something doesn't work, slap sudo in front of it and try again. That works often enough that the actual reason rarely comes up.

But there is a real reason. It’s not arbitrary, and it’s not random. Once you understand the logic behind it, the whole system starts making sense in a way that makes you a noticeably better terminal user. You start knowing in advance which commands will need it and why.

Your computer has two kinds of territory

Think of your operating system as a building with two distinct areas. The first is your personal office.

You own it completely. You can rearrange the furniture, delete things, move things around, and nobody needs to check your credentials before you do any of it. This is your home directory and everything under it.

When you run commands that only touch your own files, your own settings, or your own running processes, the system has no reason to stop you.

The second area is the shared infrastructure of the building. The server room. The electrical panel. The plumbing. This is the part that affects everyone, not just you.

If you want to make changes here, you need to demonstrate that you’re someone with the authority to do so.

That second area, in Linux terms, is things like system configuration files, installed software directories, network settings, hardware devices, and processes owned by other users or by the system itself.

These live outside your home folder, often in places like /etc, /usr, /bin, or /var, and they require root-level access to modify.

sudo is how you temporarily prove you're someone with that authority.

What root actually is

Root is a specific user account that exists on every Unix-based system. It has no restrictions. It can read, write, move, or delete any file anywhere on the system, modify any setting, kill any process, and change the permissions of anything it touches.

It is an all-access account.

On a well-managed system, nobody actually logs in and works as root directly. The risk is too high. One wrong command, one typo in a destructive instruction, and the whole system can be damaged with nothing to stop it.

Instead, regular users are given permission to borrow root’s authority for a single command at a time using sudo, which is short for "substitute user do" or more commonly remembered as "superuser do."

When you run sudo somecommand, the system checks whether your account is on the list of users allowed to do this, asks for your password to confirm you're you, and then runs that one command with root-level access.

The moment that command finishes, your elevated access disappears. You're back to being a regular user with regular restrictions.

The three things that actually determine whether you need sudo

Where the command is trying to write or read. Commands that only interact with your own home directory almost never need sudo.

Commands that try to read from or write to system directories almost always do. A command that reads a file from /etc might work without sudo, since many system files are readable by regular users even if they can't be modified. A command that tries to write to /etc will almost certainly be blocked without it.

Who owns the process or file you’re trying to touch. Every file and every running process on a Linux system has an owner. If you try to stop a process owned by the system, or modify a file owned by root, you need to be authorized to act as root to do it.

That’s why sudo kill is sometimes needed for system processes while kill alone works fine for processes you started yourself.

Whether the command involves hardware or privileged system calls. Some operations, like reading raw disk data, managing network interfaces, or accessing certain hardware devices directly, require privileges beyond what any regular user account has. It doesn’t matter which files are being touched.

iotop needs sudo for this reason. So does anything that talks directly to /dev hardware devices below the normal abstraction layer.

A quick worked example

Here’s what this looks like in practice. Say you want to check which ports are listening on your machine.

Running it without sudo:

netstat -tulpn

This works, but you’ll notice the output is partial. The process names for many entries will show blank or just a dash. Seeing which process owns a port requires access to process information you don’t have permission to read for processes outside your own user.

Run the same command with sudo:

sudo netstat -tulpn

Now the output fills in completely. Same command, same result for the port numbers themselves, but with the process names and IDs fully populated, because root-level access can see the ownership information that was hidden before.

That’s the clearest way to see the difference in practice. The command works either way, but the elevated version sees more.

Why you shouldn’t just add sudo to everything

Root access is powerful in both directions. It can fix things and it can break things, equally, without any warning and without any undo.

A mistyped rm command run as a regular user might delete something in your own folder. The same command run with sudo can delete system files that bring the whole operating system down.

This is why the habit of reflexively adding sudo to anything that doesn't immediately work is worth reconsidering. A permission error is often a signal, not just an obstacle.

It means you're trying to touch something outside your normal territory, and it's worth asking why before elevating to root access and proceeding anyway.

Understanding what a command actually does, and whether it genuinely needs root-level access to do it, is a more useful skill than knowing how to override permission errors.

The permission system exists to protect both you and the system itself. Once you understand the logic behind it, you’re working with it rather than around it.

And that is what actually makes you better at the terminal.

Thanks for reading! I left a six-figure smart contract auditing career to learn Linux, Python, and AI engineering from scratch. I share my raw learning updates and one actionable terminal trick every Wednesday in my newsletter, Terminal to AI. **Join the journey for free here**.