Linux Filesystem Hierarchy Explained — Windows to Linux Guide

What This Guide Achieves

If you are coming from Windows, the Linux directory structure can feel foreign. On Windows, you have C:\Program Files, C:\Users, and C:\Windows — three main places and that is basically it. On Linux, you open the file manager and see /usr, /etc, /var, /opt, /home, and a dozen other directories sitting at the root level. It looks overwhelming.

This guide maps every important Linux directory to its closest Windows equivalent so the layout makes immediate sense. By the end, you will know exactly where your apps, configs, and data live — and why Linux splits them up the way it does.

The Problem: Why Is Everything Scattered?

On Windows, when you install an application, nearly everything goes into one folder under C:\Program Files\AppName\. The executable, configuration files, shared libraries, documentation — all bundled together.

Linux takes a different approach. It follows the Filesystem Hierarchy Standard (FHS), which separates files by purpose rather than by application:

Executables go in one place (/usr/bin/)
Configuration goes in another (/etc/)
Shared data goes in yet another (/usr/share/)

This seems confusing at first, but it is actually more organized. Here is why:

All configs in one place. Need to back up every app’s settings? Copy /etc/ and ~/.config/. On Windows, you would have to hunt through dozens of Program Files subfolders and registry entries.
Clean separation of system vs user. Everything under /home/ belongs to you. Everything outside it belongs to the system. On Windows, user data and system data are intermingled across AppData, ProgramData, the Registry, and Program Files.
Easier administration. A sysadmin can lock down /usr/ (read-only) while leaving /home/ read-write. This is harder to do on Windows because app data and executables are co-located.

Think of it like a well-organized workshop: all the tools hang on one wall, all the materials sit on shelves, and all the blueprints go in a filing cabinet. You always know where to look.

The Directory Map: Linux vs Windows

This is the core reference. Bookmark this section.

