How to reset folder permissions to their default in Ubuntu?

Question

I recently typed the command

sudo chmod 777 -R /

after that some things like

sudo -i

are not working normally. So I am wondering if there is any way I could reset the folder permissions to their original state?

Answer 1

It is possible to come back from this messy situation.

I ran again the same kind on issue (some bug in a script I was writing) and solved it, but you need to ask some expert's help. Be very cautious!

First, my situation was easier to solve because I had a dual boot system (Ubuntu and my old Fedora install), but running the OS from a CD/DVD, or an USB key should do the same thing.

MPOINT=/mount/ubuntu

First I mounted my file systems like this (don't forget to create the mount points):

mount /dev/ubuntu/root $MPOINT
mount /dev/ubuntu/home $MPOINT/home

Then I ran the following command (my issue was only in a few - critical - directories) to copy the permissions on from the running system to the messy one (in fact, in my case, I installed an Ubuntu system in Virtual Box under fedora and got the permissions there):

find /etc /usr /bin /sbin -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > /tmp/restoreperms.sh

And then I ran the restoreperms.sh script.

I was able again to boot on Ubuntu.

The content of restoreperms.sh will be something like:

(...)
chmod 755 /mount/ubuntu//etc/ppp
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up
chmod 2750 /mount/ubuntu//etc/ppp/peers
chmod 640 /mount/ubuntu//etc/ppp/peers/provider
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up.d
chmod 777 /mount/ubuntu//etc/ppp/resolv.conf
(...)

I didn't test it but it must work for owners and owner groups too. Something like:

find /etc /usr /bin -exec stat --format 'chown %U:%G ${MPOINT}%n' {} \; > /tmp/restoreperms.sh^

(...)
chown root:root /mount/ubuntu//etc/obex-data-server/imaging_capabilities.xml
chown root:root /mount/ubuntu//etc/obex-data-server/capability.xml
chown root:dip /mount/ubuntu//etc/ppp
chown root:root /mount/ubuntu//etc/ppp/ipv6-up
chown root:dip /mount/ubuntu//etc/ppp/peers
chown root:dip /mount/ubuntu//etc/ppp/peers/provider
chown root:root /mount/ubuntu//etc/ppp/ipv6-up.d
chown root:root /mount/ubuntu//etc/ppp/resolv.conf
(...)

Of course, you have to take care here, that the UID and GID are the same on both systems, but for the system related users and groups, this shouldn't be an issue.

Edit:

Also, setting owner will nullify SGID and SUID flags, which causes weird problems (For example, you won't be able to perform sudo unless the permission is 4755). You must, and should only set permissions AFTER setting owners. DO SAVE complete file permission information along with owner information.

Rk:

1. An important thing for this is to keep an install disk synchronized with the version you are using, or at least work with the current ubuntu version.

2. Now, I have this commands in a cronjob, running every day (could be weeks) in order to keep that information. It will make the solution easier next time but, of course, as I have this now, it will never happen again. ;-) Something like this:

   0 12 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chmod %a %n" {} \; |/bin/bzip2 -c > /tmp/restore_chmod.$(/bin/date +%w).sh.bz2

   0 13 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chown %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_chown.$(/bin/date +%w).sh.bz2

The right (combined) command is more something like:

`/usr/bin/find / -exec /usr/bin/stat --format="[ ! -L {} ] && /bin/chmod %a %n" {} \; -exec /usr/bin/stat --format="/bin/chown -h %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_fileperms.$(/bin/date +%w).sh.bz2`

Note that additional care may be required to account for parentheses in filenames (under locales, for instance) and that chown may silently unset setuid and setgid bits set by chmod. In the latter case, which would break, say, /bin/su and /usr/bin/sudo, you may need to swap the order of exec clauses above.

Answer 2

After recover sudo or selecting recover mode at the boot

It's possible to recover a whole system using debsums that verifiy file integrity and permissions.

from the man page:

apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u)

Reinstalls packages with changed files

or limited to a specific path eg: /usr:

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/usr ) | cut -d : -f 1 | sort -u)

or limited to a multiple set of path eg: /sbin /etc /var

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/etc -e ^/sbin -e ^/var  ) | cut -d : -f 1 | sort -u)

Answer 3

Always watch what you run as sudo.

This thread explains that you can manually set some permissions back, and a script there helps with this, but still it's a big job. Rather follow the tips in the tread to save your installed packages (markings) and reinstall the OS, and apply your saved packages markings to get your applications back.

Answer 4

As far as I know, only System V packages and RPMs offer a command to repair file permissions. On System V (Solaris) it is pkgchk, with RPMs it is rpm --setperms.

Unfortunately, no such command seems to exist for Debian / Ubuntu packages - but I might be wrong here.

But even with the help of these commands, it's not a trivial task to bring your system back to a sane state, and by repairing it, you can easily cause new harm to your system - if you're not careful.

Other than Joseph said, you're not the first one, and you will not be the last one to enter such a command. But the idea alone, to change file permissions to 777 on a Unix system, is a strong indication that you're not very experienced with this kind of system. The best you can do in this situation is to backup what you will need again (home directories, configuration files, mail files?), and try a fresh install.

And you should be very, very careful, when you restore your - damaged - backup files.

Good luck!

P.S.: I'm just wondering what kind of problem you wanted to solve?

Answer 5

Wow, you killed it. It's dead! Try logging in and using the machine as root (since you enabled it), then change the group membership of root to users. This may or may not work because I've never tried it before but its worth a shot.

Answer 6

You can't undo a chmod operation; at least not in the sense of rolling back to a previous setting, which is what this situation calls for.  Arguably, you can undo a chmod operation, by chmoding each file and directory back to its original mode –– but they’re not all the same; determining the original modes is tricky (as discussed in the other answers).