The Root Directory (/): Explanation & Insights

Every file and directory on a Unix or Linux system descends from a single top-level directory, written as a lone forward slash.

What It Is

On a Linux machine there is exactly one place where everything begins, and it has the shortest name of any directory you will ever meet: /. A single forward slash. That is the root directory — the top of the tree, the one directory with no directory above it. Every other thing on the system — every config file, every log, every home folder, every program you run — sits somewhere underneath it. Follow any full path back far enough and you always arrive at the same /.

It helps to picture the whole filesystem as a tree, because that is exactly the word everyone uses for it — branches splitting into branches, files hanging off the ends like leaves. This tree grows the wrong way up: the root is at the top. /usr, /etc, /home branch downward beneath it, and the actual files dangle at the bottom. No gardener ever planted a tree like that, but every server you will ever touch is built on one.

Here is the detail I still find quietly perfect. Every directory on the system has a parent — the one it lives inside — reachable as ... You can walk up and up, .. after .., getting closer to the top each time. So what is the parent of the very top? It has to be something, or the walk would crash. The answer the designers chose is beautifully honest: / is its own parent. Ask the system for /.. and it hands you / right back. It is the one directory in the world you can never step out of, because every door marked "up" leads straight back into the same room.

Why It Matters

Everything depends on /, in the most literal sense the word allows. It is the single assumption every path on the machine is built on: the very first character of an absolute path, that leading /, means "start from the root and work down from there." Strip it away and a path stops being an address at all.

That total dependence cuts both ways. It is what makes the system coherent — there is one namespace, one tree, one agreed-upon "start here," and any program can hand any other program a path and know precisely what it points at. It is also what makes that single slash the most dangerous mark on the disk. When you read horror stories about someone running rm-rf / and turning a working server into a brick, this is why: that command says "delete everything, starting from the top, and don't stop." There is no smaller blast radius than one file and no larger one than /. Aim a recursive delete at the root and you have aimed it at the whole machine.

The Three Roots (and the Confusion They Cause)

Almost everyone trips on this in their first week, and it is not their fault — the word "root" got handed out three times to three different things that all live near each other.

/ is the root directory — the top of the tree, the subject of this page.
root is the superuser — the all-powerful administrator account, user number 0, the one allowed to do anything on the system.
/root is the home directory of that superuser — where the root account keeps its files, the equivalent of what /home/alice is for an ordinary user.

The trap is /root. It reads like it should be something to do with the root of the filesystem, and it sits right there at the top of the listing — but it is just a folder that happens to be named after its owner. It lives on /, the way every folder does; it is emphatically not / itself. Deleting /root costs the administrator their files. Deleting / costs you the server. The single slash makes all the difference, which is a fine summary of Unix in general.

What Lives Directly Under It

The children of / are not a random pile. Their layout is written down in a document called the Filesystem Hierarchy Standard — the shared agreement that lets a program written on one Linux distribution find its files on another, because everyone put them in the same place. Each top-level directory has one job:

Directory	What it holds
`/etc`	System-wide configuration — the machine's settings, in plain text
`/var`	Data that grows and changes: logs, mail, spools, caches
`/usr`	The bulk of the installed software — programs and libraries
`/home`	Ordinary users' home directories, one per person
`/tmp`	Scratch space anyone can write to, wiped on reboot
`/dev`	The hardware, dressed up as files — disks, terminals, `/dev/null`
`/proc`	A live window into the kernel and running processes, invented on the fly
`/boot`	The kernel itself and what's needed to start the machine
`/bin`, `/sbin`, `/lib`	Essential commands and libraries (on modern systems, symlinks into `/usr`)
`/root`	The superuser's home (see above)
`/mnt`, `/media`	Where you attach other disks and removable drives

Read that table not as trivia but as a map. Nearly every question of the form "where does X go?" has already been answered here, decades ago, by people who got tired of every system being laid out differently. When you go looking for a service's config, your reflex should be /etc; for its logs, /var/log. The standard is why that reflex works.

Mount Points: How the Tree Grows

Now the question that makes / genuinely interesting. A server usually has more than one disk — a second drive, a USB stick, a network share from another machine. On some operating systems each of those shows up as a separate, walled-off thing with its own name. Unix made a different choice, and to my eye a far more elegant one: there is only ever one tree, and every extra disk gets grafted onto it as a branch.

