Files, permissions and ownership

On a shared server, not everyone should be able to read every file or run every program. Linux controls this with a permissions system that decides, for every file, who can read it, change it, or execute it. It is one of the first things that confuses newcomers and one of the most important things to understand, because half of "why won't this work on the server?" problems are permission problems. This lesson is files, permissions and ownership.

Every file has an owner and a group

Run ls -l and each line starts with something like this:

-rw-r--r--  1  asha  developers  1024  Sep 28 10:00  report.txt

Two of those columns are about who owns the file:

• asha — the user who owns the file.
• developers — the group that owns it. A group is a named set of users, so you can grant access to several people at once.

Every file belongs to one user and one group, and permissions are defined in terms of three classes: the owner (user), the group, and others (everyone else). This lets you say "the owner can edit it, the group can read it, and nobody else can touch it" — exactly the kind of control a shared server needs.

Reading the permission string

That first column, -rw-r--r--, is the permissions, and it looks cryptic until you split it up. The first character is the type (- for a normal file, d for a directory, l for a link). The remaining nine are three groups of three:

-  rw-  r--  r--
^   ^    ^    ^
|  owner group others
type

Within each group of three, the three positions mean read (r), write (w), execute (x), and a - means "not allowed":

• r (read) — can view the file's contents (or, for a directory, list what is in it).
• w (write) — can change the file (or, for a directory, add/remove files in it).
• x (execute) — can run the file as a program (or, for a directory, cd into it).

So -rw-r--r-- reads: a normal file; the owner can read and write; the group can read; others can read. A script that is -rwxr-xr-x can be executed by everyone. Learning to read this string at a glance is a core skill — it tells you instantly what is and is not allowed.

Changing permissions with chmod

You change permissions with chmod ("change mode"). There are two ways, and you should know both because you will see both.

Symbolic — readable, good for a single change:

chmod +x deploy.sh       # add execute permission (make a script runnable) for everyone
chmod u+x deploy.sh      # add execute for the user (owner) only
chmod g-w file.txt       # remove write from the group
chmod o-r secret.txt     # remove read from others

u=user/owner, g=group, o=others, a=all; + adds, - removes.

Numeric (octal) — compact, very common in scripts and docs. Each permission has a value: r=4, w=2, x=1, and you add them up per class:

chmod 644 file.txt   # owner rw (4+2=6), group r (4), others r (4)  -> -rw-r--r--
chmod 755 script.sh  # owner rwx (7), group r-x (5), others r-x (5) -> -rwxr-xr-x
chmod 600 secret.txt # owner rw, group nothing, others nothing      -> -rw-------

644 (files) and 755 (directories and executables) are the everyday defaults; 600 is for private files like keys. chmod 600 on an SSH private key is something you will do in the SSH lesson — and SSH will refuse to use a key that others can read, which is your first taste of permissions mattering in practice.

Changing ownership with chown

Ownership is changed with chown ("change owner"), usually needing administrator rights (below):

sudo chown asha file.txt              # change the owning user to asha
sudo chown asha:developers file.txt   # change user to asha and group to developers
sudo chown -R asha /var/www/app       # recursively, for a whole directory tree

You do this when files end up owned by the wrong user — a very common cause of "permission denied" when, say, a web server user cannot read files owned by someone else.

root and sudo: the administrator

One user, root, can do anything — read, write and execute every file, ignoring permissions entirely. It is the administrator (superuser). You do not normally log in as root, because a mistake as root can destroy the system. Instead you run individual commands as root with sudo ("superuser do"):

sudo apt update            # run this one command with administrator rights
sudo systemctl restart nginx

sudo asks for your password and runs just that command as root. The discipline is: work as a normal user, and reach for sudo only for the specific commands that genuinely need it. Running everything as root, or logging in as root, is how small mistakes become disasters — the same "slow down around power" caution as the rm warning. When a command says "permission denied", the question is often "does this genuinely need sudo, or is a file owned by the wrong user?" — and now you can tell.

Check your work

Owner + group. Every file belongs to one user and one group (a named set of users); permissions are defined for three classes: owner, group, and others.

The permission string (-rw-r--r--): first char is type (- file, d dir, l link); then three triplets (owner/group/others), each read / write / execute, - = denied. For a directory, x means "can cd in", w means "can add/remove files". Read it at a glance.

chmod changes permissions — symbolic (chmod +x, u+x, g-w; u/g/o/a, +/-) or numeric (r=4 w=2 x=1 per class): 644 files, 755 executables/dirs, 600 private keys. SSH refuses a key others can read.

chown changes ownership (chown user:group file, -R recursive; usually needs sudo) — fixes wrong-owner "permission denied".

root + sudo: root ignores all permissions (the superuser); don't log in as root — run specific commands with sudo. Work as a normal user, sudo only what needs it.

Practice

1. Run ls -l on a directory and read three permission strings aloud: type, and what owner/group/others may do.
2. Create a script, chmod +x it, and confirm the x appears in ls -l; then remove it with chmod -x.
3. Convert -rwxr-xr-x to its numeric form, and convert 640 to its symbolic string.
4. chmod 600 a file and explain why that is the right mode for a private key.
5. Explain the difference between chmod and chown, with a scenario for each.
6. Explain why you run commands with sudo rather than logging in as root, and give an example command that needs sudo.

Official documentation

• Ubuntu — File permissions — Reading and changing permissions, with examples.
• GNU Coreutils — chmod invocation — The reference for changing permissions.
• Ubuntu — RootSudo — Why sudo is preferred over the root account.

Next: processes, signals and services.