20

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?

3
  • I don't think linux remembers previous permission settings. Try making a new file and look at what permission settings it gets.
    – thecoshman
    Apr 20, 2010 at 9:43
  • Oh wait, I see what you did there. This is probably a re-install situation. Just back up your data, make note of what applications you have installed. Have fun, why not try 10.4! (best name ever btw... what that radio thing mean?)
    – thecoshman
    Apr 20, 2010 at 9:47
  • 1
    I dare you to find one person who hasn't done that exact thing :D it's a very tricky situation. you can fix it, try jlovi's answer but it'll take time and effort and it'll get frustrating. just reinstall and get it over with. And never use sudo chmod unless you know what you're doing. Dec 15, 2014 at 11:44

6 Answers 6

20

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.

2
  • just an excellent answer. I pointed towards it in Ask Ubuntu
    – Private
    Mar 7, 2013 at 13:51
  • Just a perfect solution for me !
    – user453839
    Jun 1, 2015 at 0:04
3

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)
2
  • does debsums really checks the permissions? I tried chmod a-x /bin/ping and debsums -c would not report that file.
    – reox
    Mar 7, 2018 at 18:53
  • This did not work for me even after installing the debsums package.
    – Bix
    Jun 28, 2021 at 18:59
0

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.

0

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?

0

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.

0

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).

You must log in to answer this question.