Oops! I Broke My Sudoers File: A Tale of Recovery Mode and Linux Permissions

We’ve all been there. One moment, you’re tinkering with your Linux system, feeling like a tech wizard, and the next, you’re staring at the screen in horror because something broke. For me, it was the /etc/sudoers file. I accidentally changed its ownership 777 and now/etc/sudoers is owned by UID 777. If you’ve ever done something similar, don’t panic! Here’s how I fixed it and what I learned along the way.

The Mistake: Changing Permissions to 777

It all started innocently enough. I was trying to change the permissions of the /etc/sudoers file to make it more accessible. I meant to run:

sudo chmod 777 /etc/sudoers

But in a hurry, I accidentally typed:

sudo chown 777 /etc/sudoers

Big. Mistake.

For those who don’t know:

chmod changes file permissions.
chown changes file ownership.

By using chown instead of chmod, I changed the ownership of the /etc/sudoers file to a non-existent user and group with the ID 777. This broke sudo out entirely, and I was locked out of administrative privileges.

The Panic: Locked Out of Sudo

Almost immediately, I realized my mistake. I tried to revert the permissions, but I couldn’t use sudo them anymore. Every time I tried, I got an error:

I was locked out of my system. No sudo, no administrative privileges, no way to fix the problem. Or so I thought.

The Solution: Recovery Mode to the Rescue

After a quick Google search, I learned about Recovery Mode. This special boot option in Ubuntu lets you access your system with root privileges, even if things are broken. Here’s how I used it to fix my mess:

Step 1: Boot into Recovery Mode

I restarted my computer and held down the Shift key (for BIOS) or pressed Esc (for UEFI) to bring up the GRUB menu.
In the menu, I selected Advanced options for Ubuntu and then chose the Recovery Mode option.

Step 2: Drop to a Root Shell

Once in recovery mode, I selected Drop to root shell prompt from the menu. This gave me a terminal with full root access—no sudo required.

Step 3: Remount the Filesystem as Read-Write

By default, the root filesystem is mounted as read-only in recovery mode which acts as a precaution to prevent further damage. Since I had to make changes to /etc/sudoers, I had to remount it as read-write:

mount -o rw,remount /

• The -o flag specifies options for the mount command

• remount is an option that tells the system to remount an already-mounted filesystem with

Step 4: Fix the Permissions

Now came the critical part: fixing the /etc/sudoers file. I ran the following commands:

chown root:root /etc/sudoers
chmod 440 /etc/sudoers

chown root:root /etc/sudoers: This set the file’s ownership back to root.
chmod 440 /etc/sudoers: This set the file’s permissions to 440, meaning only the root user can read it, and no one else can modify it.

Step 5: Verify and Reboot

Before rebooting, I double-checked the file’s permissions:

ls -l /etc/sudoers

The output looked like this:

-r--r----- 1 root root 755 Oct 10 12:34 /etc/sudoers

Perfect! The file was back to its secure state. I then rebooted the system:

reboot

What I Learned

This experience taught me a few valuable lessons:

Permissions Matter: The /etc/sudoers file is critical to system security. Never, ever set its permissions to 777. Avoid using 777 any system file unless you know what you’re doing.
Recovery Mode is a Lifesaver: When things go wrong, recovery mode is your best friend. It gives you root access to fix problems without needing sudo.
Double-Check Commands: One wrong command can cause a lot of trouble. Always double-check before hitting Enter, especially when working with system files.

Final Thoughts

Breaking your system can be stressful, but it’s also a great way to learn. My little adventure with the /etc/sudoers file taught me a lot about Linux permissions and recovery tools. If you ever find yourself in a similar situation, remember: that recovery mode is there to help, and with a few careful commands, you can fix almost anything.

I Broke my /etc/sudoers File