How to repair/restore ubuntu 10.04 after 'sudo chmod / 777'

Question

See Also:
Why is “chmod -R 777 /” destructive?

I changed file permissions recursively on the root directory / by executing sudo chmod -R / 777, and after that my system won't boot (I'm getting a lot of "permission denied" errors).

Please help.

Maybe you could use a live Ubuntu system. Install the packages you have installed on your normal system and then write a script to 'clone' them? This is just an idea. Maybe someone else can say if this is any good. — Darokthar, Nov 12 '11 at 13:27
Follow this carefully: Open in recovery mode > Mount Drive > Open interactive shell > cd into mounted hard drive (for me it was in /mnt/[directory]) > chmod -R 755 ./** > #cd ./etc/ssh/ #chmod 600 moduli #chmod 644 ssh_config #chmod 644 ssh_host_dsa_key.pub #chmod 644 ssh_host_key.pub #chmod 644 ssh_host_rsa_key.pub #chmod 600 ssh_host_dsa_key #chmod 600 ssh_host_key #chmod 600 ssh_host_rsa_key #chmod 640 sshd_config — Smit Patel, Dec 08 '19 at 05:39
I don't have enough reputation to post the answer in StackExchange but I wanted to help you. — Smit Patel, Dec 08 '19 at 05:42

score 24 · Answer 1 · answered Jan 12 '11 at 08:18

24

You're looking at a lost cause. Save the data you need, and reinstall the operating system.

answered Jan 12 '11 at 08:18

blueben

3,487
1
15
15

Yup. The amount of time you spend doing this will be crazy and you'll never know for sure that you got it exactly right. Start clean, restore your data from backup. – ThatGraemeGuy Jan 12 '11 at 11:42
1

This is one of those step back and learn from it things. Your most important areas are your home folder contents, configuration changes you've made in `/etc`, `/var/www` web server contents and databases. Grab another hard drive, enable it as your primary and install. That preserves your other drive as backup till you can transfer it. – Fiasco Labs Nov 13 '11 at 18:05
I did the same thing (and, yes, I know better) and tried several of the ideas on here but it would take weeks for me to get the machine back into a decent state. Instead try to backup your data and reinstall Ubuntu. – MikeHoss May 16 '12 at 13:21

James · Answer 2 · 2011-01-12T10:21:39.200

I know dpkg stores the permissions in the databases and I found the following script google which may help.

Edit: I actually had a quick look at the script and it looks as if it is missing a bit of magic that goes from PERMS to MODE eg dpkg -c gives for example "-rw-r--r--" but you want 0644, I am at work right now so I am not sure I have the time to do the conversion at this instant but I may come back later if no one else has jumped in to add that bit.

There is a script here which is looks interesting

#!/bin/bash
# Restores file permissions for all files on a debian system for which .deb
# packages exist. 
#
# Author: Larry Kagan <me at larrykagan dot com>
# Since 2007-02-20

ARCHIVE_DIR=/var/cache/apt/archives/
PACKAGES=`ls $ARCHIVE_DIR`
cd /

function changePerms()
{
    CHOWN="/bin/chown"
    CHMOD="/bin/chmod"
    PERMS=$1
    OWN=`echo $2 | /usr/bin/tr '/' ':'`
    PATHNAME=$3

    echo -e "$CHOWN $OWN $PATHNAME"
    #`$CHOWN $OWN $PATHNAME`
    #`$CHMOD $MODE $PATHNAME`

}

for PACKAGE in $PACKAGES;
do
    echo -e "Getting information for $PACKAGE\n"
    FILES=`/usr/bin/dpkg -c "${ARCHIVE_DIR}${PACKAGE}"`

    for FILE in "$FILES";
    do
        FILE_DETAILS=`echo "$FILE" | awk '{print $1"\t"$2"\t"$6}'`
        changePerms $FILE_DETAILS
    done
done

does it deal also with the 04555 files? – Déjà vu Jan 12 '11 at 09:17 — Déjà vu, Jan 12 '11 at 09:17

score 4 · Answer 3 · edited Nov 14 '11 at 05:01

It is possible to come back from such a messy situation, without reinstalling the system. Well, more exactly running a fresh new system either from an USB key or in a Virutal Box (or so) if you have a dual boot system.

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 cautuous!

First, my situation was easier to solve because I had a dual boot system (ubuntu and my old fedora install), but running the system for a USB key (or maybe a CD/DVD) 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 -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.

Rk:

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

EDIT: to support links, the combined command is:

/usr/bin/find / -exec /usr/bin/stat --format="[ ! -L {} ] && /bin/chmod %a %n" {}

score 4 · Answer 4 · answered Nov 29 '11 at 14:13

I modified the script from above and it's looks like this:

#!/bin/bash
# Restores file permissions for all files on a debian system for which .deb
# packages exist. 
#
# Author: Larry Kagan <me at larrykagan dot com>
# Since 2007-02-20

ARCHIVE_DIR=/var/cache/apt/archives/
PACKAGES=`ls $ARCHIVE_DIR`
cd /

function changePerms() {
    CHOWN="/bin/chown"
    CHMOD="/bin/chmod"
    PERMS=`echo $1 | sed -e 's/--x/1/g' -e 's/-w-/2/g' -e 's/-wx/3/g' -e 's/r--/4/g'  -e 's/r-x/5/g' -e 's/rw-/6/g' -e 's/rwx/7/g' -e 's/---/0/g'`
    PERMS=`echo ${PERMS:1}`
    OWN=`echo $2 | /usr/bin/tr '/' '.'`
    PATHNAME=$3
    PATHNAME=`echo ${PATHNAME:1}`

#    echo -e "CHMOD: $CHMOD $PERMS $PATHNAME"    

#    result=`$CHOWN $OWN $PATHNAME`
#    if [ $? -ne 0 ]; then
#   echo -e $result
#        exit 123;
#    fi

    echo -e "CHOWN: $CHMOD $PERMS $PATHNAME"
    result=`$CHMOD $PERMS $PATHNAME`
    if [ $? -ne 0 ]; then
    echo -e $result
    fi
}

for PACKAGE in $PACKAGES;
do
    if [ -d $PACKAGE ]; then
    continue;
    fi
    echo -e "Getting information for $PACKAGE\n"
    FILES=`/usr/bin/dpkg -c "${ARCHIVE_DIR}${PACKAGE}"`

    for FILE in "$FILES";
    do
        #FILE_DETAILS=`echo "$FILE" | awk '{print $1"\t"$2"\t"$6}'`
    echo "$FILE" | awk '{print $1"\t"$2"\t"$6}' | while read line;
        do
            changePerms $line
        done
        #changePerms $FILE_DETAILS
    done
done

score 3 · Answer 5 · answered Jan 12 '11 at 08:43

Agree with blueben, just reinstalling might be faster than analyzing which file/directory needs which permission. But if reinstalling is not an option, here's an idea:

Install a default Ubuntu install on another machine
Run this command to get the permissions of every file/directory on the system: find / | xargs stat -c 'chmod %a "'%n'"' > /tmp/chmod.sh
Copy the file chmod.sh to the computer with the wrong permissions
Execute that file chmod +x /tmp/chmod.sh && /bin/bash /tmp/chmod.sh
Hope most of the things work (not everything will work I believe)

score 2 · Answer 6 · answered Nov 13 '11 at 15:38

ERRATUM to my post posted as user user100740: to support links, the combined command is:

/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

score 2 · Answer 7 · edited Jan 10 '12 at 08:06

If you can still launch /usr/sbin/synaptic, it is often fixable.

Sort the packages by status (installed packages at the top), select all the installed packages, right click and select reinstall. Then apply, that will prompt dpkg to re-extract all the files for those packages. (You will lose any local modifications (but not config file changes).)

It may not get everything fixed though.
The other thing is if you go into /var/cache, you can call dpkg -x <package name> / for every installed package, then call dpkg --reconfigure -a. Also, if you are using Ubuntu, you can do a dist upgrade which often fixes lots of errors (assuming you aren't already on the latest release). Generally when I am trying to fix an error like this, I try these simple fixes and if they don't just make it work again, then it's time to reinstall.

score -2 · Answer 8 · answered Sep 23 '12 at 04:58

-2

boot from live CD. then start shell, then sudo -s. Then chmod 777 /*, then chmod 600 /etc/passwd. kernel will panic if init fails which will happen if /lib/init scripts are not executable. boot to single user mode, for Lilo Linux 1, and run user102453's script above. This gets sytem boot to prompt. Still need to get X running.

answered Sep 23 '12 at 04:58

Wiley

1

3

Wow, that's a pretty awful idea you have there. – HopelessN00b Oct 14 '12 at 04:25

score -3 · Answer 9 · answered Apr 08 '15 at 10:20

-3

Setting the permission of / to 755 worked for me.

So check first with

root@ubuntu:/# cd /
root@ubuntu:/# ls -ld

Permissions should be "drwxr-xr-x" (755).

answered Apr 08 '15 at 10:20

Stefan

1

1

This does not address the recursive part of the question. – kasperd Apr 08 '15 at 10:45
No, and it does not help with the 4755 2755 an 6755 either. If it was just /usr (it often is) you can recursively ls -al a similar system and exclude the 755, this can leave a list of less than 1000 files which can be manually dealt with. Of course src and headers don't really matter. – mckenzm Jun 06 '17 at 00:12

How to repair/restore ubuntu 10.04 after 'sudo chmod / 777'

9 Answers9

Linked

Related