I accidentally performed the command chown -R root / while trying to change the permissions to the public folder of my rails app. I believed this changed the permissions to all my folders on the / directory. So my question is, how dangerous is this, in fact the better question would be, is there anyway to undo this?

  • 3
    This cannot be undone automatically, and yes, it has a significant impact on your system (including, but not limited to, the various home directories). I hope you have a recent backup handy. Good luck. – Frédéric Hamidi Feb 18 '13 at 16:33
  • There are programs that check your system for appropriate permissions and file ownership. I think tripwire is or was an early one. If you don't have multiple users you may be able to salvage the situation just by getting a report and/or fix from such a tool. – minopret Feb 18 '13 at 16:45
  • Also read the great advice below that amounts to "don't react in any way that would make it worse" and "don't assume the worst". Or remember these important general troubleshooting steps using the joke version: Emergency operator: "Don't panic, are you sure your friend is dead?" Caller: BANG "Yes, sadly, he's dead." – minopret Feb 18 '13 at 16:48
  • In most cases, on a normal system, you should be able to tell from the group of a file who the owner should be. So find all files that are owned by root where the group isn't appropriate, and chown them all to the user that matches the group. Log failues, and deal with them on an individual basis. – agf Feb 18 '13 at 22:17
  • Have you run that command as root? (I hope not...) – Axel Feb 18 '13 at 23:34

One way to mitigate the issue here (not resolve, but help you out of a hole) is to run a process on a similar system to collect the appropriate ownerships for the files. I appreciate the chances of an exact match are somewhat slim, but if both the o/s's are at the same level with similar packages installed you might be lucky.

Once you have collected the file permissions into a file, you could then run a process on your own system to read the files and perms/ownerships from the good one and replace them on yours. I have a couple of small home-grown apps on Linux that do just this.



RWX * UID * GID * other stuff * directory * filename


First of all, stop the command if it is still running!

Now everything will belong to root and that is quite problematic.

You should try to restore information from your latest backup.

It is also important not to restart the system before checking all the applications running and the user launching them on boot. If you do, some of them may not start properly due to permissions problems.

Good luck.


Very and not quite.

"Very" in the sense that if the command has indeed gone through, your security is screwed. You now do not know which paths have what owners and who should be allowed to do what.

"Not quite" in the sense -- are you sure you were root when you did it and did the command go through to the end? If you've cancelled it, as soon as you saw it, then you might be lucky and the repair may be low. If you weren't root, this command shouldn't have been able to do it, unless you did something like sudo ....

There is no single remedy to this. If you have a backup, you can restore to it. You might need to check the ownerships in the backup and apply them. If you have been using a rootkit (say rkhunter) checker, it might have a list of the most basic ownerships and possibly be able to fix it. (Not quite likely).


On Fedora at least, the RPM command has the options --setperms and --setugids, using those you can fix most of the system owned files like rpm --setugids -a. To (somewhat) fix the files for each user, you can do for each one chown -R user /home/user. There probably will be leftovers that haven't been fixed by the above, particularly if you have some sort of server (web, ftp, others), those will have to be handled one by one.

Probably other distributions have similar mechanisms. Or do a full refresh (i.e., install everything anew, like it was somehow damaged. OK, it was somehow damaged.)

[Yes, this is yet again Unix' rather cruel way of teaching unsuspecting users to consider each command carefully before pressing ENTER, and to use root sparingly. Consider yourself taught.]

  • setuid and setgid permissions need to be set by hand. rpm won't restore them. – jnas Apr 18 '16 at 11:33

If your using OSX apple provides a restore feature within Disk Utilities to fix this very problem. If your using a linux distro, I'm fairly certain you'll have to redo all permissions manually. In either case, smack your hands and don't do it again

  • It's probably unlikely to be able to recover fully from this on Linux. Even if you can get the system working, you probably missed something that may come back to bite you later, either as instability or a security vulnerability. I would say that a restore from backup or rebuild approach is probably necessary. – Chris Kuehl Feb 18 '13 at 21:37

Unfortunately I don't know of any way to "undo" it, but you can probably leave system files as owned by root and restore all the files in your $HOME to be owned by you (and do the same for all users of the system). At that point you can fix permissions and/or owner on each file not in your $HOME directory that needs it as it comes up. Yes this is a pain, but I don't think there's an easy fix. That is what I would do anyway.


I'd say that you are pretty "screwed" as you say. The best way (and most efficient) is to reinstall and restore critical items from your good backups. Sorry this is not a situation that generally has a quick fix with a happy ending. Good Luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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