Overview of Root Directories on Linux Mint

/home

The home directory, often abbreviated as a tilde (~), is where user-owned files are located. Every user in the system that has a home directory, with exception of the root user, has its own subdirectory in /home.

For example, if we have two users, john and mary, then there will be a /home/john and a /home/mary.

Privacy: it's not possible for an arbitrary program executed by john to look inside /home/mary by default since john wouldn't have permission to access /home/mary. HOWEVER, it's possible for any program to look inside /home itself. This means any program that is run by john can tell that there is a user called mary in the same system because there is a folder called /home/mary.

• What Read, Write, and Execute Permissions Mean on Linux

If you are new to Linux, keep in mind that you generally don't have any reason to ever, ever, do anything, at all, with any folder or file that isn't contained within your home directory.

This means you'll never need to leave /home to touch things on /bin or elsewhere. That's because most of the files elsewhere on the system are owned by root, so in order to edit or add files you'll need sudo. To make user-level customizations, you pretty much never need sudo, as every decent program that looks somewhere in the system for a file or for settings will also look into your home directory to allow users to customize the program without having to touch root-owned files.

For example, Linux Mint's Cinnamon themes are found in two places: in /usr/share/themes, which is root-owned, and in ~/.themes, which is not root-owned. In order to install a theme in the system (in /usr/share/themes), you need root, but to install it in your user, you can just copy and paste the files in ~/.themes in your home folder. This folder isn't visible by default in Nemo because it's a dotfile, so you need to show hidden files in order to see it, but the folder is yours and you can do whatever you want with it without leaving your home directory.

For most programs, you'll see that you can find user-level settings in ~/.config, and even MOTD, which usually is set on /etc/motd, root-owned, can be set per-user by simply editing your ~/.bashrc file.

• How to Display a Message Every Time You Open the Terminal on Linux (Bash)

/media

The /media is where user-mounted media, such as USB sticks, HDDs, SSDs, etc. is found. On Windows, HDDs and SSDs are mounted by default, and portable media can be unmounted. On Linux Mint, you may be surprised to realize that you can mount and unmount HDDs and SSDs as if they were USB sticks.

Media mounted in this way is owned by the user. More specifically, the mount point is inside a subdirectory in /media that is owned by the user, e.g. /media/john/my-ssd (on Windows, this might be equivalent to the drive letter D:\ for example).

This leads to the annoying problem that if you mount an SSD from one user and switch to another user, you get cryptic errors because Nemo can't handle the fact that there are two users in a system. For example, if you are logged in as mary, you can see that a /media/john directory exists, but you can't actually look inside of it, so you can't access my-ssd, and you can't unmount from another user either, so you'll need to switch back to the previous user, unmount it, switch back, and then you can mount it. Nemo won't let you mount the same device by two users at the same time. It's really weird, to be honest.

/mnt

The /mnt directory is similar to /media in that it's used to mount disks. The difference between /media and /mnt seems to be simply that Nemo doesn't mount anything to this directory by default.

There seems to be some theoretical differences according to the standard, e.g. /media for portable disks, /mnt for temporary mounts, but seeing that this appears to make no real difference in practice, let's ignore it completely for now.

The real difference in practice as far as Linux Mint is concerned is that Nemo will create /media/(user) directories but it won't touch /mnt, so you can use /mnt for administrator level mounts. For example, if you open your Disks app through the start menu and carefully navigate through context menus full of items that will destroy all your data, you can find an option to automatically mount a disk on start up, and you could for example make it mount to /mnt/my-ssd, and it would be accessible to all users without having to mount it yourself every single time, and without running into any access permission problems.

/cdrom

The /cdrom directory is probably a mount point for a CD-ROM, which is a large, circular, flat USB stick. Why is this directory here? It's a mystery. I have no idea. Nobody else seems to know either. Nobody is touching it for fear it may render the entire distro unoperable. It's a load-bearing CD-ROM! Jokes aside, it seems this directory exists on Ubuntu, so it's also on Linux Mint which is based on Ubuntu, and it seems /cdrom, just like /floppy (a rectangular, flat USB stick), were mount points for their respective media by convention.

