Linux File System

1. Linux File System Basics

In Linux, everything is a file. The file system controls how data is stored and retrieved. Unlike Windows (which uses drive letters like C:, D:), Linux uses a single hierarchical tree structure starting from the root directory (/).

• Hierarchy: The structure looks like an inverted tree.
• / (Root): The starting point.
• /home: User personal data.
• /etc: Configuration files.
• /var: Variable data (logs, websites).

• /bin & /usr/bin: Executable binaries/programs.

• Common File System Types:

• ext4: The most common standard Linux file system. Reliable and stable.

• XFS: High-performance, great for handling very large files (often used in enterprise RHEL/CentOS systems).

• Btrfs: Advanced features like snapshots and self-healing.

---

2. Inodes (Index Nodes)

An Inode is a data structure on the file system that stores all information about a file except its name and actual data.

• What it stores: File size, owner, permissions, timestamps, and pointers to the disk blocks where the actual data resides.

• Analogy: Think of an Inode as a library catalog card. It tells you where the book (data) is on the shelf, who wrote it, and when it was bought, but it isn't the book itself.

• Inode Number: Every file has a unique inode number.

• Checking Inodes: Use the command ls -i to see the inode number of a file.

Note: If you run out of Inodes (by creating millions of tiny files), you cannot create new files, even if you have free disk space.

