/root: Explanation & Insights

The home directory of the root superuser, kept as a top-level directory separate from /home so it stays reachable even when other filesystems are not mounted.

What It Is

/root is the home directory of the superuser — the account named root, the one the system trusts to do anything at all. It sits at the very top of the tree, right beside /home rather than inside it: the path is /root, not /home/root. Everything an ordinary home directory holds lives here too — a .bashrc, a shell history, the odd small maintenance script, now and then an SSH authorized_keys file — except that this is the home of the one account on the machine that can read, rewrite, or erase every other file on it.

The system doesn't treat any of that as special. Ask it where root lives and it reads the answer out of the very same plain-text file it uses for everybody else:

$ getent passwd root
root:x:0:0:root:/root:/bin/bash

Seven colon-separated fields, identical in shape to the line for every mortal account on the box. The two zeros are the ones to stop on. The first is root's user ID, and this is the whole trick: the kernel's entire notion of "this account may do anything" is that number being 0 — not a list of granted powers, not a special bit, just a plain-integer comparison, uid == 0, buried in the permission checks. All the authority in the operating system rests on a single zero. The sixth field, /root, is what makes this directory root's home: when you log in, the login machinery reads that field and drops you there, exactly the way it would read /home/alice and drop alice into hers. Nothing in the kernel knows /root is important. It's important because this one line says so.

Now look at the directory itself, and the permissions are the first thing to read:

$ ls -ld /root
drwx------ 8 root root 4096 Jul  1 14:38 /root

drwx------ is mode 0700: the owner may read, write, and enter; the group gets nothing; the rest of the world gets nothing. That is the exact same lock every ordinary home directory is born with — the same 0700 the system stamps on /home/alice — and it comes from the same place:

$ grep '^HOME_MODE' /etc/login.defs
HOME_MODE	0700

There's the quiet asymmetry: the one account that can walk through every other door on the machine gets, for its own front door, precisely the same lock as the newest intern on their first afternoon. Not a stronger one. The same one. (The full story of that 0700, of how a home gets seeded, and of why it's stuffed with dot-prefixed files lives on the /home page — it's identical here, so there's no sense telling it twice.) What actually sets /root apart from every home under /home isn't the permissions at all. It's the address.

Why It Matters

Every other home on the machine is, in a quiet way, dispensable. If /home/alice isn't there for a moment — the disk it's on hasn't mounted yet, the file server is rebooting — then alice simply can't log in for a moment, and the world keeps turning. Root's home doesn't get that luxury. It has one job the others don't: it has to work precisely when nothing else does. Root is the account you become to fix a broken machine, and a broken machine is exactly the situation where half the filesystems might not be mounted.

So look at where /root actually sits:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
…               1.8T  1.5T  270G  85% /

/root isn't on a disk of its own — it's part of /, the root filesystem, sharing the same 1.8 terabytes as everything else on the box. That looks like the same ordinary arrangement /home often has, but here it is a deliberate structural promise rather than a default nobody thought about. The root filesystem is the one filesystem the kernel cannot boot without: it's mounted before anything else, and if it isn't there, there is no running system to speak of. Put root's home on that filesystem and it inherits the strongest availability guarantee the machine has to offer, for free.

You feel the payoff the day something goes wrong. Boot a wounded server into rescue mode — single-user, almost nothing mounted, no network, no /home — and you still land at a root shell with a working home directory, because /root came up on the root filesystem alongside the kernel that's keeping the lights on. It's the difference between a bare prompt that has forgotten who you are and one that still reads your .bashrc, still remembers your history, still has your handful of repair scripts within reach while you dig the box out of its hole. The doctor keeps the emergency bag by the front door, not in the attic — because the attic is exactly the part of the house you might not be able to reach.

Why It Isn't Under /home

Here's the counterfactual that makes the whole design click. Suppose root lived at /home/root, tidy and logical, and suppose — as is genuinely common on real servers — /home were its own separate partition, or an NFS share (a directory served over the network from another machine) mounted from a file server down the hall. Now that partition fails to mount, or the file server is down, or the network is the very thing you booted up to fix. Root logs in… into a home directory that isn't there. The account you rely on to rescue the machine has just been locked out by the same failure you're trying to repair.

Keeping /root on the always-mounted root filesystem is what forecloses that. And this isn't folklore — it's written into the Filesystem Hierarchy Standard, the document that settles where things go on a Linux system. The standard names /root the recommended home for the superuser, and spells out the fallback in the same breath: if root's home directory is not on the root partition, the system must make certain it defaults to / when it can't be found.

And that fallback is more stubborn than it looks. Try to leave root homeless and you can't quite manage it: strip /root away, and the login system doesn't shrug and give up — it moves root back upstairs into /, the top of the entire tree. Which, on the oldest Unix systems, is exactly where root lived to begin with. Early /etc/passwd files simply listed root's home as / — a single slash, the root of everything — and root's dotfiles sat scattered across the top of the filesystem like coats dropped in a hallway. /root was carved out later to give the superuser a proper room of its own and stop the clutter. But the old address never fully went away; it's still there as the address of last resort. The superuser is the one account on the machine whose fallback home is the root of the whole world.

Whose Home Is This Shell In?

Here is the practical confusion that catches nearly everyone once, and it's worth untangling slowly, because becoming root and landing in /root are not the same event. The dividing line is the dash.

