Fix chmod 777 on All Linux Files: Restore Safe Permissions

Updated 6 November 2026 · Standard formula, shown below

If you ran chmod -R 777 / or a similar command and now every file and directory on your Linux system is world-writable, you need to restore safe permissions. The direct answer: you cannot reliably reverse the change with a single command, but you can rebuild correct permissions by reinstalling system packages (which resets their files) and manually fixing user data and custom scripts.

Why chmod 777 Is Dangerous

The permission string 777 means the owner, group, and everyone else have read, write, and execute permissions. For directories, execute means the ability to traverse into them. This effectively removes all access control. Any local user (or a process that gets compromised) can modify or delete any file, plant malware, or alter system binaries. It also breaks many services: SSH often refuses to work with world-writable home directories, and some daemons fail to start because they detect insecure permissions.

Running chmod -R 777 / recursively applies this to the entire filesystem, including system directories like /usr, /etc, and /var. The original permissions are lost because chmod does not store a backup. You must rebuild them from known sources.

What Exactly Got Changed

When you run chmod -R 777 /, every file and directory under the root gets mode 0777. This includes:

System binaries and libraries in /usr, /bin, /sbin, /lib
Configuration files in /etc
Logs and spool data in /var
Device nodes in /dev (though some are virtual)
Your home directory and all user files
Mount points like /mnt and /media (if mounted, the underlying filesystem may also be affected)

Note that chmod does not follow symbolic links by default, but it can change the permissions of the link itself (which is usually irrelevant). The actual target files are unaffected unless you used -L.

Step 1: Stop Using the System Immediately

If you haven’t rebooted yet, do not continue normal work. Every process that writes to a file now has full access, and any user on the system can modify anything. Shut down the machine and boot from a live USB (e.g., Ubuntu live installer) to perform repairs without the risk of the system overwriting files or being exploited.

If you must work on the running system, at least disconnect it from the network and log out all other users. But a live environment is strongly recommended because it gives you a clean slate and prevents the system from writing to its own files while you fix them.

Step 2: Restore System Files via Package Manager

On most Linux distributions, the package manager knows the original permissions of every file it installed. You can reinstall all packages to reset their files to the correct modes. This is the most reliable method for system files.

For Debian/Ubuntu (using apt):

Boot from a live USB and mount your root partition (e.g., sudo mount /dev/sda1 /mnt).
Chroot into it: sudo chroot /mnt (you may need to mount /proc, /sys, /dev first).
Run apt-get install --reinstall -o Dpkg::Options::="--force-confmiss" $(dpkg --get-selections | awk '{print $1}')

This reinstalls every installed package. It will take a while but will reset permissions for all files that belong to packages. For Fedora/RHEL, use dnf reinstall "*" or yum reinstall "*". For Arch, use pacman -Qoq | xargs pacman -S to reinstall all packages.

After reinstalling, also reset the permissions for directories that are not owned by any package, such as /home, /root, and /tmp. You can manually set them to standard values:

/home and /root: 755
/tmp: 1777 (sticky bit)
/var/tmp: 1777

Step 3: Fix User Files Manually

Files in your home directory (and other user directories) are not tracked by the package manager. You must decide what permissions they should have. A safe default for personal files is 644 (read/write for owner, read-only for group and others) for files, and 755 for directories. However, some files need to be executable (scripts, binaries) and some need to be private (SSH keys, configuration with secrets).

You can apply a reasonable baseline:

find /home -type f -exec chmod 644 {} \;
find /home -type d -exec chmod 755 {} \;

Then restore special permissions for known sensitive files:

SSH keys (~/.ssh/*): 600 for private keys, 644 for public keys, 700 for the .ssh directory.
Shell config files (~/.bashrc, ~/.profile): usually 644, but some users prefer 600.
Executable scripts: chmod +x for those that need to run.

If you have a backup of your home directory (e.g., from rsync or a backup tool), you can restore the permissions from that backup using rsync -a --perms or chmod --reference on a per-file basis.

Step 4: Check for Special Permissions and Ownership

Beyond the basic rwx bits, chmod 777 also clears setuid, setgid, and sticky bits. Some system files rely on these:

/usr/bin/passwd should be setuid root (4755).
/usr/bin/sudo should be setuid root (4755).
Directories like /tmp and /var/tmp need the sticky bit (1777).

Reinstalling packages will restore these for package-owned files. For manually installed software, you may need to set them again. Also verify ownership: chmod 777 doesn’t change ownership, but if you ran chown -R as well, you’ll need to fix that separately. Most system files should be owned by root:root.

Common Mistakes and Pitfalls

Rebooting before fixing: The system may fail to boot or login if key files are world-writable. Always repair from a live environment.
Forgetting /dev and /run: These are usually tmpfs (in-memory) and will be recreated on boot, but if you changed permissions on a mounted filesystem, you need to fix it there too.
Using chmod -R 777 / with a trailing slash: This affects the root filesystem itself. If you have separate partitions (e.g., /home on its own), you need to fix each one.
Assuming all files should be 644/755: Some files (like .htaccess or configuration files with secrets) should be more restrictive. Use the principle of least privilege.
Not checking for world-writable files after the fix: Run find / -perm -002 -type f to list files that are still world-writable. Investigate each one.

Prevention: How to Avoid This in the Future

The best fix is to never run chmod -R 777 /. Instead, use targeted permissions:

For a web server directory, use chmod -R 755 and chown to the appropriate user.
For shared directories, use group permissions and the setgid bit.
Use chmod 777 only on a single file or directory that genuinely needs to be world-writable, and only temporarily.
Consider using ACLs (setfacl) for more granular control.
Regularly back up your system, including permissions, with tools like rsync -a or tar --preserve-permissions.

Frequently Asked Questions

Can I just run `chmod -R 755 /` to fix it?

No. That would set every file to 755, which makes all files executable (a security risk) and doesn’t restore the original modes. It also breaks files that need to be 600 (like SSH keys) or setuid. You must restore permissions from a known source (package manager or backup).

What if I don’t have a backup?

You can still recover system files by reinstalling packages. For user files, you’ll have to set reasonable defaults manually. If you have no backup and no package manager (e.g., a custom compiled system), you may need to reinstall the OS and restore user data from a backup.

Will reinstalling packages delete my configuration files?

Reinstalling packages with apt-get install --reinstall typically keeps your configuration files (unless you use --force-confmiss which replaces missing configs). However, it may reset permissions on config files, which is what you want. Your custom changes to config files are usually preserved.

How do I know which files are still world-writable after the fix?

Run find / -type f -perm -002 to list files that are writable by others. Also check directories with find / -type d -perm -002. Review the list and fix any that shouldn’t be world-writable.

Is it safe to use the system after fixing only system files?

Not fully. Your user files and any manually installed software may still have insecure permissions. You should fix those as well before considering the system safe. Also check for any processes that might have been compromised while the system was world-writable.

Can I restore permissions from a live CD using `dpkg --set-selections`?

Yes, that’s a common method. After chrooting, you can use dpkg --set-selections to reinstall all packages. The command I gave earlier does that with apt-get. For a more direct approach, you can use dpkg --configure -a after reinstalling, but the reinstall command is the key.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.