Recovering from Unintended Recursive chmod on System Directories: Steps and Precautions

When tinkering around in the command line terminal of your Linux system, it is important to be aware that a small mishap can have dire consequences. Most Linux commands are not very forgiving, and there is often not an easy way to “reverse” a command after it has been run, especially on a large batch of files. The chmod command is one such command that users need to be wary of, as unintentionally changing the file permissions for system directories is not reversible, except through a slow, manual process.

The chmod command allows users to change the permissions for an entire directory of files with use of the -R (recursive) option. If you erroneously specify the wrong directory in your command, it could affect many thousands of files in a matter of seconds. This is especially damaging if run on important system directories, such as /etc or, even worse, the root directory. You will likely begin encountering many system errors and security issues if such a change occurs.

In this tutorial, we will discuss recovery from unintended recursive chmod on system directories for Linux. We will also go over several tips and recommended habits that you should adapt in order to save yourself from accidentally damaging your system in the future because of executing the wrong command or a simple typo. After all, it is better to learn things the easy way instead of breaking your system to learn a lesson the hard way.

In this tutorial you will learn:

  • How to recover from unintended recursive command execution
  • Tips and tricks for avoiding disaster
Recovering from Unintended Recursive chmod on System Directories: Steps and Precautions
Recovering from Unintended Recursive chmod on System Directories: Steps and Precautions
Software Requirements and Linux Command Line Conventions
Category Requirements, Conventions or Software Version Used
System Any Linux distro
Software chmod
Other Privileged access to your Linux system as root or via the sudo command.
Conventions # – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command
$ – requires given linux commands to be executed as a regular non-privileged user

Recovering from Unintended Recursive chmod

If you have already run an unintended and recursive chmod command, then the damage is already done. This can be especially problematic depending on which directory you ran the command. For example, running the recursive command on root / or the /etc directory is going to have disastrous effects from which it is impossible to recover.

The only conceivable way to restore file permissions in such a scenario would be to analyze the permissions for a clean installation, and then manually copy over those same permissions on a file by file basis for your current install. This is not a feasible solution and anyone will tell you that you are much better off with just reinstalling the system.

Reinstalling the system will not be difficult if your /home directory is on a separate partition. In this case, your new install’s /home directory can be pointed to the existing /home partition and will retain all of your personal files. On the other hand, if you have everything on a single partition, then it will be necessary to back up all of your personal files before performing a clean installation.

Bottom Line: Performing a new installation and transferring your personal files to the new system is the most time efficient and fool proof method for recovery.

Tips and Tricks for Avoiding an Accidental Recursive Command

A Linux installation is pretty easy to destroy, at least by users with root (sudo) permissions. If you run an unintended recursive command on a system directory, and it had some ill effects, then that means you were not careful enough with your root permissions, or chose to delegate these permissions to users that were not prepared to wield that level of power.

Remember the warning prompt that appeared the first time you used the sudo command?

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Take what happened as a learning lesson. To ensure that history does not repeat itself, there are a few ways we can prevent these unintended commands from being executed and wreaking havoc on our Linux installation.

Separate your partitions

As discussed earlier, system reinstalls are much easier when the /home directory is kept on a different partition. This is where all personal files are supposed to go. Anything on the system partition is usually and mostly replaceable, as this space contains operating system files and programs. Therefore, reinstallation of the system and applications is not that big of a deal.

This tip will save you time and headaches in case you mess up your system in the future. You will not have to do a full system recovery, thanks to your personal files residing on the separate partition.

Experiment in a virtual machine

If you are at all unsure of a command that you are about to execute, test it out in a virtual machine. Virtual machines are easy to clone, so even if you ruin one completely, you can just jump back to the original – no harm done. All Linux administrators and those who love to tinker with their system should have a virtual machine handy for testing commands on. Better to ruin the VM than your main system.

Set up command aliases

The chmod actually has a built in option to prevent operating on the root directory:

$ sudo chmod -R --preserve-root 750 /
chmod: it is dangerous to operate recursively on '/'
chmod: use --no-preserve-root to override this failsafe

Here, we attempted to run chmod on the root directory to change all file permissions to 750, recursively. As you can see from the command output, the chmod command failed to run, thanks to using the --preserve-root option. Had we not used this option, the command would have succeeded (and destroyed the system).

If you think that you may accidentally operate on the root directory, then include the --preserve-root just to be safe. An even better solution is to set up aliases so that this option is passed to chmod automatically.

We can set this up by editing the users ~/.bashrc file.

$ nano ~/.bashrc

Append the following lines to the end of the file:

alias sudo='sudo '
alias chmod='chmod --preserve-root'
alias chown='chown --preserve-root'
alias chgrp='chgrp --preserve-root'

Note that the first line will allow the sudo command to run aliases. The following three lines will make it so that the chmod, chown, and chgrp commands automatically add the --preserve-root option to every future execution.

These settings will take effect in all new terminals, or type the following to activate it in your current session:

$ source ~/.bashrc

Another way to prevent executing commands on the root partition is to avoid appending directories with the / character. For example, executing commands on . and ./ has the same effect, but only one of these (the latter) is one character away from causing disaster. Had we accidentally missed typing the . character, then the command would be run on root instead of the present working directory.

Closing Thoughts

In this tutorial, we learned that the best way to recover from an unintended recrusive chmod on a Linux system is to simply reinstall the operating system. To keep these mistakes from happening in the future, we must always remember the warning prompt that shows when running sudo for the first time (see above). We also covered several other tips and tricks that can be used to minimize the chance of running a disastrous command on your system.

Comments and Discussions
Linux Forum