Like the `/floppy' directory, the use of the `/cdrom' directory is a standard practice and convenient, but not necessary -- you can mount disks in whatever empty directory you like. (You could even, for example, mount discs from the CD-ROM drive to `/floppy' and mount floppy disks to `/cdrom', but why would anyone do that!)

https://dsl.org/cookbook/cookbook_31.html#SEC427 (accessed 2025-07-08)

I can't test this since I don't have a CD-ROM, or a CD drive, but I have a feeling that even if you do mount a CD, specially through Nemo, it will just get mounted on /media instead of on /cdrom.

/dev

The /dev directory contains "files" associated to all your devices, to all hardware your system knows about.

Note: technically the "files" here aren't normal files. For example, if you use the ls command, you'll see that they all show in yellow, which is pretty neat, denoting their distinctive type.

/dev/nvme

If you have an NVMe SSD, you probably have /dev/nvme0, which is its file. When mounting a device such as this, or more specifically, a partition of the device, you may encounter a filepath from /dev that indicates which partition you are mounting, e.g. /dev/nvme0n1p2.

/dev/sda

Other devices of note are /dev/sda, /dev/sdb, etc., which are SATA-connected drives.

/dev/nvidia

If you have an Nvidia GPU, you'll have a /dev/nvidia0 file, and so on.

/dev/null

Among these devices a particularly unique one is /dev/null. Anything written to /dev/null is discarded, and reading /dev/null results in an empty file.

$ echo "Hello, world." > /tmp/world
$ cat /tmp/world
Hello, world.
$ echo "Hello, void." > /dev/null
$ cat /dev/null
$ 

/dev/tty

Then we have /dev/tty. The TTY stands for teletypewriter. I guess at some point it might have meant the physical ones connected to a single computer, but nowadays TTY means a virtual teletypewriter. Every user on Linux is logged in through a TTY. I believe on Linux Mint you are on TTY number 7 by default. I don't know why. A single user may be logged in through multiple TTY's simultaneously, so "TTY" is kind of like a "virtual console" or "user session" kind of thing.

Warning: if you press Ctrl+Alt+F1, you switch to the 1st TTY, Ctrl+Alt+F2 to the 2nd, and so on. In practice, it will turn your screen black and you'll be asked for username and password, but after logging in you won't see Cinnamon, you'll just see the terminal. If this ever happens to you, F7 probably gets you back to the default TTY 7 where Cinnamon is running.

/tmp

The /tmp directory is the temporary directory on Linux Mint. All files in this directory are deleted when the system restarts.

The /tmp directory is used by programs that need to create temporary files. The main reason to need a "temporary file" is if a program must save something to disk that it wants to delete later, but may not necessarily be able to.

For instance, let's say that an application lets you do something with a file or with a URL. For practical reasons, instead of having two different ways to handle opening a file and a URL, it's easier for the program to simply download the URL and save it as a temporary file and then open the temporary file as if it was a normal file. The problem is that because the program created the file, it occupies space in disk until it's deleted, and the only one who knows where the file is located is the program. Even if the program was programmed to automatically delete the files it created when you close it, that subprogram wouldn't be executed if the program unexpectedly terminated (crashed), and then the next time you ran the program it may not be able to remember where it saved its temporary files.

To get rid of the complexity with this sort of problem, operating systems have a temporary directory where programs can just throw files and forget about them, knowing that when the operating system restarts those files will be gone. After all, you are going to restart your computer one day, right? Nobody just... keeps their PC running for hundreds of days without turning it off. That would be weird.

/run

The /run directory is for temporary files, similar to /tmp, except that /tmp is publicly writable while /run is not. This means that any user can create a file in /tmp, but only programs run by root can create files in /run.

$ echo "Hello, world." > /run/world
bash: /run/world: Permission denied

/run stands for "runtime," which is that period of time in which the programs are running.

3.15. /run : Run-time variable data

3.15.1. Purpose

This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process.

The purposes of this directory were once served by /var/run. In general, programs may continue to use /var/run to fulfill the requirements set out for /run for the purposes of backwards compatibility. Programs which have migrated to use /run should cease their usage of /var/run, except as noted in the section on /var/run.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html (accessed 2025-07-08)

/etc

The /etc directory contains system-level configuration files.

Here lies /etc/motd (message of the day), /etc/hosts (lets you overwrite the IP address of a domain name), /etc/passwd (contains all users on your system), among several other files that you should probably never touch in your lifetime.

I'm serious, you should never touch any of these if you can avoid it, and you can often avoid it.

For example, there are several terminal commands you can use to edit /etc/passwd without editing it with a text editor, and you don't even need to use those commands because you have a GUI to add and remove users on Linux Mint. Similarly, you don't really need to edit /etc/fstab just to mount a disk on system start up system you can do that from the Disks app.

In essence, you may encounter many tutorials that say you have to edit /etc on Linux, and they are probably right for Linux in general, but not Linux Mint.

/bin

The /bin directory contains programs installed on the operating system.

Presumably, the word bin stands for "binary," and it stems from the idea that you have the source code of a program, and the source code is compiled into binary code (machine code). Files containing such binary code are also called "binaries." On Windows, these would be .exe files. On Linux, the native executable format is the ELF format, however, do note that usually these executables don't have a file extension (e.g. .elf) as they do on Windows.

On Linux Mint, /bin is a symlink to /usr/bin. On systems where these two directories are "merged" in this way, we may find a folder called /bin.usr-is-merged that indicates this. We'll understand why later.

Files in /bin and /usr/bin are searched by shells on Linux such as Bash to resolve the zeroth argument in the command line. For example, if you type the command date, the program that gets executed is located in /usr/bin/date.

• What Values can the Zeroth Argument Have? (in the Command-Line)

That's essentially the primary purpose of /bin. If you want to make a program available for all users on a system, you put it in /bin. You don't need to put the program itself there, since you can simply put a symlink to it.

Some symlinks on /bin are actually aliases to other files in /bin. For example, if a program wants to run python3, this could be any version of Python 3, e.g. Python 3.11, 3.12, 3.13, etc. So we can have /bin/python3 be a symlink to /bin/python3.12, which is the specific version that is actually installed in the system.

/sbin

The /sbin directory contains essential system binaries. Specifically, these are binaries you can use to recover your system even if /bin is somehow inaccessible or broken.

/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.[18]

[18] Originally, /sbin binaries were kept in /etc.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html (accessed 2025-07-08)

On Linux Mint, /sbin is a symlink to /usr/sbin, as indicated by /sbin.usr-is-merged.

/lib

The /lib directory is where most of the program files are actually installed.

Presumably, it stands for "library." A code library is a file containing programs that are used by other programs. The key difference is that an executable file has an "entry point" (e.g. main()) which is the subprogram that is run when the file is executed, while a library has no entry point so it can't be executed, at least not without specifying which subprogram contained in it should be run. On Windows, libraries typically have the .dll extension (Dynamically Linked Library), but on Linux they have the .so extension (Shared Object).

On Linux Mint, /lib is a symlink to /usr/lib, and we have /lib.usr-is-merge to indicate that.

The key difference between /bin and /lib is that /bin only contains executable files, while /lib is filled with subdirectories. For example, we have /bin/python3, which is an executable file, and /lib/python3, which is a directory. In this directory, you can find a dist-packages subdirectory containing all sorts of Python packages accessible only through Python. This means that in /bin we have a binary that will load its related data found in /lib. /bin is just a list of executable files available in the system. /lib is where their data actually resides in full.

/lib32, /lib64

The /lib32 and /lib64 directories are the same thing as /lib but only used for 32-bit or 64-bit libraries, respectively.

/usr

The /usr directory has a bit of history. Originally, user files were placed in this directory, hence the name, but that's because at the time there was so little storage that /bin and /usr where on separate disks. As /bin became too large, binaries started being stored in the /usr, and then user files were moved to a third disk, mounted on /home.

You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one, which is where all the
user home directories lived (which is why the mount was called /usr). They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp…) and
wrote files to those new directories because their original disk was out of
space. When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

Of course they made rules about "when the system first boots, it has to come up
enough to be able to mount the second disk on /usr, so don't put things like
the mount command /usr/bin or we'll have a chicken and egg problem bringing
the system up." Fairly straightforward. Also fairly specific to v6 unix of 35
years ago.

Rob Landley, "Thu Dec 9 15:45:39 UTC 2010" [https://lists.busybox.net/pipermail/busybox/2010-December/074114.html] (accessed 2025-07-08)

Although this was practical at the time, it led to a fragmentation problem on Linux where each distribution had a different configuration, some had both /bin and /usr/bin, some didn't, some had some directories replicated but not all, some had different rules for one and for the other, etc. As a consequence, this created incompatibilities across distros because the root directories behaved differently and it was hard to keep track of all these nuances.

This led to a push to merge /bin and /lib with /usr/bin and /usr/lib, so everything worked the same on every desktop Linux, improving compatibility across them.

Fedora (and other distributions) have finished work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ (accessed 2025-07-08)

The important thing to understand is that although /usr's name comes from "user," it isn't actually a user directory. It's a root-owned system directory and it doesn't contain any user files on Linux Mint today.

Fun fact: the /usr directory is a very funny one, because new 2020's Linux users will think /usr is a user directory, and they'll be corrected by experienced 2000's users that will tell them /usr isn't actually a user directory, it stands for "UNIX System Resources" or something like that, but then a mysterious graybeard will manifest out of thin air and say: actually, that's a backronym, because when I was programming in the 80's...

Thanks to the merge, /usr contains practically all data of your applications and programs on Linux Mint. /usr/bin contains the executable files, /usr/lib contains the rest of the programs, and then we have a couple more subdirectories.

/usr/include

The /usr/include subdirectory contains headers that can be included in C and C++ programs through the #include preprocessor directive. It's completely irrelevant to anyone who doesn't program C or C++.

What it means is that if you have C code like this:

#include <cairo/cairo.h>

The compiler will find the header file in /usr/include/cairo/cairo.h if /usr/include is in its search path, which may or may not be. In any case, it's nice to have a standard system location for this sort of thing.

Presumably, the reason why C gets special treatment compared to other programming languages is because Linux is programmed in C, as are many low-level programs. Had they rewritten everything to Rust (or Zig), we probably wouldn't have this directory.

/usr/share

The /usr/share directory contains data loaded by programs such as images, audio, and other resources. This is where you'll find icons and cursors, for example. It's also where translations are found. Translations are often text files that map an English phrase to its translation in another language.

Essentially everything that belongs to a program that isn't related to its algorithm is located here. That's because if something is an algorithm to be executed by a CPU, then it must be compiled to its specific CPU architecture, such as 32 bit (x86), 64 bit (x64), ARM, etc.

The /usr/share hierarchy is for all read-only architecture independent data files[30]

[30] Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html#ftn.idm236091847456 (accessed 2025-07-08)

/usr/local

The /usr/local directory contains the same hierarchy as /usr and may be used to install software that won't be modified by the system. Essentially, it's a way to bypass the package manager. If you have something in /usr/local/bin, it's included in the search path by default by the shell just like /usr/bin and /bin, but the package manager only modifies files in /usr/bin. This means that if you copy /bin/python3 to /usr/local/bin/python3, even if the package manager modifies /bin/python3, it won't touch your "local" copy of python3.

It's important to note that /usr/local is a root-owned directory, so the only person that can modify this is an administrator, and any modifications apply to all users. In general there is no reason at all to do this since, again, a much simpler solution is to do this at user-level by modifying the $PATH variable from .bashrc to include a user-owned directory in the search path, e.g. you could make Bash search ~/actual-usr/bin. You can also use aliases in Bash which do the same thing.

Honestly, I have no idea why would you ever need this, but it's an escape hatch, so I'm pretty sure it's extremely useful if you ever need it.

In general, /usr/local will be empty since it only contains files that are manually installed by the system administrator. However, on Linux Mint in particular, it's not empty by default, which is kind of surprising.

[...] this is done as it is a way to override programs already present in /usr/bin and giving a customized experience on Linux Mint. For the Linux Mint Main Edition many packages come from the Ubuntu package base. Those packages will install files into /usr/bin, and overwrite those files on any upgrades to those packages. Hence the option is to either totally replace those packages, and configure APT to not install those from the Ubuntu package base, or much simpler and less error prone is to just put the customization that is needed for Linux Mint in /usr/bin/local. Putting those in /usr/bin isn't an option as it would be overwritten by any upgrade to the packages from the Ubuntu package base. Using another name isn't an option either as other programs use these specific names (like yelp, for the GNOME help system).

https://forums.linuxmint.com/viewtopic.php?p=734656&sid=0032d2a9f140123d357de6816de0fa06#p734656 (accessed 2025-07-08)

Again, it's generally possible to customize something related to this directory from your home directory.

For example, /usr/share/fonts or /usr/share/local/fonts may be searched to find the fonts installed on your system. Since /usr/share/fonts is handled by the package manager, to install new fonts manually you would use the local subtree as the system adminstrator. However, you don't actually need to do that, because you can just place them in ~/.local/share/fonts instead, in your home directory, and then you don't need root.

Unfortunately, Linux Mint doesn't come with a font manager installed by default, which is sad shortcoming in my opinion. Look, I just want to install a font. I shouldn't need a tutorial that tells me to mess with this arcane and byzantine file system structure, and require a sudoer password, just to install a font.

• I Can't Install Fonts in Linux Mint because There's No Font Manager

/opt

The /opt directory contains software that isn't handled by the package manager but instead installed by the system administrator. It's essentially the same thing as /usr/local, except that /usr/local has the standard UNIX root subtree bin, lib, share in it, while /opt comes with none of that.

In practice, /opt is similar to Program Files on Windows. For example, Google Chrome installs itself in /opt/google/chrome, and DaVinci Resolve in /opt/resolve. These two applications aren't available for installation through the package manager on Linux Mint, so they can't be installed on /usr/bin.

Note that you still need root access to install applications in /opt. Notably, if you install games through Steam, they aren't installed in /opt, but in ~/.local/share/steam/steamapps/common by default. This doesn't even make sense, to be honest, since we already know share is for architecture-independent binaries, so I feel like the game binaries should be placed in ~/.local/lib instead, but who cares about this stuff, I just want to install a game.

/var

The /var directory is for variable files. Variable in this case means the files can be modified, although it's a bit more complicated than that.

/tmp and /run store temporary data that can change. This data will be erased when the system restarts, so theoretically it doesn't even need to be stored in the disk, you could keep it in the RAM, provided that you have enough RAM. Meanwhile, /var stores permanent data that can change, so it must be stored in disk. This data includes, for example, logs stored in /var/log. The logs aren't deleted when you restart the system, so this makes sense.

Because all variable data is stored separately from /usr, it allows a Linux system to have /usr be read-only. In other words, unless we are updating system packages through the package manager, none of the files in /usr should EVER change, because all the files that CAN change are stored in /var.

In fact, because these files can't change anyway, it should even be possible to put the files of /usr in read-only memory (ROM), a piece of hardware that physically can't be modified at all. This doesn't sound very secure for anything that connects to the Internet since you can't update any security vulnerabilities or bugs you find, but it's technically possible.

Another thing that should be technically possible is to have multiple Linuxes running simultaneously on a single computer that all use the same /usr files on a piece of hardware. So long as you mount /usr as read-only, one Linux can't mess with the files that are also used by the other Linuxes.

/var/www

The /var/www directory is used by the Apache HTTP web server to serve files to the web.

When I started using Linux, I thought the location of this was incredibly odd, because I just wanted to have something running on localhost, so I'd hoped I could just put something in my home directory. Turns out there was a reason for its location. I still don't like it, though!

/srv

The /srv directory is for services, specially of systems running as servers. For example, you may have HTML files served by web server in /srv/www instead of /var/www.

SuSE was one of the first disto's that I used that kept webroot's in /srv - typically Debian/Ubuntu/RHEL use /var/www

https://serverfault.com/a/124129 (accessed 2025-07-08)

/root

The /root directory is root's home directory. If you run any program as root that reads or writes configuration files to ~/.config, it will save them in root's home directory.

In particular, you can modify /root/.bashrc to print "I'm root" as the shell prompt every time before a command so you can tell users apart, although this is only useful if you use su instead of sudo.

/boot

The /boot directory contains files necessary to boot the system, and it may include GRUB, for example. Without this, Linux won't boot, since this is where Linux is.

/sys

The /sys directory is related to the Linux kernel itself. Like /boot, you have as much business with this as you have with C:\Windows, which is no business at all.

The sys filesystem is the location where information about devices, drivers, and some kernel features is exposed.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch06.html#sysKernelAndSystemInformation (accessed 2025-07-08)

/proc

The /proc directory contains process information. A "process" is a running program. You will find many numbered folders in /proc. The number is the respective numeric ID for the process, i.e. the Process ID, or PID.

Fun fact: in /proc/1/cmdline you can find the command used to run the first process that starts the entire system, which on Linux mint is /sbin/init splash. It shows as /sbin/initsplash if you cat it because it uses a special character to separate arguments. The special character seems to be the null character (it shows as ^@ in Neovim).

/lost+found

This /lost+found directory isn't actually part of Linux Mint but of the ext4 format. You can tell how special it is because it has a "plus" (+) in its name. Don't think I've ever seen that before.

If your operating system finds any inodes that don't have hardlinks, it can try to recover those inodes by creating a hardlink inside the /lost+found directory. In other words, if it finds any files (inodes) that aren't listed in any directories, i.e. that aren't pointed to by any filepath (hardlink), then it creates a filepath for them (a hardlink), and this hardlink is placed inside the /lost+found directory.

This can occur if the filesystem has become corrupted somehow, e.g. if the hardlink was removed but the inode wasn't deleted, or, conversely, if the directory inode where the list of hardlinks is found is in a faulty sector of the hardware.

The ext4 filesystem doesn't keep track of the hardlinks of an inode. You can tell how many hardlinks there are because the references are counted, but not where they are exactly. This means that in order to check if the entire filesystem makes sense and the numbers add up, you need to scan all files to make sure that every inode has the number of references it says it has.

In other words, /lost+found is used if you use a tool to check the integrity of the file system such as fsck.

• How Hard Links and Inodes Work on Linux