3

I recently made something very, very stupid. Instead of typing: chown adam ./* I wrote: chown adam /* (I forgot about the very important dot). Now I have some files with owner adam instead of... hmm I don't really know who. I can't even call su and login as root because I get: su: cannot set groups: Operation not permitted. I am able only to run my Arch Linux cd, run it in EFI mode, login as root and call arch-chroot /mnt, where under /mnt my main Linux partition is mounted. The situation is bad but not terrible. Is there any way to restore my system?

6
  • 3
    I would start with sudo chown -R root /bin /sbin /lib /usr /sys /boot /etc /dev from inside the chroot - This should get you a bootable system, but I'm not 100% sure. Might want to wait for someone to confirm that this won't make the situation worse. Aug 30, 2012 at 16:38
  • Thank you very much. Darth Android tip worked for me. @Daniel: Thanks, I will get familiar with that.
    – Yob
    Aug 30, 2012 at 16:47
  • Just curious, why not chown ... *? Skip the / completely?
    – Daniel Beck
    Aug 30, 2012 at 17:03
  • @DanielBeck +1, this will help prevent a recurrence of this issue. Aug 30, 2012 at 17:11

1 Answer 1

5

I would start with sudo chown -R root /bin /sbin /lib /usr /sys /boot /etc /dev from inside the chroot - This should get you a bootable system, but I'm not 100% sure. Might want to wait for someone to confirm that this won't make the situation worse.

Note, if you simply chown'd the files, you're in a much better position than someone who chmod'd or chgrp'd their system. Most files on a single-user system (i.e., used just by you) are either owned by you (in /home/username) or owned by root. There might be a few weird files in /var and there are definately some in /run and /tmp which are owned by the services that created them. Try sudo chown root /var /run /tmp (note the lack of -R) for those directories.

You will probably then want to wipe out the /run and /tmp contents (sudo rm -rf /run/* /tmp/* - Be very careful that this is typed correctly), since they are transient and rebuilt by applications when the system is restarted, and this is much easier than trying to track down the owners and fix that.

/var is going to be a complicated mess. Many daemons expect to be able to write there (mysql, apache, etc.), and have folders nested inside. It's safe to reowner the the top-level contents (sudo chown root /var/*), but the stuff in the folders needs to be restored carefully. You might look in the live-cd's /var folders for some hints.

You must log in to answer this question.

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