A login shell — the kind you get with a dash — behaves as though root just sat down and logged in fresh. It throws away your environment, sets $HOME to /root, and drops you in /root. A non-login shell does no such housekeeping; it keeps much of the environment you brought with you. So depending on exactly how you become root, $HOME might say /root, or it might still be pointing at your own home directory while you stand there wearing root's powers.

How you became root	Login shell?	`$HOME`	You land in
`su -`	yes	`/root`	`/root`
`sudo -i`	yes	`/root`	`/root`
`su`	no	`/root`	wherever you already were
`sudo -s`	no	usually still yours	wherever you already were
`sudo somecommand`	n/a	usually still yours	—

The two with the dash — su - and sudo -i — are the clean ones: a proper root login, $HOME set to /root, no surprises. Plain su is the odd middle case — modern versions do set $HOME to /root, but they leave you standing in whatever directory you started in, with much of your old environment (your PATH included) still clinging on. And the no-dash sudo forms are where the real foot-gun lives: by default, on many systems, they leave $HOME pointing at your home, not root's — though this one is genuinely governed by the machine's sudo policy, so the only safe move is to look rather than assume.

Why care? Because a great many programs write to $HOME without announcing it. Run something under plain sudo and it tucks a config file into ~/.config, drops a cache in ~/.cache, or writes a downloaded key to ~/.ssh — and if $HOME is still your home, you've just scattered root-owned files through your own directory, files you now can't edit or delete without becoming root all over again. The same split decides where your .bash_history lands: which commands get recorded to /root's history and which to your own depends entirely on which flavour of "become root" you reached for.

Pro Tip

The instant you become root, run echo "$HOME"; pwd. Those two answers tell you whether you're in a clean root login or a mongrel shell wearing root's authority with your own environment — and that one glance saves you an afternoon of hunting down root-owned junk in your home directory later.

Why the Prompt Turns Red

A lot of systems paint root's shell prompt red on purpose — Fedora and Kali ship it that way out of the box, and countless admins wire it into /root/.bashrc by hand. It is not decoration. It's a tripwire for the eyes.

You already get one small signal for free: an ordinary user's prompt ends in $, and root's ends in #, a convention old enough that "the pound prompt" is just shorthand for "you're root now." The red is a second, louder version of the same warning, and it's earned. Root has no seatbelt. There is no are you sure? — rm doesn't ask, the permission checks that stop the rest of us from wandering into the wrong file are skipped wholesale for uid == 0, and the machine does precisely what you told it, instantly, with complete and cheerful obedience. A stray space in an rm -rf command reads very differently when the prompt in front of it is the colour of a stop sign.

And notice where that warning lives: in /root/.bashrc, a dotfile in this very directory — the same .bashrc that still greets you in rescue mode. Root's one guardrail comes up even on a half-mounted, wounded machine, because it rides the always-mounted root filesystem alongside everything else in /root. The machine never turned the prompt red to protect you; you did, and tucked the warning into your own home, about your own power — the single seatbelt on the account that has none, and you fit it yourself.

Gotchas

Becoming root doesn't guarantee you're in /root. As above: only the dash forms (su -, sudo -i) give you a clean root login with $HOME=/root. The rest can leave $HOME pointing at your own home, which is how root-owned config files end up littering /home/you.
/root's 0700 is the most consequential lock on the machine. A normal home holds someone's private files; /root tends to hold the keys to the kingdom — SSH private keys, credentials, scripts that run as root. Loosening it with chmod 755 (never mind 777) hands every account on the box a reading window onto the exact material that would let them become root. If you ever find /root opened up, close it: chmod 700 /root.
A full root filesystem is a full /root, and you log in through the wound. Because /root shares /, a root filesystem that fills to 100% takes root's own home down with it — and you'll be logging into that same jammed disk to fix it. Watch the space on /, not just on your data volumes. See disk full.
/root is for administering the machine, not for storing your life. The FHS is explicit that root's home shouldn't accumulate a user's clutter, and there's a hard reason underneath the etiquette: a giant download or an unpacked build tree dumped in /root eats the root filesystem, the one filesystem the whole machine depends on. Big scratch data belongs on a data volume or in /var, not here.
Don't lock root out of its own home. Point root's home field at a path that doesn't exist, or its shell at a binary that's missing, and you can turn the one account meant for rescue into the one you can't log into. Change root's /etc/passwd line with the same care you'd change the locks while you're still inside.

Cheat Sheet

# --- Who is root, and where does it live? ---
getent passwd root              # the passwd line: UID 0, home /root, shell /bin/bash
ls -ld /root                    # permissions on root's home — should be drwx------ (0700)
df -h /root                     # confirm it's on the root filesystem (/), always-mounted

# --- The mode homes are created with ---
grep HOME_MODE /etc/login.defs  # 0700 — the same default lock /root wears

# --- Become root, cleanly (login shell: $HOME=/root, land in /root) ---
su -                            # needs the root password
sudo -i                         # needs YOUR password; logged, no shared root password

# --- Become root WITHOUT a clean login (mixed environment — verify!) ---
su                              # $HOME=/root but you stay put, old PATH clings on
sudo -s                         # non-login shell; $HOME may still be YOURS
echo "$HOME"; pwd               # run this the moment you become root, every time

# --- Put the lock back if /root has drifted open ---
chmod 700 /root