/home: Explanation & Insights

The directory that holds each user account's personal files, settings, and configuration on a Linux system, kept private to its owner by default.

What It Is

/home is where people live on a Linux machine. Every human account gets one directory beneath it — /home/alice, /home/jsmith — and inside that directory sits everything that belongs to them: their documents, their downloads, their shell history, their SSH keys, and the saved configuration for nearly every program they run. When you log in, this is where you land. When any program asks itself "where do I keep this user's stuff?", the answer, almost always, is here.

The shell even gives your home a private nickname. That ~ you type without a second thought — cd ~, ~/notes.txt, ~/.ssh/ — expands to your own home directory. It's such deep muscle memory that hardly anyone stops to notice it is a convention, a deliberate shorthand somebody had to invent. Somebody did — and why a tilde, of all the characters on the keyboard, is the one thing this page saves for last.

Look at the directory itself and the first surprise is who owns it:

$ ls -ld /home
drwxr-xr-x 3 root root 4096 May  8 21:31 /home

Not any user — root. /home belongs to the system, and its permissions (drwxr-xr-x, mode 755) let anyone read the list of who lives there while letting only root add or remove a resident. Picture /home as a street and each account's directory as a house on it: anyone can walk down the street and read the nameplates — the usernames are public — but only root, the landlord, gets to build a new house or knock one down, and every front door has its own lock. The whole design turns on those locks.

Why It Matters

/home earns its importance twice over: it is where your data actually is, and it is where privacy is actually enforced.

Start with the locks. When a new home is created, it comes out with one specific, deliberately strict permission mode — and the system spells that default out for you:

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

0700 renders as drwx------: the owner can read, write, and enter; the group can do nothing; everyone else can do nothing. One octal number, and an entire life is private by default. On a shared box with fifty accounts, alice can cd /home and see that bob has an account — the street is public — but the moment she tries cd /home/bob she's bounced with Permission denied. She can't list his files, can't read them, can't even learn their names. That's the two-layer trick worth holding onto: the street is world-readable (755, owned by root), each house is sealed to its owner (0700). Public address, private interior.

Then there's the plain fact of what's in there. The operating system you can reinstall from an image in twenty minutes. The packages apt can refetch on demand. Even /etc, the system's configuration, you can mostly regenerate. But the half-finished novel, the photos, the years of accumulated settings, the private key that authenticates you to twelve other servers — those exist nowhere else. When someone says "back up the server," nine times in ten what they truly mean, whether they know it or not, is back up /home. It is the one directory on the machine you cannot rebuild from scratch.

Pro Tip

If your backup covers exactly one thing, make it /home. Everything else on a server is a fresh install and a config-management run away from being reborn identical; the contents of /home are the only bytes on the box with no upstream copy to pull from.

What's Inside a Home Directory

Most of what fills a home directory, the owner put there. But a brand-new account is not born empty — it's born seeded. The instant useradd -m creates a home, it copies in a starter kit from a directory with the wonderfully blunt name /etc/skel — short for skeleton:

$ ls -la /etc/skel
drwxr-xr-x   2 root root  4096 May 18 09:12 .
drwxr-xr-x 147 root root 12288 Jul 19 10:34 ..
-rw-r--r--   1 root root   220 Mar  8 16:21 .bash_logout
-rw-r--r--   1 root root  3526 Mar  8 16:21 .bashrc
-rw-r--r--   1 root root  5290 Aug 28  2025 .face
lrwxrwxrwx   1 root root     5 Aug 28  2025 .face.icon -> .face
-rw-r--r--   1 root root   807 Mar  8 16:21 .profile

Every one of those names begins with a dot, and every single account on this machine started life holding a byte-for-byte identical copy of them — the same .bashrc, character for character. From that shared beginning each account quietly diverges: one person tunes their prompt, another piles on aliases, a third never opens the file at all. /etc/skel is the mould every home is stamped from, exactly once, at the moment of its creation. Same cast, then a thousand different lives.

The .bashrc it hands out is worth opening, because it's the very first thing your shell reads when it starts:

$ head -15 /etc/skel/.bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it

That case block near the top is the shell asking one careful question before it does anything else. $- is the set of option flags the current shell is running with, and an i in there means interactive — a shell with a human at the keyboard. If the i is present the block does nothing and carries on; if it's absent, return bails out immediately. It's the reason a script that quietly starts a shell in the background doesn't waste time setting up a prompt and command history nobody's there to use.

