A Walk Through Ubuntu's Directory Layout

Ubuntu looks tidy on the desktop, but underneath the file manager sits a sprawling tree of folders that quietly organise everything your computer does. Australians tinkering with Linux on a home server, a media box in the shed, or a work laptop in a Melbourne coworking space quickly bump into folders like /etc, /var, and /home. Knowing what lives where turns guesswork into confidence and prevents the kind of accidental deletions that can ruin a long arvo spent configuring a system.

The layout follows the Filesystem Hierarchy Standard, a long-running convention shared by most Linux distributions. Ubuntu inherits this skeleton from Debian and adds a few of its own conventions on top, such as snaps living under /snap and the use of systemd paths. Once you grasp the logic, the same knowledge transfers to a fresh install of Linux Mint, Pop!_OS, or a server running in a Brisbane data centre.

You'll often hear people describe the layout as a single inverted tree that starts at /, pronounced "slash" or "the root directory." Everything else branches downward from there, including external drives and network shares that get grafted onto empty branches at mount points. This guide walks through the major branches an everyday user actually visits, explaining what each one stores and when you might poke around inside it.

The Roots of the Filesystem Hierarchy Standard

The current arrangement owes a great deal to decisions made back in the 1990s, when Linux distributors wanted one predictable place to find every binary, library, and configuration file. The result is the Filesystem Hierarchy Standard, or FHS, which draws a careful line between files that the system uses to run and files that are merely data the system manages. Understanding that distinction helps Australian sysadmins and home tinkerers alike, especially when running Ubuntu on hardware far from any support technician, perhaps in a regional practice in Mildura or a remote research station in the Pilbara.

Files that the operating system needs to boot and to repair itself sit near the top of the tree. /bin and /sbin hold essential programs, while /lib collects the shared libraries those programs depend on. /boot stores the kernel and the initial RAM disk, the small bundle of drivers that load before the rest of the system wakes up. None of these are places a typical user ever modifies, which is precisely the point: keeping them separate makes recovery simpler when something else goes wrong.

A handful of virtual folders round out the root. /dev exposes every piece of hardware as a file, /proc and /sys offer a window into running processes and kernel settings, and /run holds volatile data created since the last boot. They look like ordinary folders in a file manager, yet they live entirely in memory. Treat them as read-only unless an explicit guide, like a how-to-set-up-a-personal-cloud-with-nextcloud-on-ubuntu tutorial, tells you otherwise.

Where Your Personal Work Lives Under /home

For most people, /home is the folder that actually matters day to day. Each user gets a subdirectory named after their account, so a person signed in as harriet finds their files in /home/harriet. This separation is what lets a family in Adelaide share one desktop PC with separate logins for parents and kids, or lets a contractor hop between machines and keep their own documents, SSH keys, and shell history intact.

Inside that personal folder, Ubuntu drops a stack of hidden directories beginning with a dot. These are configuration files for individual programs: .config stores settings for most graphical apps, .local holds user-installed extras, and .cache keeps temporary data that apps can rebuild on demand. A .ssh folder quietly guards your login keys, which becomes important when you start managing a remote box over a flaky NBN satellite link in the Kimberley and cannot afford to lock yourself out by accident.

Knowing the difference between the visible and hidden parts of /home pays off when you back up. A quick tar of the whole user folder captures far more than just the documents on the desktop, including browser profiles, GnuPG keys, and dotfiles that customise the shell. Many Australian homelab builders copy /home to an external drive regularly, then keep a separate image of the system itself for the rare occasions a disk fails.

System Settings Gathered in /etc

Every configuration file that affects all users tends to land in /etc. Network interface names, hostname, time zone, the list of users allowed to use sudo, the rules for the firewall, and the schedule for routine maintenance tasks all live here as plain text. Editing these files directly with sudo nano /etc/hostname is a rite of passage, and a useful skill when remoting into a server from a café in Surry Hills and the GUI is hours away.