That grafting is called mounting, and the spot where a disk joins the tree is its mount point — just an ordinary, empty directory somewhere on /. Attach a new drive at /mnt and, from that instant, everything on the drive appears as files under /mnt, indistinguishable from anything else. Walk into it and you have quietly crossed from one physical disk onto another without a single sign that anything changed underfoot. The / you started from is itself a mount point — it is where your main disk was grafted on when the machine booted, the first branch, the one the whole tree stands on. Which disk goes where is written in /etc/fstab, the table the system reads at startup to assemble the tree.

This is the payoff of committing to one tree instead of many: a path never has to say which disk it lives on. It only says where in the tree it lives, and the mount table quietly takes care of the rest.

How I Inspect It

You do not need special tools to look at the root — the everyday ones tell you everything. Here is the top of the tree on one of my machines:

$ ls /
bin   dev  home        lib    media  opt   root  sbin  sys  usr
boot  etc  lost+found  lib64  mnt    proc  run   srv   tmp  var

To see / as an object in its own right rather than a list of its children, ask stat:

$ stat /
  File: /
  Size: 4096       Blocks: 8       IO Block: 4096   directory
Device: 254,1      Inode: 2        Links: 18
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

Two numbers in there are lovely once you know what they are. The inode — the internal ID the filesystem uses for a file, its real name behind the human-readable one — is 2. It is almost always 2. On the ext family of filesystems that most Linux servers run, inode 1 is reserved for the list of bad blocks and inode 2 is, by unbreakable convention, the root directory. Format a fresh disk and its whole world will hang off inode number 2, the same as nearly every other Linux disk on Earth.

And Links: 18? A directory's link count quietly tells you how many subdirectories it has. Every child folder contains a .. entry pointing back at its parent, and each of those counts as a link. So the root's 18 is: its 16 real subdirectories, each pointing home, plus the directory's own entry, plus that famous .. that loops straight back to itself. The number was never arbitrary; it was counting the doors all along.

To confirm which disk / actually lives on, findmnt or df will say:

$ findmnt /
TARGET  SOURCE                FSTYPE  OPTIONS
/       /dev/mapper/vg-root   ext4    rw,relatime,errors=remount-ro

Gotchas

Danger

rm-rf / means "erase the entire machine." Modern GNU rm refuses it by default — it will not recurse into / unless you also pass the grimly-named --no-preserve-root — but older systems, and the near-miss rm -rf / mnt (a stray space where you meant /mnt), have ended plenty of servers. Treat any recursive delete with an absolute path the way you'd treat a loaded tool: check the target twice before you commit.

A few smaller snags worth knowing:

/root is not /. Worth repeating, because it is the single most common beginner mix-up. One is the top of the filesystem; the other is a folder sitting on it.
The disappearing /bin. On current distributions /bin, /sbin and /lib are no longer real directories — they are symbolic links pointing into /usr, a tidy-up known as the "usr merge." Your old paths still work; they just quietly redirect. That is why they show up with an arrow in a long listing.
/lost+found. That odd entry at the top isn't yours and you should leave it alone. When the disk-checker fsck finds a file that has come loose from the tree — an inode with data but no name, usually after a crash or a failing disk — it parks it here rather than throwing it away. An empty lost+found is a healthy sign.

History and Philosophy

The idea of arranging files as a single branching tree, all descending from one root, was not obvious and did not always exist. It came from Multics, the ambitious 1960s operating system that taught the world hierarchical filesystems, and it separated its directories with a greater-than sign — you would write a path as >usr>alice. When Ken Thompson and Dennis Ritchie built Unix in the early 1970s they kept the tree but swapped the separator for the humble forward slash, and that small mark has been doing double duty ever since: the first / in a path is the root, and every / after it is a hinge between one directory and the next. The same small mark names the top of the tree and every joint below it.

The most telling thing about the one-tree idea is what it looks like when someone doesn't do it. Windows, whose lineage runs back through DOS to a 1970s system called CP/M, never adopted a single root. It gives each disk its own letter — and it still starts your main drive at C:, because A: and B: were spoken for by floppy-disk drives. The floppies vanished from the world decades ago, and the letters are still being held for them, like two reserved seats at a table for guests who are never coming. Unix simply never had that problem. It grafts every disk onto the same tree, so there is nothing to run out of and no seats to reserve.

For a long time each Unix vendor arranged the branches below / however it pleased, which meant a program couldn't be sure where anything lived. The Filesystem Hierarchy Standard, first published in the mid-1990s, ended that quarrel by writing the layout down — this is what belongs in /etc, this in /var, this in /usr — and it is the reason a skill you learn on one Linux box transfers, almost unchanged, to every other.