Two of the seeded files have nothing to do with your shell: .face is a small avatar image, and some graphical login screens will actually display it next to your name on the greeter. .face.icon isn't a second copy — the lrwxrwxrwx and the -> mark it as a symlink, a signpost pointing back at .face so a program expecting either name finds the same picture. An obscure corner of the convention, but a genuine one.

And where do all those "new home lands here, seeded from there" defaults come from? Another plain file, /etc/default/useradd, which documents itself by showing you exactly what it would do if you told it nothing:

$ cat /etc/default/useradd
SHELL=/bin/sh
# GROUP=100
# HOME=/home
# INACTIVE=-1
# EXPIRE=
# SKEL=/etc/skel
CREATE_MAIL_SPOOL=no

The commented-out lines aren't dead — they're the fallbacks. Leave them alone and a new account lands under HOME=/home, gets seeded from SKEL=/etc/skel, and is handed /bin/sh as its shell. The file is a set of factory settings written in the margin.

Its Own Filesystem, Sometimes

Here's a question worth asking of any box: is /home its own disk, or just a folder like any other? Ask this particular box and there's no separate answer to give:

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

/home never shows up as a filesystem of its own — it's simply part of /, the root filesystem, sharing the same 1.8 terabytes as everything else on the machine. That's completely normal, and completely fine. But it is a choice, not a law, and plenty of servers make the opposite one.

On those, /home is a separate partition or a whole separate disk, mounted in its own right — and the reason is worth knowing before you build your next box. If /home lives on its own filesystem, you can wipe and reinstall the entire operating system on / without touching a single user file. Blow away the system; keep the people. A separate /home is a firewall between the part of the machine that's replaceable and the part that isn't.

It can go one step stranger still. In a great many companies /home isn't even on the computer you logged into — it's mounted across the network from a central file server over NFS (the Network File System, which makes a directory on one machine appear as an ordinary folder on another). Log into any of a hundred different workstations and the same /home follows you onto each: same files, same shell config, same desktop, because every one of those machines is mounting the one real directory off the same server. That's the honest answer to "why would a plain directory ever need to be its own mount" — so that your home can live somewhere else entirely, and come to wherever you sit down.

How I Inspect It

The moves I make, roughly in order, when I want to understand /home on a machine I've just met:

# Who has an account here?
ls -l /home

# Permissions on the street, then on one house
ls -ld /home /home/alice

# Is /home its own filesystem, or just part of /?
df -h /home
mount | grep -w /home        # a line printed = separate mount; nothing = it's on /

# What starter files does a brand-new account get?
ls -la /etc/skel

