Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I was working and there was a directory that I was periodically changing to my user in a root terminal so that I could open the files in text editors, but I accidentally pressed / instead of . and this was the command I put out:

chown -R emil.emil /

Then immediately panicked ^C and put in another command, as I thought I could always change back the files I needed to access:

chown -R root.root /

So now I can't do su from emil to even try to fix this, as I'm getting permission denied error. I'm on Ubuntu could someone tell me if there is a way I could fix this, without absolutely reinstalling the whole thing.


If you are trying to get root access, and are getting this permission denied error when using su try this command:

gksu gnome-terminal

It will prompt you for the root password and open a new root terminal for some reason this works and gives me root access, when su doesn't.

share|improve this question
A bootable CD will get you started, but you've got a mess on your hands even then.... – retracile Feb 17 '12 at 3:16
To try and avoid this in future, you could try getting used to using chown -R $PWD or chown -R ~+ (at least if you forget the + you've only messed up the home dir). – Sirex Feb 17 '12 at 8:30
up vote 5 down vote accepted

The filesystem descending from / has a variety of ownership permissions in order to achieve different things.

The fix you attempted makes root the owner of everything, and so for many operations (including accessing files under /home/emil) root is the only user that will work.

So your options are:

  1. Restore from backup
  2. Reinstall
  3. Boot into single user mode and manually apply the correct owner to each file

I'll assume 1. is off the table, and 2. is not a preferred option.

In the Grub menu when you boot Ubuntu, you should have a recovery option at boot time. If you don't see the grub menu (this comes up before anything else after the bios) then hold down the left Shift and it will appear. Choosing this will boot into single user mode, where you are logged in as root.

From there you can begin to change ownership. The first thing would be

 chown -R emil /home/emil

Which will make you the owner of your own files. For the remainder, you may want to do an installation on another machine to compare file ownership, or start each service that you use in /etc/init.d and watch for reasons for failing (note that a service may fail simply because it is unable to write its logs to /var/log and so cannot even provide error reporting).

This would be an extremely time consuming process, but does get around re-installation. Note that any personal configuration you have made to Ubuntu and application settings will be stored in the /home/emil heirachy so copying these files somewhere else, re-installing the OS and applications, and copying them back is a far quicker option.

share|improve this answer
Paul, I tried rebooting into recovery mode but once the screen opens up my keyboard does not work so I was not able to get the root terminal that way. However I figured out a weird way to get root terminal, using gksu gnome-terminal for some reason this works and gives me a root terminal which I used to chown my home directory, however I still can't su into root, still getting permission denied. – Emil Feb 17 '12 at 4:56
@Emil yes, this is is expected. Fixing the ownership of your home directory is step one of about 1000 steps. Now that you have a root session though, you can work out all the other ownerships that need to be fixed in order to restore functionality, as above. – Paul Feb 17 '12 at 5:06
Yeah, this sucks I will probably have to reinstall, anyway thanks for the help. – Emil Feb 17 '12 at 5:12
A reinstall would probably be less time-consuming than finding and fixing all the incorrect ownerships. – Wyzard Feb 17 '12 at 6:21

If you have a similar system at hand, you could use find to figure out the correct owner and group for each file, e.g. using:

find / -printf "%u:%g %p\n" > permissions.txt

which will produce output like the following:

root:root /
root:root /usr
root:staff /usr/local
root:staff /usr/local/man
root:staff /usr/local/games
root:staff /usr/local/lib
root:staff /usr/local/lib/python2.7
root:staff /usr/local/lib/python2.7/dist-packages
root:staff /usr/local/lib/python2.7/site-packages
root:staff /usr/local/lib/python3.2

You could then iterate through this and chown each file to its original owner and group.

while read line
    chown $line
done < permissions.txt

I doubt this will fix everything perfectly since permissions and files differ between systems, but it is a start and should at least get the base system back to the defaults

share|improve this answer
Just a small note. It should be ' chown '$line' ` Otherwise if $line has spaces it will break the name into two files instead. – Abhishek Gupta Mar 22 '14 at 15:36
My saviour :) Thanks! Worked like a charm with /etc/ only, it fixed all my issues. – diosney Nov 18 '14 at 15:41
It worked for me but without wrapping in quotes; I just have few more folders left /var/lib/mysql but now I have chowned them recursively and all fixed for now – Nitroxis Sep 18 '15 at 10:01

I'm more familiar with Fedora, but my suggestion would be to boot from a live CD and copy your data off the machine and re-install.

You could potentially use the package manager (apt/dpkg) information to figure out what the ownership of all the files on the system are supposed to be. I could figure out how to do that with rpm, but I'm not that intimately familiar with apt/dpkg. Any enhanced security such as SELinux may also complicate matters.

rpm -qa --list -v gives the required information on an rpm-based system, which you'd have to parse and feed to chown. If you can find the equivalent for apt/dpkg you can get there.

share|improve this answer
Oh, and you may also need to deal with sticky bits; I suspect chowning /bin/su may clear its sticky bit. – retracile Feb 17 '12 at 4:31

You must log in to answer this question.

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