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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

💡 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

Enter fullscreen mode Exit fullscreen mode

☠️ 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

Enter fullscreen mode Exit fullscreen mode

☁️ 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

Enter fullscreen mode Exit fullscreen mode

⚠️ 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

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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.

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

• 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.