I was going to change the ownership of a directory to apache:apache, but I ended up running:

chown -R apache:apache /

Bad! Very bad! I knew what was going on when it started saying:

chown: changing ownership of `/proc/2694/fd/48': Permission denied

That's when I stopped everything (Ctrl+C).

The current system I have is a server running virtualbox running CentOS 5. This problem happened inside the VM.

Currently, everything seems to be working, but I have not restarted the system yet, and to be honest, I'm afraid that if I did something will break.

I do not know chown's order, should I be concerned and assume something will break after a reboot? Is there a way to recover form this problem without having to rely on backups? I do have a daily one, but I thought there may be a simpler way out.


It would be good to have an old backup, but IMHO it would suffice to be able to extract the ownership data.

I would it do this way:

  • First, make a backup of the current state.

  • Then, restore the original properties according to the RPMDB. This will probably repair a lot of your files

  • To identify and repair the remaining ones, find all files which are still subject to this problem. These are the files which belong to apache:apache and are in the "search order" before /proc . Maybe you do

    ls -U /

    first and get the list of root level entries before /proc (I suppose this is where you canceled the process).

    Then do a

    find /foo /bar /baz -user apache -group apache

    replacing foo, bar, baz with the entries identified before. Redirect find's output to a file.

  • Extract all the ownership data of the given files from the backup and apply them to the files.

  • Thanks, very useful info. ls -U listed sbin etc before proc. – Christian Apr 10 '12 at 11:30
  • @ChristianSciberras Only these two? Then it won't probably be very hard... – glglgl Apr 10 '12 at 11:34
  • @glglgl: I play Starcraft II and your username was a perfect ending to that comment. – gparent Apr 10 '12 at 13:59
  • After a while, I realized /bin was also modified. It works perfectly now. I'm marking this as the answer since it's much more detailed and practical. Thanks. – Christian Apr 10 '12 at 14:58

rpm --setugids will restore ownership for the packages passed to it. Pass -a to restore all packages. You may also need --setperms to restore setuid/setgid permissions.

  • That's all there is to it? – Christian Apr 10 '12 at 11:07
  • 1
    Well, it can't help you with files that aren't in the rpmdb. Those you'll need to handle yourself. – Ignacio Vazquez-Abrams Apr 10 '12 at 11:08
  • But how do I know which ones to change? What if the machine won't reboot (what are my options then)? – Christian Apr 10 '12 at 11:09
  • "Restore from backup" and "Make note to create a snapshot before making major changes to a VM" are notes I've learned to memorize. – Bart Silverstrim Apr 10 '12 at 11:10
  • It wasn't really a major change. :) – Christian Apr 10 '12 at 11:12

In all honesty it's easiest to schedule a proper restore from your last backup at this point. Fortunately you can still do another, final, backup to preserve your current user data; then restore your old backup, and finally restore your user/customer data from your final backup, making sure you preserve the permissions of each group of files as you do so.

  • 3
    I always cringe at questions like these because they're almost certainly asked by people who don't have backups. – Jeff Ferland Apr 10 '12 at 13:45
  • 1
    I do have a backup, but I'd rather not loose employees work of the last 2 days. – Christian Apr 10 '12 at 14:57
  • @JeffFerland By the way, I specifically mentioned in my question that I did have a backup... – Christian Apr 10 '12 at 15:06

Since you're one of the lucky smart enough folks to have implemented a daily backup, here's what I suggest:

If you can access your backup catalog directly, you can use that to scrape permissions off all the files. Bacula, for example, stores the metadata in a database and file data can be viewed using SQL queries.

It is also possible to restore all your files to a separate location and read the filesystem from there to determine the appropriate permissions.

For each file on the system you have clobbered with chown (find / -user apache -group apache), check for the corresponding file on your backup. If it exists, restore the user and group. If it doesn't exist, flag it for later review and move on.

This process will keep all your data current and prevent clobbering a day or two worth of work. The RPM database permissions restore is a good idea, but where you have backups you can accomplish a greater degree of the work in one pass.

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.