File System Deep Dive, File Operations & Permissions

📌 What's covered in this session

• Linux File System Hierarchy — deeper look at every directory
• File Operations — rm, cp, mv with all flags
• Linux Permissions — what they mean, how they work
• Symbolic vs Numeric permission system
• Real DevOps use cases for permissions

---

01 — File System Hierarchy (Deeper Look)

We touched on this in Session 2. This session goes deeper — every directory has a specific purpose and knowing them matters when you're working on real servers.

/  (root)
├── /bin
├── /sbin
├── /etc
├── /home
├── /tmp
├── /lib
├── /lib32
├── /boot
├── /mnt
├── /media
└── /var

Every Directory Explained

Directory	Full Name	What lives here	DevOps relevance
/bin	Binaries	Essential user commands — ls, cp, mv, cat	These commands are available even in minimal rescue environments
/sbin	System Binaries	Admin commands — fdisk, reboot, ifconfig	Used for system recovery and server administration
/etc	Et Cetera (config)	All system & app config files	Critical in DevOps — Ansible, Chef, Puppet all manage files here
/home	Home	Personal directories for each user (/home/tejas)	Where your scripts, keys, and user files live
/tmp	Temporary	Temp files, cleared on reboot	CI/CD pipelines often use this for build artifacts
/lib	Libraries	Shared libraries that /bin and /sbin need to run	Like DLLs in Windows — programs depend on these
/lib32	32-bit Libraries	32-bit version of libraries	Needed when running older 32-bit software
/boot	Boot	Bootloader files — GRUB, kernel image (vmlinuz)	BIOS → UEFI → GRUB → Kernel boot sequence lives here
/mnt	Mount	Manually mounted drives and filesystems	Mounting EBS volumes on EC2, NFS shares
/media	Media	Auto-mounted removable media (USB, CD)	Less relevant in servers, common on desktops
/var	Variable	Logs, mail, databases — data that changes constantly	/var/log is where you debug production issues
/root	Root home	Home directory of the root superuser	Separate from /home — root user lives here
/run	Runtime	Temporary runtime data — PID files, sockets	Services write their PID here on startup
/proc	Process (virtual)	Live kernel and process info — not real files on disk	cat /proc/cpuinfo, cat /proc/meminfo for system stats

/etc — The Config Directory (DevOps Essential)

/etc is the most important directory for DevOps work. Key files inside it:

File	What it controls
/etc/passwd	User account info — username, UID, home dir, shell
/etc/shadow	Encrypted passwords (only root can read)
/etc/group	Group definitions — which users belong to which group
/etc/shells	List of valid shells on the system
/etc/profile	System-wide environment variables and startup programs
/etc/hostname	The server's hostname
/etc/hosts	Local DNS — maps IPs to hostnames without DNS server
/etc/fstab	Filesystem mount table — what gets mounted on boot

Boot Process — Quick Overview

BIOS / UEFI → GRUB (bootloader) → Kernel loads → init / systemd starts → System ready

💡 GRUB lives in /boot. When a server won't boot, this is where you investigate. On EC2, AWS handles the bootloader but the concept is the same.

☁️ DevOps Context — EC2 & EBS

When you attach an EBS volume to an EC2 instance, you mount it under /mnt or a custom path. When you need to debug why a service failed, you check /var/log. When Ansible configures a server, it edits files in /etc.

Knowing the file system hierarchy is knowing where things live on every Linux server you'll ever touch.

02 — File Operations

Deleting Files & Directories — rm

⚠️ Linux has no recycle bin. rm is permanent.

Command	What it does
rm file.txt	Delete a single file permanently
rm file1.txt file2.txt file3.txt	Delete multiple files in one go
rm *.txt	Delete all files with .txt extension in current directory
rm -d my_dir	Remove an empty directory only
rmdir my_dir	Remove an empty directory (same as -d)
rm -r my_dir	Remove directory and everything inside it recursively
rm -f file.txt	Force delete — suppresses errors, no prompts
rm -rf my_dir	Force delete directory recursively — most dangerous command
rm -i file.txt	Interactive — prompts before each deletion (y = yes, n = no)
rm -ir my_dir	Interactive recursive delete — prompts for each file inside

