Inside the Linux File System: What I Found When I Stopped Using ls and Started Investigating 🔎
Linux doesn't hide how it works. Every configuration, every running process, every connected device it's all sitting right there in the file system, waiting to be read. I explored an Ubuntu 24.04 system from the ground up. Here are 12 findings that changed how I think about Linux.
Finding 1: /etc/resolv.conf — Where Linux Learns to Translate Domain Names
When you type google.com in a browser, your system doesn't magically know the IP address. It needs a translator a DNS resolver. That translator's address lives in one tiny file.
This single line tells the entire system: "When you need to convert a domain name to an IP address, ask Google's DNS server at 192.68.65.7"
Why it matters: If this file is misconfigured or empty, nothing on your system can resolve domain names. Your internet technically works --> the network is connected but no website will load because the system can't translate names to addresses. It's like having a phone but no contacts saved. You could dial numbers, but you wouldn't know anyone's number.
Interesting baat: On many modern systems, this file is actually auto-generated by services like systemd-resolved. ( I got to know the same thing 2 min ago )
Finding 2: /etc/hosts — The Local Override Nobody Talks About
Before Linux even touches the DNS server, it checks a local file first just like pehle istemal kre phir vishwas kre
This file maps hostnames to IP addresses locally. If it finds a match here, it never goes to the DNS server at all. The request is resolved instantly, on the machine itself.
The first two lines are standard — 127.0.0.1 localhost maps the hostname "localhost" to the my machine. The IPv6 versions (::1) do the same for IPv6 networking.
But look at the last line: 172.17.0.2 a3e3314bffb1. That's Docker adding your container's hostname and IP address to its own /etc/hosts file so the container can reference itself by name.
Why it matters: This is how developers point domains to their local machine during development. For example you can add 127.0.0.1 myapp.local and your browser will treat myapp.local as your own computer. The system checks this file before hitting the DNS server, making local hostname resolution instant and always working, even if your internet is down.
Interesting baat: how does Linux decide whether to check /etc/hosts first or DNS first? That brings us to the next finding. lesss goo 🔥
Finding 3: /etc/nsswitch.conf — The Decision-Maker Behind DNS Resolution ⚖️
This is the file most people have never heard of, but it controls the entire name resolution order.
Look at the hosts: line — it says files dns. That means for hostname lookups, check files first (/etc/hosts), then dns (/etc/resolv.conf). If you swapped the order to dns files, the system would ask the DNS server first and only check local files as a fallback.
I guess the doubt is now clear.
Why it matters: This file controls more than just DNS. It also decides how user authentication, groups, and network lookups are resolved whether from local files, or other directory services. It's the silent traffic controller of the entire system's lookup behavior.
Notice the passwd:, group:, and shadow: lines all say files. This means Linux checks these local files for user info.
Interesting insight: The order matters. files dns means local resolution is fast and preferred. If a domain is in /etc/hosts, DNS is never even contacted. This is why /etc/hosts is so powerful — it's checked first, always.
Finding 4: /etc/passwd and /etc/shadow — Linux's Two-Layer Security Design
Every user on the system has an entry in /etc/passwd.
Each line has 7 colon-separated fields: username, password placeholder, user ID (UID), group ID (GID), description, home directory, and login shell.
Notice the x in the password field? That means the actual password hash is stored elsewhere in /etc/shadow.
Why it matters: /etc/passwd is readable by everyone (-rw-r--r--) because many programs need to look up usernames. But if password hashes were stored here, any user could read and attempt to crack them. So Linux separates the sensitive data into /etc/shadow, which only root and the shadow group can read (-rw-r-----). This is a textbook example of the principle of least privilege.
Interesting insight: Look at the shell field. root gets /bin/bash, meaning it can log in and run commands. But daemon and bin have /usr/sbin/nologin — these are system accounts that are intentionally blocked from ever logging in interactively. The system creates users that aren't people. They exist only so that services can run under their own isolated identity instead of running as root.
Finding 5: The Permission System and SUID When a Regular User Needs Root Powers
Linux permissions follow a simple model: read (r), write (w), execute (x) for owner, group, and others. But there's a special permission bit most people overlook.
These files have the SUID bit set. That means when any user runs them, the program executes with the file owner's permissions (usually root) — not the user's own permissions.
Why it matters: A normal user can't modify /etc/shadow directly. But they need to change their own password. So /usr/bin/passwd (a SUID binary) temporarily runs as root, validates the old password, updates the shadow file, and drops back. The user never actually gets root access — the program does, on their behalf, for that one specific task.
Interesting insight: SUID is powerful but dangerous. If a SUID binary has a vulnerability, an attacker can exploit it to gain root access. This is why security audits regularly scan for unexpected SUID files. One misplaced SUID bit on the wrong binary can compromise an entire server.
What I Took Away From This
Linux doesn't have a hidden control panel. There's no settings app, no registry. The configuration is the file system. DNS resolves because of three text files working together. Security works because of permission bits on two files. Hardware works because devices are files you can read and write.
The "everything is a file" principle isn't just a design choice — it's the reason Linux is debuggable, scriptable, and composable in ways other systems aren't. When something breaks, you don't need special tools. You need to know which file to read.
This exploration was done on Ubuntu 24.04.4 LTS (Noble Numbat). All outputs shown are from an actual Linux environment, not fabricated examples.