How to Resurrect a Linux Box After a Permission Apocalypse

🧨 Once Upon a Time in Terminal Land...

There are stories, and then there are war stories. This is one of the latter.

It began with a simple task: prep some folders, set up permissions. A routine day on a Synology NAS, armed with SSH access and a mission. Then, in a moment of fatigue, distraction, or perhaps an out-of-body root experience, came The Command:

chmod -R 777 /

Oh no.

Wait, CTRL+C! CTRL+C!—too late. The wheels were already in motion. The system didn’t crash. No explosion. Just eerie silence.

But the silence… was lying.

🔐 The First Casualty: Sudo

Try anything elevated, and the box replied like a scorned lover:

sudo: /etc/sudoers world writable
sudo: no valid sudoers sources found. Quitting.

Panic. Despair. Existential reflection.

But then, a beacon: Synology DSM’s WebUI was still breathing. And with it—Task Scheduler. Root-capable. Script-enabled. A second chance.

🛠️ Fixing Sudo with a Toothbrush and a Flamethrower

Like Indiana Jones repatching ancient mechanisms, the first goal was to bring back sudo from the dead:

chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
chown root:root /usr/lib/sudoers.so
chmod 644 /usr/lib/sudoers.so
chmod 775 -R /etc/sudoers
chmod 775 -R /etc/sudoers.d/

Boom. The terminal gods whispered: “Access granted.”

📉 But Wait… What’s That Noise?

Weeks passed. The system ran. Or limped. Disk I/O was off the charts. Services were failing. Logs ballooned to galactic proportions. Every systemd message became a haiku of sorrow:

Configuration file /usr/lib/systemd/system/atalk.service is marked executable.
Please remove executable permission bits. Proceeding anyway.

Like a haunted house where every room has its own poltergeist. The ghost of chmod past was very much alive.

🧠 Enter Plan B: Digital Necromancy

The hero had a twin NAS. Untouched. Pristine. A living archive of how things should be. Could we—dare we—clone the file permission matrix?

Yes. Yes, we could.

📋 Step 1: Create a Permission Inventory

From the healthy system:

find /etc -type f -exec stat -c "%a %n" {} \; > /tmp/permissions.txt

Translation: Give me the numeric permissions and full paths of every file in /etc.

🚚 Step 2: Copy the Spellbook

From Good NAS to Doomed NAS:

scp /tmp/permissions.txt user@busted:/tmp/

🔁 Step 3: Rebuild the World

Now the magic loop:

while read -r perm file; do
chmod "$perm" "$file"
done < /tmp/permissions.txt

Start small. /etc. /usr. Like rebuilding Jenga, from the middle. Gradually. Carefully.

🧪 Testing the Waters

With cautious optimism, services flickered back to life. Log rotation resumed its sacred duty. The cursed chirping of drives turned into the soothing whisper of normality.

And while not every file could be salvaged—different NAS models, divergent package sets—our hero used ls -l comparisons and persistence to manually patch the rest.

📦 Lessons from the Edge

1. Never run chmod -R 777 /. Just. Don’t.
2. Always verify your command. One extra / can ruin lives.
3. WebUI root tools can save your neck—if you're lucky.
4. Two NAS boxes are better than one. A backup is not optional. It’s survival.
5. Permissions are not just numbers. They’re the ancient scrolls that keep your OS from collapsing into madness.

🔥 Final Thought

Linux is powerful. It’s the forge of sysadmins and the playground of automation. But it’s also unforgiving. One command can tip it from order into chaos. So be kind to your root shell. Use your powers wisely. And never forget:

With great permissions comes great responsibility.