Permissions & Ownership

Sooner or later the filesystem tells you "permission denied," and it feels like the computer is being difficult on purpose. It isn't. Every file carries rules about who's allowed to touch it, and once you can read those rules, that error stops being a wall and becomes a clear, fixable message.

Why permissions exist at all

What it actually is. A shared computer holds things that shouldn't be freely editable by everyone: the system's own configuration, other users' private files, the programs that keep the machine running. Permissions are the filesystem's answer to a question asked on every single file access: "is this person allowed to do this?"

Why this matters. Without permissions, any program you ran - or any other user on the machine - could overwrite the OS, read your private documents, or delete someone else's work. "Permission denied" is usually the system doing its job: stopping a mistake or a security hole.

💡 Key point. "Permission denied" is not a bug and rarely a glitch. It means: the rules on this file don't grant you what you just tried to do. The fix is always one of three things - do it as a user who's allowed, change the file's rules, or accept that you shouldn't be doing it.

The two questions: who owns it, and who can do what

Every file answers two things. First, who owns it - on Unix systems that's an owner (one user) and a group (a named set of users). Second, what's allowed, broken into three actions for three audiences.

The three actions:

   r  = read     → look at the file's contents (or list a folder's contents)
   w  = write    → change the file (or add/remove things in a folder)
   x  = execute  → run the file as a program (or enter/pass through a folder)

The three audiences, in order:

   user    → the single owner of the file
   group   → everyone in the file's group
   others  → everybody else on the machine

📝 Terminology. This is the rwx model: read / write / execute, granted separately to user, group, and others. Almost every permission question on macOS and Linux comes down to reading this little grid.

Reading ls -l - the permission line decoded

What it does in real life. Add -l ("long" format) to ls and the filesystem shows you the rules. Here's the line that confuses everyone the first time, fully annotated:

$ ls -l notes.txt
-rw-r--r--  1  ada  staff  1048  Jun 19 09:14  notes.txt

What just happened: you asked for the detailed listing of one file. That cryptic -rw-r--r-- is the permission grid, and ada / staff are the owner and group. Here's how to read it:

   -  rw-  r--  r--   1   ada   staff   1048   Jun 19 09:14   notes.txt
   │  │    │    │          │     │       │      │              │
   │  │    │    │          │     │       │      │              └ file name
   │  │    │    │          │     │       │      └ last modified
   │  │    │    │          │     │       └ size in bytes
   │  │    │    │          │     └ group that owns it
   │  │    │    │          └ user who owns it
   │  │    │    └ OTHERS can: read only (r--)
   │  │    └ GROUP can: read only (r--)
   │  └ USER (ada) can: read and write (rw-), but not execute
   └ type: "-" = file, "d" = directory

In plain English: ada can read and edit this file; everyone else can only read it; nobody can run it as a program (it's text, not a program - x is off everywhere). That single line answers "why can't my coworker edit this?" before they even ask.

Now a folder and a program for contrast:

$ ls -l
drwxr-xr-x  4  ada  staff   128  Jun 18 17:02  projects
-rwxr-xr-x  1  ada  staff  9216  Jun 10 11:30  deploy.sh

What just happened: the leading d on projects marks it a directory, and its x bits mean people are allowed to enter it (for folders, x means "pass through," not "run"). deploy.sh has x set for everyone, so it's a file meant to be run as a program - what makes a script executable.

⚠️ Gotcha - x means different things for files and folders. On a file, x = "run this as a program." On a folder, x = "you may enter it." A folder you can read (r) but not enter (x) will let you see the names inside but not open them - baffling until you know this rule.

"Permission denied" - what it really means

What it does in real life. Here's the error in the wild, and the calm read of it:

$ echo "edit" >> /etc/hosts
bash: /etc/hosts: Permission denied

What just happened: you tried to write to /etc/hosts, a system file owned by the administrator. Your user has read but not write permission on it, so the filesystem refused before changing a single byte. Nothing broke - the rule held.

The straight fix on Unix is to act as the administrator for that one command using sudo ("do this as the superuser"). To actually change a system file, open it as the administrator - for example with a terminal editor:

$ sudo nano /etc/hosts
[sudo] password for ada:

What just happened: sudo asked for your password and, because you're allowed to use it, opened /etc/hosts as the administrator - who does have write permission. sudo runs one command with full rights; that's how you cross the permission line on purpose. (Why not sudo echo "edit" >> /etc/hosts? The >> redirect is handled by your shell, running as you, before sudo ever starts - so it still hits "permission denied." Editing the file as above sidesteps the trap.)

⚠️ Gotcha. Reflexively slapping sudo on everything to make errors disappear is how people accidentally damage their system or end up owning files as root that they can no longer edit normally. If a normal action needs sudo, pause and ask why this file is protected before forcing past it.

Changing the rules: chmod and chown

What it actually is. chmod ("change mode") edits the rwx rules; chown ("change owner") changes who owns the file. You mostly reach for chmod to make a script runnable:

$ chmod +x deploy.sh
$ ls -l deploy.sh
-rwxr-xr-x  1  ada  staff  9216  Jun 10 11:30  deploy.sh

What just happened: chmod +x turned on the execute bit. Before, the file was just text the system wouldn't run; now the xs are present and you can run it as a program. This is the single most common reason a beginner reaches for chmod - "permission denied" when trying to run their own script.

A short note on Windows

Windows reaches the same goal - controlling who can do what - by a different, more detailed road called ACLs (Access Control Lists). Instead of three audiences (user/group/others) with three bits each, an ACL is a list of entries, each naming a specific user or group and spelling out exactly what they may do (read, write, modify, full control, and more).

📝 Terminology. An ACL is a per-file list of "who → what they're allowed." It's more granular than Unix rwx, which is why Windows permissions are usually managed through the file's Properties → Security dialog rather than a single readable line. The mental model is identical: a file knows its owner, and it knows the rules for who may touch it.

Recap

1. Permissions exist to safely share one machine - they answer "is this person allowed to do this?" on every file access.
2. Unix files carry an owner and group, plus rwx (read / write / execute) for user, group, and others.
3. ls -l shows the rules; read the line left to right - type, then three triplets of rwx.
4. x means "run" on a file but "enter" on a folder - a classic source of confusion.
5. "Permission denied" means the rules didn't grant your action; cross the line on purpose with sudo (carefully), or change the rules with chmod / chown.
6. Windows uses ACLs for the same idea - more detailed lists, same goal.

Next, we'll connect the tree and the rules to what actually happens when you open a file - plus hidden files, what extensions really are, and how to find anything on the disk.

← Phase 1: What a Filesystem Is · Guide overview · Phase 3: Where Things Live & Finding Them →

Try it yourself

Toggle the permission bits and watch the octal (e.g. 755) and rwx string update: