📌 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

/etc — The Config Directory (DevOps Essential)

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

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.

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.

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

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):

3 Types of Permissions (what):

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

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

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