Recovering from Accidental chmod 777 on Linux

Setting chmod 777 on the wrong directory is a rite of passage for Linux developers. I once ran chmod -R 777 / during a late-night debugging session and learned a painful lesson about the importance of double-checking commands. This post covers how to recover and prevent this from happening again.

Environment

• OS: Ubuntu 22.04 LTS
• Damage scope: Recursive chmod 777 on /home directory
• Impact: SSH login failures, application crashes, security exposure

# The command that caused the problem (DO NOT RUN THIS)
$ sudo chmod -R 777 /home

The Problem

Immediately after running the command, multiple services broke:

$ ssh admin@server
Permissions 0777 for '/home/admin/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
Bad owner or permissions on /home/admin/.ssh/id_ed25519

# Web server started returning 500 errors
$ curl -I http://localhost
HTTP/1.1 500 Internal Server Error

# Applications couldn't write to their directories
$ systemctl status myapp
● myapp.service - My Application
     Active: failed (Result: exit-code)
     ...
Jul 10 22:15:01 server myapp[1234]: Error: EACCES: permission denied, open '/home/admin/app/config.json'

Analysis

Step 1: Assess the Damage

# Check what was affected
$ find /home -type f -perm 777 | head -20
/home/admin/.ssh/authorized_keys
/home/admin/.ssh/id_ed25519
/home/admin/app/config.json
/home/admin/app/secrets.env
/home/admin/app/data/production.db

# Check directories too
$ find /home -type d -perm 777 | head -20
/home/admin
/home/admin/.ssh
/home/admin/app
/home/admin/app/data

Step 2: Understand Permission Requirements

Different file types need different permissions:

Step 3: Check What Cannot Be Fixed Simply

The SSH key issue is the most immediate problem:

$ ls -la /home/admin/.ssh/
-rwxrwxrwx 1 admin admin  570 Jul 10 22:00 authorized_keys
-rwxrwxrwx 1 admin admin 2655 Jul 10 22:00 id_ed25519
-rwxrwxrwx 1 admin admin  570 Jul 10 22:00 id_ed25519.pub

Solution

Step 1: Fix SSH Access Immediately

If you still have console access, fix SSH permissions first:

# Fix SSH key permissions
$ chmod 600 /home/admin/.ssh/authorized_keys
$ chmod 600 /home/admin/.ssh/id_ed25519
$ chmod 644 /home/admin/.ssh/id_ed25519.pub

# Fix .ssh directory
$ chmod 700 /home/admin/.ssh

# Test SSH
$ ssh admin@localhost
# Should work now

Step 2: Restore Permissions Using Package Manager

For system files, reinstall packages to restore original permissions:

# Find which package owns a file
$ dpkg -S /etc/passwd
passwd: /etc/passwd

# Reinstall to restore permissions
$ sudo dpkg --force-all -S --reinstall passwd

Step 3: Use Reference System for Permissions

If you have access to another identical system:

# Export permissions from reference system
$ find /home -type f -exec stat -c '%a %n' {} \; > permissions.txt

# Apply on damaged system
$ while read perm file; do
    if [ -f "$file" ]; then
        chmod "$perm" "$file"
    fi
done < permissions.txt

Step 4: Set Correct Permissions Recursively

# Home directory structure
$ chmod 755 /home/admin

# .ssh directory and contents
$ chmod 700 /home/admin/.ssh
$ chmod 600 /home/admin/.ssh/*
$ chmod 644 /home/admin/.ssh/*.pub

# Application directories
$ find /home/admin/app -type d -exec chmod 755 {} \;
$ find /home/admin/app -type f -exec chmod 644 {} \;

# Sensitive files (secrets, configs with passwords)
$ chmod 600 /home/admin/app/secrets.env
$ chmod 600 /home/admin/app/config.json
$ chmod 600 /home/admin/app/data/*.db

Step 5: Fix Specific Application Permissions

# Web server (nginx/apache)
$ sudo chown -R www-data:www-data /var/www/html
$ sudo find /var/www/html -type d -exec chmod 755 {} \;
$ sudo find /var/www/html -type f -exec chmod 644 {} \;

# Database files
$ sudo chown -R mysql:mysql /var/lib/mysql
$ sudo chmod 700 /var/lib/mysql

# Log files
$ sudo find /var/log -type f -exec chmod 640 {} \;

Step 6: Verify and Create a Recovery Script

#!/bin/bash
# /usr/local/bin/fix-permissions.sh

echo "Fixing home directory permissions..."
chmod 755 /home/admin
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/id_*
chmod 644 /home/admin/.ssh/*.pub
chmod 600 /home/admin/.ssh/authorized_keys

echo "Fixing application permissions..."
find /home/admin/app -type d -exec chmod 755 {} \;
find /home/admin/app -type f -exec chmod 644 {} \;
chmod 600 /home/admin/app/secrets.env
chmod 600 /home/admin/app/config.json

echo "Fixing system directories..."
chmod 755 /var/www/html
chmod 644 /var/www/html/*

echo "Permission recovery complete"

Prevention Strategies

Use Alias for Dangerous Commands

# Add to ~/.bashrc
alias chmod='echo "Use full path. Type yes to confirm:" && read confirm && [ "$confirm" = "yes" ] && command chmod || echo "Cancelled"'

Use chmod with --no-preserve-root Safety

Always be explicit about what you are changing:

# BAD: Recursive on broad path
$ sudo chmod -R 777 /home

# GOOD: Specific target
$ sudo chmod -R 755 /home/admin/app/static

Set Up a Permission Backup Cron Job

#!/bin/bash
# /usr/local/bin/backup-permissions.sh

TIMESTAMP=$(date +%Y%m%d)
find /home /etc /var -type f -exec stat -c '%a %U %G %n' {} \; | \
    gzip > /backup/permissions-${TIMESTAMP}.tar.gz

# Keep only last 7 backups
find /backup -name "permissions-*.tar.gz" -mtime +7 -delete

Lessons Learned

1. Always double-check recursive commands - especially chmod, chown, and rm with -R.
2. Never run chmod 777 on any directory - it is almost always a security risk.
3. Keep console access available when making permission changes on remote servers.
4. Maintain a permissions backup that can be restored quickly.
5. Use principle of least privilege - grant only the minimum permissions needed.

This blog does not accept any external sponsorships, affiliate marketing, or ad revenue.