5

Possible Duplicate:
How do I recover a RHEL 4.3 server from bad permissions set over the entire filesystem?

Is there any way to restore the default ownership of a CentOS filesystem after an accidental chown -R user:group /* ?

Before I go and reinstall, I thought I'd ask and perhaps save some time. I'm in the process of setting up a new dev machine (thankfully not prod) and typed too fast or missed the . key or something. I tried to cancel as soon as I caught it but all my /bin /boot /dev etc had already been changed.

Is there hope, or just reinstall and be happy it wasn't a production machine?

2
  • 2
    This one has been asked a bunch, kind of disconcerting actually :-) May 14, 2010 at 15:58
  • 2
    Hopefully you have good backups of your production machines. So if something like this does happen all you have to do is restore.
    – Zoredache
    May 14, 2010 at 16:31

4 Answers 4

10

"Just reinstall and be happy it wasn't a production machine?"

Yes.

9
rpm -a --setugids
3
  • I used this, worked like a charm, but some specific folders didn't change, I had to take care of them manually.
    – aliep
    Sep 20, 2017 at 6:28
  • Also had to use this and it works up to a point. I had to manually reset the owner of files in /var/log and also /var/lib/mysql (mysql user) and erase a lock file for postfix. Most importantly, setuid,sticky settings were removed. I had to reset the setuid bit on /usr/bin/sudo and the sticky bit on /var/spool/postfix/maildrop.
    – Gerrit
    Aug 8, 2019 at 8:58
  • Also setuid: /usr/bin/passwd
    – Gerrit
    Oct 25, 2019 at 16:20
2

If you happen to have an exact clone of that machine, it is possible to restore permissions using the other machine as a model. Something like:

server1:# find / /usr /home -xdev | xargs getfacl -Pp > /tmp/permissions_from_server1


server2:# setfacl --restore=/tmp/permissions_from_server1
  • -xdev tells find to stay on one filesystem.
  • The upper-case -P stands for Physical walk; i.e.: ignore symlinks.
  • The lower-case p preserves leading slash. Without this switch, getfacl's default behavior is to remove the leading slash, causing the restore fail.

YMMV, here's a starting point.

1

Reinstalling is ultimately easier, and is the route I would take. If this were a production server and you didn't have backups, your first task would be regaining root privileges, as /bin/su and /usr/bin/sudo may not work any longer.

Log in locally, as root, reset the ownership of those binaries, and start working on the errors you immediately see crop up, such as libraries not working, etc.

From a similar machine, you could build a list of files in various system directories with a shell/Perl/Python script, and then run the script in reverse on the affected system, to grant proper ownerships to the files.

It's not the end of the world, although pretty close, and it's a huge pain in the bum.

Not the answer you're looking for? Browse other questions tagged .