18

While trying to debug a mail server, I typed:

chmod -R 777 /

instead of:

chmod -R 777 .

and the icing on the cake, due to me forgetting I had changed a script I use to sign in to fix something, I did all this as root. I do not have backups of most of the system (poor choice I know).

Unlike in the questions "Recovering from chmod -R -777 /" and "What to do after 'chmod -R 777 /'?" i am still signed in as root, and not the whole system was changed, so I do have some control over the system. I also ^C d out of the command within one second to minimize damage. Since then I have physically disconnected the server from the internet.

I believe a script could fix it if it restored the permissions of the filesystem based on data from the package manager, but i do not know how I would go about doing this. If this is not possible, how would I save the data from the server to reinstall the OS?

I am aware of the potential risks of missing a file, but would prefer recovery to reinstall despite them.

this is the current output of ls -la /:

drwxrwxrwx  22 root root  4096 Sep  7  2016 .
drwxrwxrwx  22 root root  4096 Sep  7  2016 ..
drwxr-xr-x   2 root root  4096 May 18 07:55 bin
drwxr-xr-x   3 root root  4096 Sep 21 07:53 boot
drwxr-xr-x  19 root root  3180 Sep 11 20:54 dev
drwxrwxrwx  92 root root  4096 Aug 23 07:50 etc
drwxr-xr-x   4 root root  4096 May 23  2016 home
lrwxrwxrwx   1 root root    31 Feb 24  2016 initrd.img -> /boot/initrd.img-3.16.0-4-amd64
drwxrwxrwx  18 root root  4096 Feb 24  2016 lib
drwxr-xr-x   2 root root  4096 Jun 20 07:00 lib64
drwx------   2 root root 16384 May 19  2016 lost+found
drwxrwxrwx   2 root root  4096 May  5  2015 media
drwxr-xr-x   2 root root  4096 May  5  2015 mnt
drwxr-xr-x   3 root root  4096 May 28  2016 opt
dr-xr-xr-x 148 root root     0 Sep  3 21:55 proc
drwxrwxrwx  10 root root  4096 Aug 19 17:58 root
drwxr-xr-x  22 root root   800 Sep 21 17:09 run
drwxrwxrwx   3 root root  4096 Jun 20 07:00 sbin
drwxr-xr-x   4 root root  4096 Sep 20 23:18 sftp
dr-xr-xr-x  13 root root     0 Sep  3 21:55 sys
drwxrwxrwx   8 root root  4096 Sep 21 17:17 tmp
drwxrwxrwx  11 root root  4096 Feb 24  2016 usr
drwxr-xr-x  14 root root  4096 Jun 25 06:21 var
lrwxrwxrwx   1 root root    27 Feb 24  2016 vmlinuz -> boot/vmlinuz-3.16.0-4-amd64

just noticed in my panic i clicked ubuntu forum not debian... im aware thats not how you fix a mail server. it was a hacky sloppy fix to see what broke

iv reposted this in the correct forum now

kaioker2
  • 291
  • 1
  • 2
  • 6
  • 1
    if you used CHMOD not chmod your fine – George Udosen Sep 21 '17 at 18:41
  • Did you use CHMOD or chmod? These aren't the same commands. And as such you probably didn't harm your system if you used all caps. – Thomas Ward Sep 21 '17 at 18:42
  • 1
    And to add to it: - chmod 777 . is NOT the correct command to debug a mailserver. If you have problems you check the logs in /var/log/ for messages, you do not mess with the permissions on your system. Assume those are always correct. - debian is off topic, we only support official Ubuntu versions. – Rinzwind Sep 21 '17 at 18:51
  • Saved by a mispelled command ;) – Redbob Sep 21 '17 at 19:30
  • kaioker2 did you run some form of chmod previously as I see certain file such as /etc, /root, etc have permissions set to 777? – George Udosen Sep 21 '17 at 19:36
  • @Rinzwind how did you pick out the debian OS? – George Udosen Sep 21 '17 at 19:58
  • 2
    Folks do those perms really look undamaged to you all? It looks more like they actually typed chmod and the only reason not everything is completely borked is that they Ctrl C'd it so fast. As such, the best hope for recovery is terdon's answer to set myself as owner of /etc... – Zanna Sep 21 '17 at 21:07
  • just noticed in my panic i clicked ubuntu forum not debian... /etc and /root were changed by the command typed i did type lowercase. idk why i typed uppercase in the question and yes im aware thats not how you fix a mail server. it was a hacky sloppy fix to see what broke – kaioker2 Sep 21 '17 at 21:08
  • Looks like /usr and /media are gone too. Since it's Debian you may want flag for migration to [unix.se]... – Zanna Sep 21 '17 at 21:17
  • @redbob edit number 2 ;) – Rinzwind Sep 22 '17 at 03:19
  • Oh Gosh! what an adventure! That's the best of the week ... Sorry!... – Redbob Sep 22 '17 at 04:56

1 Answers1

28

Fixing Permission Error

How to restore root directory permission to default?

Rule #1: If you are not comfortable with command lines, do not run any command as root.

Running chmod -R 777 / as root will break your system.

Running rm -rf / as root will result in a disaster!.

If you've ran chmod -R 777 / as root, follow these steps to restore it back:

Step 1:

Copy the following script, paste it on your console to generate fixpermission script 