Ubuntu leans heavily on /etc for things that other systems might scatter elsewhere. The package manager keeps its sources list in /etc/apt/sources.list, the default printer configuration sits in /etc/cups, and the login manager reads display setup from /etc/X11. A whole folder called /etc/nginx can appear the moment you install the popular web server, full of ready-made snippets that turn the box into a small static site or a reverse proxy in front of a self-hosted Nextcloud instance.

Because /etc governs the machine rather than the person using it, backups here matter even more than backups of personal files. A single corrupted fstab can stop a system from booting, and a misconfigured sudoers file can lock everyone out. Version-controlling /etc with a private Git repository has become a popular habit among Australian sysadmins, since it gives a clear history of every change and an easy way to roll back a botched edit.

Logs and Spooled Data Under /var

Anything the system generates while running, but that should survive a reboot, settles under /var. This is where log files pile up at /var/log, where mail queues wait at /var/spool, and where the package manager stashes downloaded .deb files before installing them. When something misbehaves on a workstation in a Perth engineering firm, the very first stop is usually journalctl or /var/log/syslog.

Log rotation is built in, so folders under /var/log rarely grow out of control on a healthy machine. Still, a desktop that has been running for years without updates can accumulate surprising amounts of cached data, and /var/cache/apt is often the biggest culprit. Freeing a few gigabytes with sudo apt clean is a quick win that many an Australian Linux user has rediscovered when their / partition suddenly fills up during an upgrade.

Databases also live here by default. MySQL or PostgreSQL typically write into /var/lib, which means a full backup of /var along with /etc and /home captures nearly everything needed to rebuild a working system. Container and virtual machine images stored under /var/lib/libvirt or /var/lib/docker can balloon quickly, so it pays to keep an eye on the size of this branch if your homelab doubles as a testing ground for cloud projects.

Where Programs and Add-Ons Reside in /usr and /opt

The vast majority of software on a typical Ubuntu install lives under /usr. Once upon a time, /usr stood for "Unix System Resources," but today it behaves like the main programme directory: compiled binaries in /usr/bin, shared libraries in /usr/lib, architecture-independent data in /usr/share, and header files for developers in /usr/include. Locally installed tools traditionally land in /usr/local, leaving a clean separation between what the distribution provides and what an administrator adds by hand.

Third-party software that does not follow standard Linux packaging tends to settle in /opt. Vendor bundles such as Google Chrome, Zoom, or proprietary CAD packages often unpack into their own self-contained subtree like /opt/google/chrome. This makes them simple to remove in one go and reduces the risk of stray files littering the main hierarchy. Snap packages, by contrast, mount their own read-only filesystems under /snap and appear as if by magic when a user installs them.

A handy rule of thumb is to look in /usr/bin for anything supplied by Ubuntu's repositories, in /usr/local/bin for anything a sysadmin has compiled or scripted for the whole machine, and in /opt or /snap for vendor downloads. Together, those three locations cover almost every command a user types into the terminal. Knowing the difference saves time when a script fails because a tool is installed in the wrong place.

Mount Points, Temporary Space, and the Edges of the Tree

A few branches of the tree act as docking stations rather than permanent homes. /mnt is the conventional scratch space for temporarily mounting a filesystem, often used while diagnosing a disk that won't boot. /media is where Ubuntu automatically mounts removable drives, so popping in a USB stick usually drops a label like "JANE'S BACKUP" into the sidebar of the file manager. Persistent external drives configured through /etc/fstab can also be grafted anywhere an empty folder exists, a common trick for attaching a big photo library to a home server.

/tmp is the place for temporary files. Most programs clean up after themselves, but a few leave behind hefty leftovers, and /tmp is wiped at reboot on most modern Ubuntu installs. /srv is reserved for data served over the network, so a self-hosted Minecraft world or an FTP archive ends up here by convention rather than under /home. /lost+found appears only when a filesystem check has recovered orphaned chunks, and is best left alone unless a disk has clearly had a bad day.

With that map in mind, the simplest way to internalise it is to see it for yourself. Open a terminal this evening and run tree -L 2 / after installing the tree package with sudo apt install tree, then prune the output with sudo tree -L 2 / -I 'proc|sys|run|dev'. The result is a compact picture of every folder covered above, sitting right there on your own machine.