Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I accidentally executed the following command on the etc directory:

sudo chmod -R 700 /etc

I know that I have done something very wrong. My terminal now prints:

I have no name!@ubuntu: /$

How can I revert my etc directory to its earlier state?

I tried changing the permissions but it is failing now. Also, it would be very helpful if someone can explain what actually went wrong when I executed that command on etc. It was only file permissions. Then why does the whole system seems completely blown up? Why is it that no login passwords are working now? I know that there is a file in etc directory that has to do with users. But how did changing permissions jeopardize everything? Some technical details about this would be very helpful.

share|improve this question
You need a directory listing (ls -laR) from another running system. What version is yours? You can change directories to 755 and and files to 644, but some must have different modes (like /etc/shadow e.g.). –  ott-- Jul 23 '13 at 11:12
When you type sudo you should read it back in your head as "I am granting myself ultimate power over my system with no safety net, am I sure I know what I'm doing? Am I certain that I typed what I meant?" before pressing return. –  msw Jul 23 '13 at 12:07
With a working system, you can use find /etc -type d ! -perm 755 -exec ls -ld {} \; and find etc -type f ! -perm -644 -exec ls -l {} \; to find directories and files with non-standard modes. In Debian it's just 2 directories and 39 files –  ott-- Jul 23 '13 at 13:07
add comment

3 Answers

up vote 5 down vote accepted

One thing went wrong: the use of sudo with that command. The -R switch tells chmod to recursively set the permissions to that directory, which is, in every case, a non-recommended action (should we call it: heresy) if you don't know what are you doing (once this happened to me, I didn't issue the command but a faulty GUI made it, and my system went wire).

It was only file permissions. Then why does the whole system seems completely blown up?

GNU/Linux is very sensitive to file permissions, as it was built with stability and security in mind. Same applies to most programs run in GNU/Linux (i.e. apache2 drops root privileges and uses www-data, or similar user, and your 700 permission wouldn't allow it to read/write it own files).

Why is it that no login passwords are working now?

As you already mention, login passwords are stored in a file in /etc/passwd and only root (I assume you didn't change that) can read it, but the login prompt (or GUI login) uses a non-privilege account, hence it cannot read the file.

But how did changing permissions jeopardize everything?

Same as said above, Linux is very sensitive to file permissions. Some programs even check the permissions of their configuration files and if they are not expected they won't run at all.

How can I revert my etc directory to its earlier state?

If you use a RPM-based distro, this can be done using the rpm --setperms command, it would be painfully reverting one by one the packages, on Debian-like system apt-get --reinstall install is your friend. Other solutions may be available, but would need a working system for it.

share|improve this answer
+1 good explanation of the "whys" for newbies –  msw Jul 23 '13 at 12:04
add comment

Let's see, what you have done is set permissions in the whole /etc dir as read/write/execute allowed only for the owner of the file/dir, denied for everybody else. If you are confused by the file permissions, you can read more at Wikipedia: Traditional UNIX permissions.

The reason you have blown up your system is because many processes can't read their settings anymore, being unable to access /etc. It won't be easy to recover the entire /etc dir to its previous state. How to do that will depend on your distro, but basically it means reinstalling every package which holds any file within /etc.

As a quick band aid to be able to use the system, in order to fix it properly (reinstalling all the packages with contents within /etc, as stated above), you could do:

    # sudo find /etc -type d -exec chmod 775 '{}' \;
    # sudo find /etc -type f -exec chmod 664 '{}' \;

With those two lines you'll be setting liberal permissions in all the /etc dir, with read/write allowed for the owner and the group, and read allowed for everybody else. The reason of the two chmod is to set the execute bit only on dirs. Some processes will complain or fail even so, including any executable within /etc, but you should be able to do the reinstall I outlined above.

Please be aware than until you recover the original permissions your system will be, at the very least, in an insecure state.

share|improve this answer
Additionally, some programs won't work; SSH for example requires restrictive permissions on certain files. /etc/sudoers is another. –  Mel Boyce Jul 23 '13 at 11:51
But some files in /etc must not be made world readable ever! Restore from backups, that's why you have them (or, that's why people have been urging you to make backups). –  tripleee Jul 23 '13 at 12:49
add comment

700 has removed access to lots of files for groups and world users (e.g. files now have rwx------ permissions). For example, all users need to be able to read /etc/passwd. With your setup, only root can now read /etc/passwd. Many things will break if you break the permissions on files in /etc/ in unpredictable ways.

You could try and rebuild the permissions (assuming you can still switch to root) based on a working server, but that's prone to error.

I suggest restoring /etc/ from backup if you have one (making sure the restore puts the permissions back, or, if your backup solution supports it, restore just the permissions).

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.