What Is the File System Hierarchy in Kali Linux?
The file system hierarchy in Kali Linux organizes files and directories under the root directory (/). Key directories like /bin, /etc, /home, and /var serve specific purposes, from storing system binaries to user data and logs. Understanding this structure helps users navigate, secure, and maintain their systems effectively.
Quick answer: Kali Linux follows the Filesystem Hierarchy Standard, so everything hangs off one root directory, /. Configuration lives in /etc, user files in /home, logs in /var/log, programs in /usr, devices in /dev, and boot files in /boot. Kali's pentest tools and wordlists sit mostly under /usr/share.
Key takeaways
- Linux has no drive letters. Every disk, USB stick and virtual file is mounted somewhere under
/. - The layout is the same as Debian, because Kali is built on Debian. If you know one, you know the other.
- Kali-specific material (wordlists, Nmap scripts, Metasploit) lives under
/usr/share, and your own work belongs in your home directory. - On current Kali,
/bin,/sbinand/libare symbolic links into/usr. Runls -l /to see it.
What is the Filesystem Hierarchy Standard?
The Filesystem Hierarchy Standard (FHS) is an agreed layout for Linux directories, so that software and administrators know where to look. It is published by the Linux Foundation at refspecs.linuxfoundation.org. Kali follows it through its Debian base, with a few extra locations for security tools.
The top of the tree is the root directory, written /. Do not confuse it with /root, which is the home directory of the root user.
The directories you will actually use
| Directory | What it holds | Example on Kali |
|---|---|---|
/etc | System and service configuration, plain text | /etc/passwd, /etc/ssh/sshd_config, /etc/apt/sources.list |
/home | One folder per normal user | /home/kali |
/root | Home of the root user | Root's shell history and config |
/var | Data that changes: logs, caches, spools | /var/log/auth.log, /var/log/apache2 |
/usr | Installed programs, libraries, shared data | /usr/bin/nmap, /usr/share/wordlists |
/opt | Self-contained third-party software | Tools installed by hand |
/tmp | Temporary files, may be cleared on reboot | Scratch output from tools |
/dev | Device files for hardware | /dev/sda, /dev/null |
/proc, /sys | Virtual views of processes and kernel | /proc/cpuinfo, /proc/meminfo |
/boot | Kernel, initramfs, bootloader files | vmlinuz-*, grub/ |
/mnt, /media | Mount points: manual and automatic | A USB stick appears under /media |
/run | Runtime state since boot, such as PID files | /run/user/1000 |
/srv | Data served by this machine | Web or FTP content, if you choose to use it |
Binaries and libraries: /bin, /sbin, /lib and the /usr merge
The original FHS split commands between /bin and /sbin (needed early in boot) and /usr/bin and /usr/sbin (everything else). Modern Debian-based systems, Kali included, have merged them. /bin, /sbin and /lib are now symbolic links to their /usr counterparts. You can confirm it yourself:
ls -l / | head -20
# lrwxrwxrwx... bin -> usr/bin
In practice, nothing changes for you. Commands still work from either path. It matters when you read an older tutorial that says /sbin holds admin tools, because that is now only a convention.
Where Kali keeps its security tools and wordlists
Kali's tools are ordinary packages, so their binaries go to /usr/bin and their support files to /usr/share. A few places are worth memorising:
/usr/share/wordlistsholds wordlists such asrockyou.txt.gz, which you must decompress before use./usr/share/nmap/scriptsholds the Nmap Scripting Engine scripts./usr/share/metasploit-frameworkholds Metasploit modules./usr/share/seclistsappears if you install theseclistspackage.- Your own notes, captures and scripts should live under
/home/<user>, not under system directories.
Package contents under /usr can be overwritten by updates. Keep anything you want to keep in your home directory.
Commands to explore the tree
ls -l / # top level, shows symlinks
tree -L 1 / # one-level overview (sudo apt install tree)
df -h # mounted filesystems and free space
du -sh /var/log # how big are the logs
findmnt # what is mounted where
file /bin # confirm it is a symlink
which nmap # where a command lives
dpkg -L nmap | head # files a package installed
Permissions and safety
- Recent Kali releases log you in as a normal user by default. Use
sudoonly when needed. - Be careful with recursive commands as root, especially
rm -rfandchmod -Rnear/,/etcor/usr. /etcis where mistakes break services. Back up a file before editing, for examplesudo cp sshd_config sshd_config.bak./var/logis where you look first when something fails, and where a defender looks for traces of your testing. Authorised testing leaves logs. That is expected.
Common mistakes
- Confusing
/with/root. - Installing tools by hand into
/usr/bin, which the package manager may later overwrite. Use/optor your home directory. - Storing project files in
/tmpand losing them after a reboot. - Editing files in
/procor/syswithout knowing the effect. They change live kernel settings.
Next steps
The same layout applies to RHEL and Rocky Linux, with small differences in package paths, so practising here carries over to Red Hat exams. For a structured path, see the Linux course. For the general view, read what the Linux file system hierarchy is and why it matters.
Related reading
Frequently Asked Questions
What's Your Reaction?
Like
1
Dislike
0
Love
0
Funny
0
Wow
0
Sad
0
Angry
0