echo '
chmod -R 755 /bin /boot /dev /etc/ /home /lib /lib64 \
/media /mnt /opt /run /sbin /srv /usr /var

chmod -R 777 /initrd.img /vmlinuz
chmod -R 1777 /tmp
chmod -R 555 /sys
chmod -R 555 /proc
chmod -R 700 /root

' > fixpermission

chmod +x fixpermission

./fixpermission

The above will create a script named fixpermission and run it by ./fixpermission if not already invoked.

Step 2:

Run stat -c '%A %a %n' /* to show your proper directory and their permission as restored.

Example: Your directory permission structure should look similar to the following:

root@plab:~# stat -c '%A %a %n' /*
drwxr-xr-x 755 /bin
drwxr-xr-x 755 /boot
drwxr-xr-x 755 /dev
drwxr-xr-x 755 /etc
drwxr-xr-x 755 /home
lrwxrwxrwx 777 /initrd.img
lrwxrwxrwx 777 /initrd.img.old
drwxr-xr-x 755 /lib
drwxr-xr-x 755 /lib64
drwx------ 700 /lost+found
drwxr-xr-x 755 /media
drwxr-xr-x 755 /mnt
drwxr-xr-x 755 /opt
dr-xr-xr-x 555 /proc
drwx------ 700 /root
drwxr-xr-x 755 /run
drwxr-xr-x 755 /sbin
drwxr-xr-x 755 /srv
dr-xr-xr-x 555 /sys
drwxrwxrwt 1777 /tmp
drwxr-xr-x 755 /usr
drwxr-xr-x 755 /var
lrwxrwxrwx 777 /vmlinuz
lrwxrwxrwx 777 /vmlinuz.old

Step 3:

Reboot your system!

Hope this helps.

Prince Adeyemi
  • 503
  • 4
    THANK YOU SO MUCH!!! i dont have the words to describe how amazing you are! you my friend have saved me many hours of work. =D – kaioker2 Sep 21 '17 at 23:57
  • @kaioker2 You are welcome. I'm glad to be of help. – Prince Adeyemi Sep 21 '17 at 23:59
  • upon noticing i put this on the ubuntu forum, even tho i run debian, i reposted the question to https://superuser.com/questions/1252600/fix-permissions-of-server-after-accidental-chmod-debian/1252622#1252622 id love to select this answer as the top one there too. – kaioker2 Sep 22 '17 at 00:04
  • @kaioker2 Thank you. I'm very sure it will help others as well. – Prince Adeyemi Sep 22 '17 at 00:45
  • 10
    This seems like a pretty crude solution (especially on. Ubuntu where /usr/bin/sudo requires the setuid bit and the user will rarely have the option of running as root). Making every file in the system executable is not a great idea, and lots of the config files in a user's $HOME are meant to have stricter permissions than 755, for example – Zanna Sep 22 '17 at 05:42
  • @Zanna It seems in this context meaning you are not sure. Share output of your stat -c '%A %a %n' /* and compare it with solution above which emanated from a freshly installed Ubuntu for the purpose of getting default directory permissions. – Prince Adeyemi Sep 22 '17 at 06:29
  • 3
    It's the use of the -R flag I object to. We rarely want files and directories to have the same permissions. here are the octal permissions for just the top level contents of my /etc directory, for example. Notice how they are not all 755... – Zanna Sep 22 '17 at 06:42
  • @Zanna Note that OP said *I typed:* chmod -R 777 /" which changed all permission to 777 recursively from /. Without using the flag R then you are exposing all config, sys and vital files and folders at 777 . *I provided a solution that works, got his system back online*, OP may compare directory's octal permission for each folder one by one and apply as deemed necessary. I'm here having fun helping people when I can, I really don't care about down voting the accepted answer, I'm sure that you have a better answer, you can post it to educate more people. – Prince Adeyemi Sep 22 '17 at 17:25
  • 2
    I realise that OP used the -R flag. That's why it's not easy to fix (I already suggested the best chance at a solution in a comment - this is a common problem & various answers deal with it - the easy way is to reinstall) and why I said your solution is crude. In fact, it's dangerous as any file in the system can now be executed by any user including root, many programs may not run or may complain in uninformative ways because the permissions they expect are not present, and many locations that should be hidden are exposed. Since not everything was broken, you've made the situation worse :( – Zanna Sep 22 '17 at 17:41
  • 1
    You might get permission denied while executing above. You need to run the command in root user in recovery mode.
    Bring you up the boot menu.

    Select Advanced Options.

    Select your OS version in (recovery mode), and press Enter Key.

    Ex : Ubuntu 14.04 (recovery mode)

    It will bring you up another screen. Now select “Drop to root shell prompt” and press Enter.

    It will load a command line at the bottom of the screen.

     – bikram Mar 27 '19 at 09:37
  • 2
    Tried this, only messed up my system further. "Just" reinstall with "Something Else" option, like here: https://askubuntu.com/questions/269880/re-install-ubuntu-without-losing-data-in-home-folder#comment1359142_270045 – Bill Kotsias Apr 07 '20 at 06:49
  • You said, "Running rm -rf / as root will result in a disaster!." . I can't agree with you. rm -rf / will do nothing but tell this as a dangerous operation. – Akib Azmain Turja Jul 25 '20 at 07:03
  • i m not able to access console via SSH – Ravi Mehta Apr 24 '21 at 06:17