Linux Location	Purpose	Windows Equivalent
`/usr/bin/`	System-wide application binaries (the actual programs you run)	`C:\Program Files\`
`/usr/share/`	System-wide application data, themes, icons, documentation	`C:\Program Files\` (data subfolders)
`/etc/`	System-wide configuration files (plain text, editable)	`C:\Windows\System32\` and the Registry
`~/.local/share/`	Per-user application data (icons, themes, fonts, app databases)	`C:\Users\You\AppData\Local\`
`~/.config/`	Per-user configuration files	`C:\Users\You\AppData\Roaming\`
`~/`	Your personal files (Documents, Downloads, Pictures, etc.)	`C:\Users\You\Documents\`
`/opt/`	Third-party standalone applications (self-contained installs)	`C:\Program Files\` (separate folder per app)
`/tmp/`	Temporary files (automatically cleared on reboot)	`C:\Windows\Temp\`
`/var/`	Variable data: logs, caches, databases, mail spools	`C:\Windows\Logs\` and `C:\ProgramData\`
`/boot/`	Boot loader files, Linux kernel images	`C:\Windows\Boot\`
`/home/`	All user home directories (`/home/alice/`, `/home/bob/`)	`C:\Users\`
`/mnt/` and `/media/`	Mounted drives, USB sticks, external disks	`D:\`, `E:\`, etc.

A few things to notice

The ~ shortcut. In Linux, ~ always means “my home directory.” If your username is alice, then ~ expands to /home/alice/. You will see this everywhere.
No drive letters. Linux does not use C:\ or D:\. Everything is part of one single directory tree starting at / (called “root”). External drives get mounted into the tree at /media/your-username/drive-name/.
Config files are plain text. Unlike the Windows Registry (a binary database), Linux stores configuration in readable text files. You can open /etc/hostname in any text editor to see your computer’s name. No regedit needed.

Where Software Gets Installed (by Method)

Different installation methods put files in different locations. This table shows you where to look depending on how you installed something.

Install Method	Binary Location	Data Location	Config Location
`apt install`	`/usr/bin/`	`/usr/share/`	`/etc/`
`.deb` download	`/usr/bin/`	`/usr/share/`	`/etc/`
`git clone` + `install.sh`	`~/.local/bin/` or `/usr/local/bin/`	`~/.local/share/`	`~/.config/`
Snap	`/snap/`	`/snap/`	`~/snap/`
Flatpak	`/var/lib/flatpak/`	`/var/lib/flatpak/`	`~/.var/app/`
AppImage	Wherever you put it	Self-contained	`~/.config/`
pip / npm (global)	`~/.local/bin/`	`~/.local/lib/`	`~/.config/`

What this means in practice

apt install is the cleanest. The system’s package manager tracks every file it installs. When you remove the package, it cleans up after itself. This is equivalent to using the Windows “Add or Remove Programs” feature, except it actually works reliably.
.deb files behave the same as apt install because they use the same underlying package system (dpkg). The .deb format is Linux’s equivalent of a .msi installer on Windows.
git clone builds are the messiest. You download source code, compile it, and run an install script. The files can end up in various places, and there is no uninstaller. This is like downloading a .zip from a website on Windows and manually extracting it.
Snaps and Flatpaks are sandboxed. They bundle everything the app needs into one package (similar to how macOS .app bundles work). The trade-off is they use more disk space.
AppImages are single-file executables. Download one file, make it executable, run it. Nothing gets installed system-wide. This is the closest thing to a Windows “portable app.”

The Home Directory Problem

Here is a real situation that catches new Linux users off guard. You open your home directory and find unexpected folders cluttering it up:

/home/you/
    auto-cpufreq/
    RcloneBrowser/
    javasharedresources/
    Documents/
    Downloads/
    Pictures/
    ...

Where did auto-cpufreq/, RcloneBrowser/, and javasharedresources/ come from? On Windows, random folders do not just appear in your user profile. On Linux, they sometimes do — and here is why.

Real examples and what they were

~/auto-cpufreq/ — A leftover build folder from running git clone followed by install.sh. The actual application was installed to /opt/auto-cpufreq/, so this source folder was no longer needed. Safe to delete.
~/RcloneBrowser/ — A build folder from compiling RcloneBrowser from source. The compiled binary was already installed to the system. Safe to delete.
~/javasharedresources/ — A cache directory created by the IBM OpenJ9 JVM. It stores ahead-of-time compiled classes. Safe to delete (it will be recreated if needed).

How to investigate unknown folders

When you find a folder in your home directory and you are not sure what it is, run these commands:

# Check if any installed package owns it
dpkg -S ~/folder-name 2>/dev/null

# Check if any process is currently using it
lsof +D ~/folder-name 2>/dev/null

# Check when it was last modified
stat ~/folder-name

Interpreting the results:

If dpkg -S returns nothing, no apt package owns that folder. It was created manually or by a build process, and it is likely safe to delete.
If lsof +D returns nothing, no running process is using it right now.
The stat output shows when the folder was created and last modified, which can help you remember what you were doing at that time.

Rule of thumb: If a folder in your home directory is not one of the standard ones (Documents, Downloads, Pictures, Music, Videos, Desktop, Templates, Public) and is not hidden (does not start with .), it is probably a leftover from something you built or installed manually. Investigate it, and if nothing needs it, delete it.

Important Hidden Directories

Your home directory contains many folders that start with a dot (.). These are hidden by default — you will not see them in the file manager unless you press Ctrl+H or run ls -la ~/ in the terminal.

These hidden directories are managed by applications and the system. Here are the important ones:

Hidden Directory	Purpose	Safe to Delete?
`~/.config/`	Application configuration files (settings, preferences, keybindings)	No — you will lose all your app settings
`~/.local/share/`	Application data (icons, themes, fonts, databases)	No — apps store important data here
`~/.cache/`	Application caches (thumbnails, downloaded data, build artifacts)	Yes — apps will rebuild their caches as needed
`~/.bashrc`	Your terminal/shell configuration (aliases, PATH, prompt style)	No — your terminal customizations live here
`~/.ssh/`	SSH keys for remote server access and Git authentication	No — losing these means losing access to servers
`~/.gnupg/`	GPG encryption keys for signing and encrypting files	No — losing these means losing your encryption keys

When you need disk space

If your home directory is getting full, ~/.cache/ is the safest place to reclaim space:

# See how much space .cache is using
du -sh ~/.cache/

# Clear it (apps will recreate what they need)
rm -rf ~/.cache/*

This is similar to clearing C:\Users\You\AppData\Local\Temp\ on Windows.

Clean Install Best Practices

Follow these rules to keep your Linux system tidy. These are lessons learned from real experience, not just theory.

1. Always prefer `apt install`

The system package manager is your best friend. It tracks every file, handles dependencies, and provides clean uninstallation. If a package is available through apt, use it.

# Search for a package
apt search package-name

# Install it
sudo apt install package-name

2. For `git clone` installs, use a staging directory

Never clone repositories directly into your home directory. Use a temporary staging area, install the software, then clean up:

# Create a staging area
mkdir -p ~/Downloads/staging

# Clone and install
cd ~/Downloads/staging
git clone https://github.com/somedev/some-app.git
cd some-app
./install.sh

# Clean up — the app is installed, the source is no longer needed
cd ~ && rm -rf ~/Downloads/staging/some-app

This prevents the “mystery folder in home directory” problem described above.

3. Use `apt install ./package.deb` instead of `dpkg -i`

When you download a .deb file from a website, install it with apt, not dpkg:

# Good — automatically installs missing dependencies
sudo apt install ./package.deb

# Avoid — will fail if dependencies are missing
sudo dpkg -i package.deb

The apt method resolves and installs any missing dependencies automatically. The dpkg method does not, and you will end up with a broken install that requires running sudo apt --fix-broken install afterward.

4. Never use `sudo npm install -g`

Installing Node.js packages globally with sudo writes files as root into system directories, which creates permission conflicts later. Instead:

# Bad — causes permission issues
sudo npm install -g some-package

# Good — installs to your home directory
npm install -g some-package  # (after configuring npm prefix to ~/.local)

If npm install -g fails without sudo, configure npm to use a local prefix:

npm config set prefix '~/.local'

5. Verify installation location

After installing software from source, confirm the binary is in your system PATH:

# Shows where the binary was installed
which app-name

# Shows all matching binaries (if there are duplicates)
which -a app-name

If which returns nothing, the binary is not in your PATH and you will not be able to run it by name.

6. Delete build folders after installation

Once software is installed, the source code and build artifacts are no longer needed. Delete them to keep your system clean. The installed binary is independent of the build folder — removing the source will not break anything.

Quick Reference: Where Do I Look?

When you need to find something, use this cheat sheet:

I want to…	Look in…
Find an app’s executable	`/usr/bin/`, `/usr/local/bin/`, or `~/.local/bin/`
Edit an app’s system-wide config	`/etc/`
Edit an app’s personal config	`~/.config/`
Find where an app stores my data	`~/.local/share/`
Find system logs	`/var/log/`
Find where my USB drive mounted	`/media/your-username/`
Find temporary files	`/tmp/`
Reclaim disk space	`~/.cache/` and `/tmp/`

Summary

The Linux filesystem is not random — it is methodical. Once you understand that files are organized by purpose (binaries, configs, data, logs) rather than by application, the whole structure clicks into place.

Coming from Windows, the single most important shift in thinking is this: there is no C:\Program Files\AppName\ that holds everything. Instead, the app’s binary goes in one standard location, its config goes in another, and its data goes in a third. Every app follows the same pattern, which means you always know where to look.

Stick with apt install whenever possible, use staging directories for source builds, and your system will stay clean and predictable.

What to Expect — The Windows-to-Linux mental model shift
Package Management Basics — How software gets installed on Linux
Windows to Linux Glossary — Terminology mapping