Command,Description,Example
df -h,"Shows disk space usage in ""human-readable"" format (GB, MB).",df -h
df -T,"Shows the file system type (ext4, xfs, etc.).",df -Th
du -sh [path],"""Disk Usage"". Shows the size of a specific directory.",du -sh /var/log
lsblk,Lists all block devices (disks/partitions) in a tree view.,lsblk
mount / umount,Attaches or detaches a file system.,mount /dev/sdb1 /mnt/data
ls -i,Lists files with their Inode numbers.,ls -i filename
df -i,Checks total Inodes available vs. used (useful if disk is full but df -h shows space).,df -i

stat [file],"Displays detailed Inode info (access time, modify time, Inode #).",stat index.html

3. Hard Links & Soft Links

Hard Links
A Hard Link is essentially a mirror copy or a second name for the exact same file.

It points directly to the Inode of the original file.

If you change the content of the hard link, the original file changes (because they are physically the same data).

If you delete the original file, the hard link still works because the inode and data blocks still exist.

Soft Links (Symbolic Links / Symlinks)
A Soft Link is like a shortcut in Windows.

It points to the file path (name) of the original file, not the inode.

It has its own unique inode.

If you delete the original file, the soft link becomes "broken" (dangling) because the path it points to no longer exists.

Links are pointers to files. Linux has two distinct types.

Feature	Hard Link	Soft Link (Symbolic Link)
Definition	A direct mirror copy. It points to the same Inode as the original file.	A shortcut. It is a special file that points to the path/name of another file.
Inode	Shares the same Inode number as the original.	Has its own unique Inode number.
Deletion	If you delete the original file, the hard link still works (data remains).	If you delete the original file, the soft link becomes broken (dangling).
Cross-filesystem	Cannot link across different partitions/drives.	Can link across different partitions/drives.
Directory	Generally cannot link to directories.	Can link to directories.
Command	ln target link_name	ln -s target link_name

Commands for Hard & Soft Links
How to create and identify links using the ln command.

Creating a Hard Link

Syntax: ln [original_file] [link_name]

Example: ln script.py hard_script.py

Check: If you run ls -i, both files will share the same Inode number.

Creating a Soft (Symbolic) Link

Syntax: ln -s [original_path] [link_name]

Example: ln -s /var/www/html/index.php my_link

Check: ls -l will show an arrow: my_link -> /var/www/html/index.php. The Inode numbers will be different.

4. LVM (Logical Volume Manager)

LVM allows for flexible disk management. Instead of dealing with fixed physical partitions (like /dev/sda1), LVM creates an abstraction layer. This allows you to resize volumes on the fly.

The LVM Architecture:

1. Physical Volume (PV): The actual raw disk or partition (e.g., /dev/sdb).
2. Volume Group (VG): A pool of storage created by combining one or more PVs. Think of this as a "storage bucket."
3. Logical Volume (LV): A virtual partition carved out of the VG. This is what you actually format and mount (e.g., /dev/mapper/vg_data-lv_logs).

Why use LVM?

• Resizing: You can extend a Logical Volume if it runs out of space (provided the Volume Group has space) without rebooting.
• Spanning: A single file system can span across multiple physical hard drives.
• Snapshots: You can take a frozen copy of the file system for backups.

LVM (Logical Volume Manager) Commands
LVM involves three steps: Physical Volumes (PV) → Volume Groups (VG) → Logical Volumes (LV).

Step A: Physical Volume (PV)
pvcreate /dev/sdb: Initialize a disk or partition for LVM use.

pvs: Short summary of physical volumes.

pvdisplay: Detailed info about PVs.

Step B: Volume Group (VG)
vgcreate my_vg /dev/sdb: Create a group named "my_vg" using the PV.

vgs: Short summary of volume groups.

vgextend my_vg /dev/sdc: Add a new disk to an existing group to increase capacity.

Step C: Logical Volume (LV)
lvcreate -L 10G -n my_lv my_vg: Create a 10GB logical partition named "my_lv" inside "my_vg".

lvs: Short summary of logical volumes.

lvextend -L +5G /dev/my_vg/my_lv: Increase the size of the logical volume by 5GB.

resize2fs /dev/my_vg/my_lv: Crucial step. Resizes the file system to use the newly added space (for ext4).

5. RAID Levels (Redundant Array of Independent Disks)

RAID combines multiple physical disk drive components into one or more logical units for data redundancy, performance improvement, or both.

• RAID 0 (Striping):
• Concept: Splits data evenly across two or more disks.
• Pros: Very high performance (read/write speed).

• Cons: Zero redundancy. If one disk fails, all data is lost.

• RAID 1 (Mirroring):

• Concept: Writes the exact same data to two disks simultaneously.

• Pros: High redundancy. If one drive fails, the other has a full copy.

• Cons: You lose 50% of your storage capacity (2TB + 2TB drives = 2TB usable space).

• RAID 5 (Striping with Parity):

• Concept: Stripes data and parity (error correction) information across 3 or more disks.

• Pros: Good balance of performance and redundancy. Can survive 1 disk failure.

• Cons: Write performance is slower due to parity calculations.

• RAID 10 (1+0):

• Concept: A stripe of mirrors. It combines the speed of RAID 0 with the redundancy of RAID 1.

• Pros: High speed and high redundancy.

• Cons: Expensive (requires at least 4 disks and loses 50% capacity).
  RAID Commands
  Software RAID in Linux is typically managed using the mdadm tool.

cat /proc/mdstat: The quickest way to check the status of active RAID arrays.

mdadm --detail /dev/md0: specific details about a RAID array (replace /dev/md0 with your array).

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc: Example command to create a RAID 1 (Mirror) array using two disks.

Here is a safe, executable Bash script that simulates these concepts. You can copy this code, save it as a file (e.g., practice_links.sh), and run it in your terminal.

This script will create a temporary directory, generate files, create links, and display the Inode numbers so you can see the differences clearly.

The Practice Script

#!/bin/bash

# 1. Setup a sandbox directory so we don't mess up your actual files
mkdir -p link_practice
cd link_practice
echo "--- Starting Inode & Link Practice ---"
echo ""

# 2. Create an original file
echo "This is the original content." > original.txt
echo "[1] Created 'original.txt'."
ls -li original.txt
echo "--------------------------------------"

# 3. Create a Hard Link
ln original.txt hard_link.txt
echo "[2] Created Hard Link named 'hard_link.txt'."
echo "Check the Inode numbers (1st column) below. They should be identical:"
ls -li original.txt hard_link.txt
echo "--------------------------------------"

# 4. Create a Soft Link
ln -s original.txt soft_link.txt
echo "[3] Created Soft Link named 'soft_link.txt'."
echo "Check the Inode numbers below. The Soft Link has a DIFFERENT Inode:"
ls -li original.txt soft_link.txt
echo "--------------------------------------"

# 5. Modify the Hard Link
echo " [Update] Appending text to 'hard_link.txt'..."
echo " (Added via hard link)" >> hard_link.txt
echo "Reading 'original.txt':"
cat original.txt
echo "--> Notice: The original file changed because they point to the same data."
echo "--------------------------------------"

# 6. Delete the Original File
rm original.txt
echo "[4] DELETED 'original.txt'."
echo ""

# 7. Check the results
echo "Checking Hard Link content:"
if cat hard_link.txt; then
    echo "--> SUCCESS: Hard link still works (Data still exists on disk)."
else
    echo "--> FAIL."
fi
echo ""

echo "Checking Soft Link content:"
if cat soft_link.txt 2>/dev/null; then
    echo "--> SUCCESS."
else
    echo "--> FAILED: Soft link is broken (Dangling link). It points to a filename that is gone."
fi

# Cleanup
cd ..
rm -rf link_practice
echo ""
echo "--- End of Simulation (Cleaned up temporary files) ---"

The LVM Practice Script
Save this as lvm_practice.sh, make it executable (chmod +x lvm_practice.sh), and run it with sudo ./lvm_practice.sh.

#!/bin/bash

# Ensure script is run as root
if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root (use sudo)." 
   exit 1
fi

echo "--- Starting LVM Simulation ---"
echo "We will create 'fake' hard drives using files to practice LVM safely."
echo ""

# 1. Create fake physical disks (100MB each)
echo "[1] Creating 2 fake disk images (100MB each)..."
dd if=/dev/zero of=disk1.img bs=1M count=100 status=none
dd if=/dev/zero of=disk2.img bs=1M count=100 status=none

# Attach them to loop devices so Linux sees them as block devices
LOOP1=$(losetup --find --show disk1.img)
LOOP2=$(losetup --find --show disk2.img)
echo "--> Created fake disks at: $LOOP1 and $LOOP2"
echo "--------------------------------------"

# 2. Initialize Physical Volumes (PV)
echo "[2] Initializing Physical Volumes (pvcreate)..."
pvcreate $LOOP1 $LOOP2
echo "--> PVs created."
echo "--------------------------------------"

# 3. Create a Volume Group (VG)
echo "[3] Creating Volume Group 'demo_vg' using the first disk..."
vgcreate demo_vg $LOOP1
vgs
echo "--> Volume Group 'demo_vg' created."
echo "--------------------------------------"

# 4. Create a Logical Volume (LV)
echo "[4] Creating a 50MB Logical Volume 'demo_lv'..."
lvcreate -L 50M -n demo_lv demo_vg
lvs
echo "--> Logical Volume 'demo_lv' created."
echo "--------------------------------------"

# 5. Format and Mount
echo "[5] Formatting with ext4 and mounting..."
mkfs.ext4 /dev/demo_vg/demo_lv > /dev/null
mkdir -p /mnt/lvm_demo
mount /dev/demo_vg/demo_lv /mnt/lvm_demo

# Check space
echo "--> Current Disk Usage:"
df -h /mnt/lvm_demo
echo "--------------------------------------"

# 6. EXTENDING the Storage (The Magic of LVM)
echo "[6] SCENARIO: We are running out of space!"
echo "    We will add the second disk to the group and extend the volume."
echo ""

echo "Step A: Extend Volume Group (add disk2)..."
vgextend demo_vg $LOOP2

echo "Step B: Extend Logical Volume (add 80MB)..."
lvextend -L +80M /dev/demo_vg/demo_lv

echo "Step C: Resize Filesystem (make the OS see the new space)..."
resize2fs /dev/demo_vg/demo_lv > /dev/null

echo ""
echo "--> New Disk Usage (Notice the size increase!):"
df -h /mnt/lvm_demo
echo "--------------------------------------"

# 7. CLEANUP (Undo everything)
echo "[7] Cleaning up..."
umount /mnt/lvm_demo
lvremove -y /dev/demo_vg/demo_lv
vgremove -y demo_vg
pvremove -y $LOOP1 $LOOP2
losetup -d $LOOP1
losetup -d $LOOP2
rm disk1.img disk2.img
rmdir /mnt/lvm_demo

echo "--- Simulation Complete. System returned to normal. ---"

What you will learn from this script:
pvcreate: You'll see how raw "disks" are prepped.

vgextend: You'll see how easy it is to add a second "disk" to your storage pool.

lvextend + resize2fs: You'll witness the storage capacity of a mounted folder jump from ~50MB to ~130MB instantly without losing data.

Troubleshooting
If the script fails halfway (e.g., if you cancel it with Ctrl+C), you might have leftover loop devices. You can clean them manually:

sudo losetup -D (Detaches all loop devices)

sudo rm disk1.img disk2.img

Here is the breakdown of Linux File Permissions. This is one of the most critical security concepts in Linux. If you master this, you control who can see, touch, or run anything on your server.

---

1. The Anatomy of a Permission

When you run ls -l, you see a string like this:
drwxr-xr--

This string is split into 4 parts:

1. File Type: The first character.
2. - = Normal File
3. d = Directory

4. l = Link

5. User (u): The Owner of the file. (Next 3 chars)

6. Group (g): The Group assigned to the file. (Next 3 chars)

7. Others (o): Everyone else (the public). (Last 3 chars)

---

2. The "What": Read, Write, Execute

Linux uses a point system (Octal) for permissions. You just add the numbers up to get the permission level.

Permission	Letter	Number Value	Description
Read	r	4	Can open and view the file content.
Write	w	2	Can modify or delete the file content.
Execute	x	1	Can run the file as a program/script.
None	-	0	No access.

The Math (Common Examples)

• 7 (rwx): 4 + 2 + 1 (Read + Write + Execute) → Full Control
• 6 (rw-): 4 + 2 (Read + Write) → Standard for files
• 5 (r-x): 4 + 1 (Read + Execute) → Standard for programs you don't want edited
• 4 (r--): 4 (Read only) → Strict read-only

---

3. The Commands

A. chmod (Change Mode)

This command changes the permissions (Who can do What).

Method 1: The Numeric Way (Most Common)
You provide 3 numbers: One for User, one for Group, one for Others.

• chmod 777 file.txt
• User: 7 (rwx), Group: 7 (rwx), Others: 7 (rwx).

• Danger: Everyone can delete this file.

• chmod 644 file.txt

• User: 6 (rw-), Group: 4 (r--), Others: 4 (r--).

• Standard: Owner can read/write; everyone else can only read.

• chmod 755 script.sh

• User: 7 (rwx), Group: 5 (r-x), Others: 5 (r-x).

• Standard for Scripts: Everyone can run it, but only the owner can change the code.

Method 2: The Symbolic Way
Useful for quick tweaks without doing math.

• u (User), g (Group), o (Others), a (All)
• + (Add), - (Remove)
• chmod +x script.sh → Makes it executable for everyone.
• chmod u+x script.sh → Makes it executable only for the owner.
• chmod o-r secret.txt → Removes read permission for others (privacy).

---

B. chown (Change Owner)

This command changes who owns the file and which group it belongs to. You usually need sudo for this.

• Syntax: chown [user]:[group] [file]

Examples:

• chown steve file.txt

• Changes the owner to "steve".

• chown steve:developers file.txt

• Changes owner to "steve" and group to "developers".

• chown -R steve:developers /var/www/html

• Recursive: Changes owner/group for the folder and everything inside it.

---

4. Practice Simulation

Here is a safe script to practice permissions. It will create files and let you try to "break" the security rules to see what happens.

Save as: perm_practice.sh
Run: chmod +x perm_practice.sh then ./perm_practice.sh

#!/bin/bash

# Setup
mkdir -p perm_lab
cd perm_lab
echo "This is a Top Secret File" > secret.txt

echo "--- Permission Practice ---"

# 1. Standard Permissions
echo "[1] Current permissions for secret.txt:"
ls -l secret.txt
echo "-----------------------------------"

# 2. Locking it down (Read Only)
echo "[2] Running: chmod 400 secret.txt (Read-only for User, Nothing for others)"
chmod 400 secret.txt
ls -l secret.txt

echo "--> Attempting to READ the file:"
cat secret.txt
echo "    (Success!)"

echo "--> Attempting to WRITE to the file:"
# We use a trick to catch the error message safely
if echo "Hacker was here" >> secret.txt 2>/dev/null; then
    echo "    Written successfully."
else
    echo "    FAILED: Permission Denied! (As expected)"
fi
echo "-----------------------------------"

# 3. Making it Executable
echo "[3] We created a script called 'hello.sh'"
echo '#!/bin/bash' > hello.sh
echo 'echo "Hello World!"' >> hello.sh

echo "--> Attempting to run it ./hello.sh"
# Try to run it before giving permission
if ./hello.sh 2>/dev/null; then
    echo "    Ran successfully."
else
    echo "    FAILED: Permission Denied! (It lacks the 'x' flag)"
fi

echo "--> Fix: Running chmod u+x hello.sh"
chmod u+x hello.sh
ls -l hello.sh
./hello.sh
echo "-----------------------------------"

# Cleanup
cd ..
rm -rf perm_lab
echo ""
echo "--- Lab Complete ---"

Here are the Special Permissions in Linux.

In standard permissions (rwx), if I create a file, I own it. If I run a script, it runs with my level of power. Special permissions break these rules to allow for system administration and team collaboration.

---

1. SUID (Set User ID)

"The Temporary Root Badge"

• Function: When a file with SUID is executed, it runs with the permissions of the file owner, not the user who ran it.
• Classic Example: The passwd command.
• Normal users need to change their passwords, which requires writing to /etc/shadow.
• Normal users cannot write to /etc/shadow.

• The passwd binary is owned by root and has the SUID bit set. When you run it, you temporarily "become" root for that specific task.

• Symbol: Look for an s in the User execute slot.

• rwsr-xr-x

• Numeric Value: 4000

⚠️ DevOps Security Warning: SUID is dangerous. If a hacker finds a vulnerable SUID file (like a script that lets them spawn a shell), they can become root instantly. Always audit your system for unknown SUID files: find / -perm /4000

---

2. SGID (Set Group ID)

"The Collaboration Tool"

SGID works differently depending on whether it is on a file or a directory.

A. On a File:

• Similar to SUID, but the program runs with the permissions of the File Group.

B. On a Directory (Most Common DevOps Use Case):

• Function: Any new file created inside this directory will inherit the Group ownership of the directory, not the User's primary group.
• Why use it? If Developers Alice and Bob share a folder /var/www/project.
• Without SGID: Alice creates a file, it belongs to alice:alice. Bob cannot edit it.

• With SGID: Alice creates a file, it belongs to alice:developers. Bob (part of developers group) can edit it.

• Symbol: Look for an s in the Group execute slot.

• rwxr-sr-x

• Numeric Value: 2000

---

3. Sticky Bit

"The Anti-Sabotage Rule"

• Function: Used on shared directories. It ensures that only the owner of a file (or root) can delete or rename it. Even if others have "Write" permission on the folder, they cannot delete your files.
• Classic Example: The /tmp directory.
• Every user and process writes temporary files here.

• Without the Sticky Bit, User A could delete User B's temp files, crashing User B's programs.

• Symbol: Look for a t in the Others execute slot.

• rwxrwxrwt

• Numeric Value: 1000

---

Summary Table

Permission	Acronym	On File	On Directory	Numeric	Symbol
Set UID	SUID	Runs as File Owner	(Ignored)	4000	rws------
Set GID	SGID	Runs as File Group	Files inherit Dir Group	2000	---rws---
Sticky Bit	---	(Ignored)	Only Owner deletes	1000	------rwt

Commands to Set Special Permissions

You can add these bits using the symbolic method (easiest) or numeric method.

1. Setting SUID:

• chmod u+s filename
• chmod 4755 filename (4=SUID, 7=User, 5=Group, 5=Others)

2. Setting SGID:

• chmod g+s directory_name
• chmod 2775 directory_name

3. Setting Sticky Bit:

• chmod +t directory_name
• chmod 1777 directory_name (Standard for /tmp)

---

Quick Practice Check

Run this on your terminal to see the Sticky Bit in action on your own system:

ls -ld /tmp

You should see something like: drwxrwxrwt ... root root ... /tmp

---

This is a complete, hands-on "Master Class" tutorial. It combines every concept we have discussed into a single workflow.

Scenario: You are a Junior DevOps Engineer setting up a new server. You need to manage storage efficiently and secure files for a development team.

Prerequisites: A Linux terminal (Ubuntu/CentOS/WSL) and sudo access.

---

Phase 1: Storage Internals (Inodes & Links)

Goal: Understand how Linux stores files and how to create shortcuts safely.

Step 1: Check your File System

First, let's see what storage you currently have.

df -hT

• Look for: The Type column (usually ext4 or xfs) and the Avail column (free space).

Step 2: Inode Investigation

Create a sandbox directory and a file.

mkdir storage_lab
cd storage_lab
echo "This is my data" > original.txt

Check the Inode number (the file's unique ID):

ls -i original.txt

• Note the number returned (e.g., 123456).

Step 3: Hard vs. Soft Links

Now, let's create both types of links.

1. Create a Hard Link (A mirror copy):

ln original.txt hard_link.txt

1. Create a Soft Link (A shortcut):

ln -s original.txt soft_link.txt

1. Compare them:

ls -li

• Observation: original.txt and hard_link.txt share the same Inode number. soft_link.txt has a different Inode number.

1. The "Destruction" Test: Delete the original file and see what survives.

rm original.txt
cat hard_link.txt   # This works (Data is safe)
cat soft_link.txt   # This fails (Broken link)

---

Phase 2: Logical Volume Manager (LVM)

Goal: Simulate adding a new hard drive and expanding storage without downtime. This is crucial for resizing AWS EBS volumes or DigitalOcean Droplets.

Step 1: Create "Fake" Hard Drives

Since we can't physically insert a drive, we will create two 100MB files that act like drives.

sudo dd if=/dev/zero of=disk1.img bs=1M count=100
sudo dd if=/dev/zero of=disk2.img bs=1M count=100
# Attach them as loop devices
sudo losetup /dev/loop10 disk1.img
sudo losetup /dev/loop11 disk2.img

Step 2: Initialize Physical Volumes (PV)

Tell LVM to use these disks.

sudo pvcreate /dev/loop10 /dev/loop11
sudo pvs

Step 3: Create a Volume Group (VG)

Combine the disks into a storage pool named app_data.

sudo vgcreate app_data /dev/loop10
sudo vgs

Step 4: Create a Logical Volume (LV)

Carve out a 50MB partition from that pool.

sudo lvcreate -L 50M -n logs_lv app_data
sudo lvs

Step 5: Format and Mount

Make it usable for the OS.

# Format as ext4
sudo mkfs.ext4 /dev/app_data/logs_lv
# Create a mount point and mount it
sudo mkdir /mnt/logs
sudo mount /dev/app_data/logs_lv /mnt/logs

Check the size:

df -h /mnt/logs

(You should see roughly 45-50MB available).

Step 6: The "Oh No, Disk Full!" Scenario

Imagine your logs filled up the partition. Let's extend it on the fly using the second disk.

# 1. Add the second disk to the group
sudo vgextend app_data /dev/loop11

# 2. Extend the Logical Volume by 80MB
sudo lvextend -L +80M /dev/app_data/logs_lv

# 3. Resize the file system (The most important step!)
sudo resize2fs /dev/app_data/logs_lv

# 4. Check the new size
df -h /mnt/logs

(You should now see roughly 120-130MB. You just resized storage without rebooting!)

---

Phase 3: Understanding RAID

Goal: Conceptual check. (We won't build a RAID array as it conflicts with the LVM lab on a single machine, but we will check for it).

1. Check RAID Status: Run this command to see if your current system uses Software RAID.

cat /proc/mdstat

• If you see unused devices: <none>, you are not running RAID.
• In a real server, you might use mdadm to pair disks (e.g., RAID 1 for mirroring).

---

Phase 4: Basic Permissions

Goal: Control who can read/write your files.

Step 1: Create a "Secret" File

cd /mnt/logs
sudo touch secret_config.txt

Step 2: Lock it down

Remove all permissions for "Group" and "Others".

sudo chmod 600 secret_config.txt
ls -l secret_config.txt

• Result: Only the owner (root) can read/write. If you switch users, you cannot see this file.

Step 3: Change Ownership (chown)

Give this file to your current user so you can edit it without sudo.

# Replace 'your_user' with your actual username (run 'whoami' to check)
sudo chown $USER:$USER secret_config.txt
ls -l secret_config.txt

---

Phase 5: Advanced Permissions (The Pro Stuff)

Goal: Use SGID for team collaboration and Sticky Bit for safety.

Step 1: SGID (Shared Group Collaboration)

This is how multiple developers work in one folder (like /var/www/html for WordPress).

1. Create a shared directory.

sudo mkdir /mnt/logs/team_project

1. Set the SGID bit (the 2 in 2777).

sudo chmod 2777 /mnt/logs/team_project

1. Check the permission (Look for the s in the group column).

ls -ld /mnt/logs/team_project

• Result: Any file created inside this folder will automatically inherit the group ownership of the folder, ensuring all team members can access it.

Step 2: Sticky Bit (Anti-Delete)

1. Set the Sticky Bit (the 1 in 1777).

sudo chmod 1777 /mnt/logs/team_project

1. Check the permission (Look for the t at the end).

ls -ld /mnt/logs/team_project

• Result: Users can write files here, but only the person who created the file can delete it. This prevents team members from accidentally deleting each other's work.

---

Cleanup

Since we created fake drives and mount points, let's clean up your system so nothing is left behind.

# 1. Unmount the partition
sudo umount /mnt/logs

# 2. Remove LVM components
sudo lvremove -y /dev/app_data/logs_lv
sudo vgremove -y app_data
sudo pvremove -y /dev/loop10 /dev/loop11

# 3. Detach loop devices and delete fake files
sudo losetup -d /dev/loop10
sudo losetup -d /dev/loop11
rm ~/storage_lab/disk1.img ~/storage_lab/disk2.img
rm -rf ~/storage_lab
sudo rmdir /mnt/logs

Tutorial Complete

You have just performed the daily tasks of a Systems Engineer: managing inodes, resizing volumes with LVM, and securing files with advanced permissions!