# Where's the space going — whose home is enormous?
du -sh /home/* 2>/dev/null | sort -rh | head

The one I never skip is the mount check. Before I reason about anything — a disk-space alarm, a user whose settings keep vanishing, a permissions puzzle — I want to know whether /home is a local partition, part of the root disk, or an NFS mount hanging off a server across the building, because a surprising amount of the diagnosis forks on that single answer.

Gotchas

root does not live in /home. The superuser's home is /root, a separate top-level directory — and that's deliberate. If /home is a separate mount that fails to come up at boot, root still needs a working home to log in and fix it, so root's home stays on the root filesystem where it's always available.
Deleting a user does not delete their home. userdel alice removes the account but leaves /home/alice sitting there, now owned by an orphaned numeric ID. You have to ask for the home explicitly with userdel -r alice — which deletes it, permanently, no /tmp-style grace period.
~ is per-user, and root's ~ is /root. This bites people helping out as the superuser: a script you run with sudo that writes to ~/config or ~/.cache does not write to the user's home — it writes to /root, because ~ and $HOME follow whoever's actually running the command. Files go missing in plain sight this way.
Loosening a home's permissions exposes everything. A home directory at 0700 is the strong, quiet default. chmod 755 (or, heaven forbid, 777) on a home directory hands every other account on the box a window into its owner's files. If you find a home that's been opened up, close it.
Don't stash service data in a person's home. A daemon that keeps its state under some user's /home is a foot-gun: the home might be an NFS mount that's briefly unreachable, or encrypted and unmounted the moment that user logs out. Machine state belongs in /var; homes are for humans.

History and Philosophy

/home is younger than Unix itself, and the tale of where it came from is one of the tidier accidents in Unix's whole history.

In the earliest Unix there was no /home at all. User home directories lived in /usr — because that is precisely what the name was short for: user. Ken Thompson's home was /usr/ken; Dennis Ritchie's was /usr/dmr. Then, around 1971, the machine ran out of room. Unix was living on a pair of small removable disks — the RK05, about a megabyte and a half each — and when the operating system outgrew the first disk it simply spilled onto the second: the one holding everyone's home directories. To make room, the system's own directories got replicated over there (this is the actual reason a Unix box to this day has both a /bin and a /usr/bin). When a third disk finally arrived, the humans were the ones asked to move: their directories were relocated onto it, mounted at a brand-new path called /home, so the system could have /usr all to itself. /home was born as an overflow lot — the place the people got shuffled off to when the machine wanted their space back.

Now look again at all those dot-prefixed files in /etc/skel, because their leading dot is an accident too — and a famous one. When early Unix grew its hierarchical directory structure, every directory gained two housekeeping entries: ., meaning "this directory," and .., meaning "the parent." To keep those two from cluttering every listing, ls was taught a shortcut — skip any name that starts with a dot. A side effect fell out of that shortcut for free: any file whose name began with a dot now also vanished from the default listing. People noticed, and started deliberately naming their configuration files .bashrc, .profile and the like, precisely to keep them out of the way. That is the entire reason your home directory is quietly full of dotfiles. As Rob Pike — who lived through the culture that grew up around it — has told the story, the dot-hiding was never a designed feature at all but a lazy simplification that then got cemented by a generation of programmers copying it. It's the commonly accepted origin, and the mechanism it rests on is plain in every ls to this day: a whole convention we all lean on, hatched as a side effect nobody meant to ship.

And that ~ from the top of the page? The C shell — an early Unix command interpreter written by Bill Joy at Berkeley in the late 1970s — is where the tilde-means-home shorthand was born. But why a tilde, of all the characters on the keyboard? Here the answer really does come down to a keyboard. Joy did his work on a Lear-Siegler ADM-3A — a "dumb terminal," the same model whose h, j, k, l keys had little arrows printed on them and thereby gave vi its cursor movement. On that keyboard, the ~ was not off on its own: it shared a single physical key with the word HOME (the key that jumped the cursor to the top-left corner of the screen). Home was, quite literally, printed on the tilde key. Whether Joy chose the character because of that label or whether it's just a coincidence too tidy to be true, nobody can prove either way — but there's a fair chance that every cd ~ you've ever typed is a small, unwitting echo of a legend printed on a terminal keyboard from the mid-1970s.

Underneath these stories is a quieter shift worth naming. The earliest Unix was a communal place — a handful of researchers sharing one machine, their homes sitting wide open together in /usr, everyone trusting everyone. /home, with its per-user walls and its 0700 doors, is Unix growing up into a world of strangers: first timeshared university machines, then servers with hundreds of accounts, then the flat assumption that the person in the next home directory is not your friend and has no business reading your files. The directory doesn't just store your data. It encodes a change in who Unix came to be for.

Cheat Sheet

# --- Look around ---
ls -l /home                       # who has an account
ls -ld /home /home/alice          # permissions: the street vs one house
echo ~                            # where your home is (tilde expands to it)
echo "$HOME"                      # the same thing, via the env var

# --- Is it a filesystem of its own? ---
df -h /home                       # size and usage
mount | grep -w /home             # a line = its own mount; nothing = part of /

# --- Space ---
du -sh /home/* 2>/dev/null | sort -rh | head   # biggest home directories

# --- The new-account starter kit ---
ls -la /etc/skel                  # files every new home is seeded with
cat /etc/default/useradd          # the defaults: HOME=/home, SKEL=/etc/skel

# --- Permissions ---
chmod 700 /home/alice             # lock a home to its owner (the default)
grep HOME_MODE /etc/login.defs    # the mode new homes are created with

# --- Create and remove (root only) ---
useradd -m alice                  # -m makes the home and seeds it from /etc/skel
userdel  alice                    # removes the account, LEAVES /home/alice behind
userdel -r alice                  # removes the account AND deletes the home