Creating nested dirs and removing them

# Create nested structure
mkdir -p rm/rm1/rm2

# Remove the whole thing
rm -rf rm

☠️ rm -rf — The Most Dangerous Command

rm -rf / would delete the entire filesystem. There's no undo.

Always double-check your path before running rm -rf.

In scripts, use rm -i or add a confirmation prompt.

The famous incident: a deployment script ran rm -rf $DEPLOY_DIR/ where $DEPLOY_DIR was empty — it became rm -rf /.

Use rm -ir when deleting recursively in unfamiliar directories.

☁️ DevOps Context — Cleanup Scripts

In CI/CD pipelines, old build artifacts and log files are cleaned up with rm.

A common pattern:

rm -rf /tmp/build/*      # clean build artifacts
rm -f /var/log/app/*.log # clean old logs

Always use -i when testing a cleanup script for the first time.

---

Copying Files & Directories — cp

cp copies files — the original stays, a new copy is created at the destination.

Command	What it does
cp file.txt backup.txt	Copy file.txt → backup.txt (new file created in same dir)
cp file.txt file2.txt	If file2.txt exists, it will be overwritten
cp -r mydir /home/tejas/Desktop	Copy entire directory with all its contents
cp /home/tejas/docs/file.txt /home/tejas/backup/	Copy file to another directory, same filename
cp /home/tejas/docs/file.txt /home/tejas/backup/file_backup	Copy and rename at destination simultaneously

Source and Destination pattern

cp <source> <destination>

# Examples
cp file.txt /home/tejas/backup/              # copy, keep same name
cp file.txt /home/tejas/backup/file_bak.txt  # copy and rename
cp -r mydir/ /home/tejas/Desktop/            # copy whole directory

☁️ DevOps Context — Backups

Before editing any config file on a server, always take a backup:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

If your edit breaks something, restore with:

cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

This is standard practice before touching any file in /etc.

---

Moving & Renaming — mv

mv does two things depending on how you use it — it moves files/dirs, and it renames them. The original is removed (unlike cp).

Command	What it does
mv file.txt new.txt	Rename file in the same directory
mv my_dir new_dir	Rename a directory
mv file.txt /home/tejas/desktop	Move file to another location, same name
mv mydir /home/tejas/desktop	Move entire directory to another location
mv file.txt file2.txt	If file2.txt exists, it overwrites the contents — no warning
mv -i file1.txt file2.txt	Interactive — prompts before overwriting
mv /home/tejas/docs/file.txt /home/tejas/backup/	Move using absolute paths — works from anywhere
mv /home/tejas/docs/file.txt /home/tejas/backup/file2.txt	Move AND rename at the same time

mv — rename or move, same command

# Rename
mv old_name.txt new_name.txt

# Move
mv file.txt /home/tejas/projects/

# Move + rename in one shot
mv file.txt /home/tejas/projects/renamed_file.txt

⚠️ Common mistake: mv file.txt existing_file.txt silently overwrites existing_file.txt with no warning. Use mv -i when you're not sure what's at the destination.

☁️ DevOps Context — Deployments

mv is used in deployment scripts to do atomic swaps:

mv /opt/app/releases/new /opt/app/current

This is safer than copying because the move is near-instant on the same filesystem — no half-copied state.

03 — Linux Permissions

This is one of the most important topics in Linux — and one of the most common interview areas for DevOps roles.

The Big Picture

Every file and directory in Linux has 3 types of users and 3 types of permissions.

3 Types of Users (who):

Type	Symbol	Who they are
Owner	u	The user who created the file
Group	g	A group of users who share access
Others	o	Everyone else on the system

3 Types of Permissions (what):

Permission	Symbol	Numeric	What it means
Read	r	4	View file contents / list directory
Write	w	2	Modify file / create files in directory
Execute	x	1	Run the file as a program / enter directory

---

Reading Permissions — ls -l

When you run ls -l, you see something like this:

```text id="xvfyqx"
-rwxr-xr-- 1 tejas devops 4096 Jun 10 file.txt
drwxr-xr-x 2 tejas devops 4096 Jun 10 mydir/

Breaking down the permission string:



```text id="j8y7fq"
d  rwx  r-x  r--
│   │    │    │
│   │    │    └── Others permissions
│   │    └─────── Group permissions
│   └──────────── Owner permissions
└──────────────── File type: d=directory, -=file, l=symbolic link

Each permission block is rwx:

• r = read is allowed
• w = write is allowed
• x = execute is allowed
• - = that permission is NOT set

---

Numeric (Octal) Permissions

Each permission has a number value:

```text id="vlgxho"
r = 4
w = 2
x = 1

You add them up for each user type:

| Combination | Calculation   | Meaning                    |
| ----------- | ------------- | -------------------------- |
| `rwx`       | 4+2+1 = **7** | Full access                |
| `rw-`       | 4+2+0 = **6** | Read and write, no execute |
| `r-x`       | 4+0+1 = **5** | Read and execute, no write |
| `r--`       | 4+0+0 = **4** | Read only                  |
| `---`       | 0+0+0 = **0** | No permissions             |

So a 3-digit number like `755` means:



```text id="rds26u"
7  5  5
│  │  │
│  │  └── Others: r-x (read + execute)
│  └───── Group:  r-x (read + execute)
└──────── Owner:  rwx (full access)

---

Common Permission Numbers

Number	What it means	Used for
777	Everyone has full access	❌ Never use in production
755	Owner: full, Group+Others: read+execute	Directories, public scripts
644	Owner: read+write, Group+Others: read only	Regular files, config files
600	Owner: read+write only, nobody else	Private keys, sensitive files
700	Owner: full, nobody else	Private scripts
711	Owner: full, others: execute only	Executable with restricted read
666	Everyone can read+write	Default for new files (before umask)

---

Default Permissions

Linux assigns default permissions when you create new files or directories:

```text id="e43c0x"
Default for files: 666 (rw-rw-rw-)
Default for directories: 777 (rwxrwxrwx)

> But these defaults are modified by **umask** (covered in a later session) — which is why files you create usually show up as `644` and directories as `755`.

---

### Real Use Cases for Permissions

**1. Protecting a private file**



```bash id="rk8k13"
chmod 600 private_key.pem
# Only you can read/write. No one else can even see it.

2. Script is not running (no execute permission)

```bash id="2q4p5z"
chmod 755 deploy.sh

Now you can run it with ./deploy.sh

**3. Shared file — team can read, only you can edit**



```bash id="d2u6kh"
chmod 644 config.yaml

4. Lock down a sensitive config

```bash id="c4s8rw"
chmod 600 /etc/app/database.conf

---

### How Groups Work in Practice

Think of it like a project structure:



```text id="e4wltx"
PROJECT
├── MODULE 1 → Users: A, B, C  (they're a group)
├── MODULE 2 → Users: D, E
└── MODULE 3 → Users: F, G, H

• A, B, C form a group — they all get the same access to MODULE 1 files
• If file.txt belongs to the MODULE 1 group, A, B, C all inherit the group permissions
• D, E working on MODULE 2 fall under "others" for MODULE 1 files

This is exactly how server teams work — a devops group can have read access to config files, while only root (owner) can write to them.

☠️ Never use chmod 777 in Production

chmod 777 gives every user on the system full read, write, and execute access. On a shared server or cloud instance, this is a critical security vulnerability. If someone gets any user account, they can modify or execute your files.

The only time 777 is acceptable is temporary local testing — and even then, it's a bad habit.

☁️ DevOps Context — SSH Keys

When you download a .pem key from AWS to SSH into an EC2 instance, the first thing AWS tells you:

chmod 400 my-key.pem
# or
chmod 600 my-key.pem

If the key has open permissions (644 or 777), SSH refuses to connect with the error:

WARNING: UNPROTECTED PRIVATE KEY FILE!

This is Linux permission enforcement protecting you from accidentally exposing your private key.

⚡ Quick Revision

Concept	One-liner
/etc	All config files live here. The most important dir in DevOps.
/var/log	Where logs live. First place to check when debugging.
/proc	Virtual FS — live kernel and process info. Not real files.
/boot	Bootloader and kernel image. GRUB lives here.
rm -rf	Force recursive delete. Permanent. No undo. Always double-check path.
rm -ir	Interactive recursive delete. Safer for scripts.
cp src dst	Copy — original stays. Overwrites destination if it exists.
mv old new	Move/rename — original is removed. Overwrites silently without -i.
r=4, w=2, x=1	Numeric permission values. Add them up per user type.
chmod 600	Owner read+write only. Used for SSH keys and sensitive files.
chmod 755	Owner full, others read+execute. Standard for scripts and dirs.
chmod 644	Owner read+write, others read. Standard for config files.
777 = danger	Never in production. Full access to everyone.

---

🎯 Interview Points

Q: What does rm -rf do and why is it dangerous?

It forcefully deletes a directory and all its contents recursively with no prompts and no undo. It's dangerous because a wrong path — especially with a variable that's empty — can delete critical system files. Always verify the path before running it.

Q: What is the difference between cp and mv?

cp copies a file — the original remains at the source and a new copy is created at the destination. mv moves a file — the original is removed from the source. mv is also used to rename files.

Q: Explain the permission string drwxr-xr--

d = it's a directory. rwx = owner has read, write, execute. r-x = group has read and execute (no write). r-- = others have read only. In numeric form: 754.

Q: Why would a DevOps engineer use chmod 600 on a file?

For sensitive files like SSH private keys, passwords, or API credentials. 600 means only the owner can read or write — no one else on the system can access it. AWS SSH keys require this or the SSH client refuses to use the key.

Q: What is the difference between /bin and /sbin?

/bin contains essential commands available to all users — like ls, cat, cp. /sbin contains system administration commands — like fdisk, reboot, ifconfig — typically only run by root.

Q: What files in /etc are important for user management?

/etc/passwd — stores user account info (username, UID, home dir, shell). /etc/shadow — stores encrypted passwords, only readable by root. /etc/group — defines groups and their members.

Q: What is /proc and how is it different from other directories?

/proc is a virtual filesystem — its files don't exist on disk. They're generated by the kernel in real time. It exposes live system information: cat /proc/cpuinfo gives CPU details, cat /proc/meminfo gives memory stats. Useful for monitoring and debugging without installing tools.

---

🛠️ Practice Tasks

Easy

1. Create a file secret.txt, write something in it, then set permissions so only you can read and write it. Verify with ls -l.

2. Create a shell script file hello.sh with echo "hello" inside. Try running it. It will fail — fix the permissions so it's executable, then run it.

3. Create a directory project/ with 3 files inside. Use cp -r to copy the whole directory to /tmp/project_backup.

Medium

1. Create a nested directory deploy/v1/artifacts. Copy a file into it. Then use rm -ir to delete it interactively — observe the prompts at each level.

2. Use mv to rename a file, then move it to a different directory, and finally move+rename it in a single command. Do all three as separate operations.

3. Read /etc/passwd using cat. Identify 3 fields — username, UID, and the shell assigned. Find a user that has /usr/sbin/nologin as their shell and explain why.

DevOps Scenarios

Scenario: You SSH into an EC2 instance and your .pem key throws WARNING: UNPROTECTED PRIVATE KEY FILE!. What happened, why does Linux block this, and what command fixes it?

Scenario: A junior engineer ran a cleanup script that accidentally deleted /var/log/nginx/ instead of /tmp/nginx/. The script used rm -rf $LOG_DIR and $LOG_DIR was set incorrectly. How would you prevent this in future scripts? What safeguards would you add?

---

💡 Takeaway

Session 3 connected two things that always come up together in DevOps — file operations and permissions. Knowing rm, cp, and mv is table stakes. But understanding why permissions exist and how to set them correctly is what keeps production systems secure.

Every time you deploy an app, create a service account, or set up SSH access — you're making permission decisions. Getting them wrong either locks things out or opens up security holes.

The rule is simple:

Give the minimum permissions needed for the job to work, nothing more.

---

Next session: Users & Groups management — useradd, usermod, passwd, chown, chgrp and how Linux user management maps to IAM in AWS. 👀

---

💬 Learning Linux for DevOps & Cloud. Drop a comment if you spot something wrong or have questions — always open to feedback.