The Day Linux File Permissions Locked Me Out

It was late, I was tired, and I was trying to be clever. I'd just set up my shiny new Linux server, and naturally, the first thing I wanted to do was… tweak permissions. You know, for security. My brain, fueled by lukewarm instant coffee and a vague memory of a sysadmin horror story, decided the best way to secure my home directory was to make it read-only for everyone except me. Sounds reasonable, right? Famous last words. I typed in a chmod command, feeling like a digital locksmith, and hit Enter. Then, it happened. The screen went blank. Not a graceful shutdown, just… blank. When it came back, I couldn't log in. My own /home/myusername directory was suddenly a no-go zone. I was locked out of my own digital kingdom. Oops.

TL;DR: The Epic Permission Fail

So, I messed up Linux file permissions by making my home directory too restrictive. I couldn't log in, couldn't access my files, and felt like a total noob. The fix involved booting into a recovery environment and using sudo to reset permissions. Lesson learned: chmod is powerful, and I should respect its power!

The "Securing My Castle" Illusion

Back in my early Linux days, I was on a mission to harden my systems. I'd read about the importance of file permissions and how they control who can read, write, and execute files. My home directory, /home/myusername, felt like the ultimate target. It held all my personal stuff, my project files, my configs – everything! I thought, "What if someone else gets shell access? They shouldn't be able to snoop around my private files!"

I remembered a command called chmod, which stands for "change mode" (or permissions). It uses numbers or symbolic notation to set permissions. I decided on a number-based approach, thinking I knew what I was doing. I wanted to give myself full control (read, write, execute) and deny everyone else everything.

I typed something that looked like this (don't copy this, obviously!):

chmod 700 /home/myusername

Let's break down that 700:

First digit (7): Owner permissions. 7 in octal is 111 in binary, meaning Read (4) + Write (2) + Execute (1) = 7. So, I gave myself full permissions. Second digit (0): Group permissions. 0 means no permissions at all. Third digit (0): Others permissions. 0 also means no permissions.

This is the correct command to make a directory accessible only by its owner. The problem wasn't the command itself, but what it implied for the login process. When Linux starts your graphical session or shell, it needs to access your home directory to load your settings, profile, and environment variables. If it can't even read inside, it throws a fit.

After running the command, I tried to log out and log back in. The login screen appeared, I typed my password, and then… nothing. The screen flickered, maybe showed a brief glimpse of a desktop, and then dumped me back at the login prompt. Or worse, it might just give me a cryptic error message like:

Login incorrect

or

Permission denied

Then, I tried SSHing in from another terminal. That was even more direct.

ssh myusername@localhost

And the devastating reply:

myusername@localhost's password:
Could not chdir to home directory /home/myusername: Permission denied

My heart sank. I had successfully secured my castle by locking myself out.

The Great Escape: Recovery Mode to the Rescue

Panic started to set in. How do I fix this? I couldn't even get a terminal to run chmod again! My first instinct was to reboot and hope it magically fixed itself (spoiler: it never does).

My next thought was, "Okay, I need administrative access, but outside of my broken user environment." This led me to the magical world of Linux recovery modes. Most Linux distributions have a way to boot into a special mode where you get root privileges and a command line before your user’s home directory is even mounted or accessed.

The specific steps vary depending on your distribution (Ubuntu, Debian, Fedora, Arch, etc.), but the general idea is:

    mount -o remount,rw /
    

cd /home

ls -l

drwxr-xr-x 15 myusername myusername 4096 Oct 26 10:00 myusername

Owner: Read, Write, Execute (7) Group: Read, Execute (5) - This allows users in the same group to list files and execute them, which is common for shared environments or system processes. Others: Read, Execute (5) - Similar to group, but for anyone else.

So, the command to fix it would be:

chmod 755 myusername

Or, if I wanted to be a bit more restrictive and only allow the group to execute (common practice):

```bash chmod 75