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

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

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


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.

  • 3
    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
  • 8
    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 5:42
  • 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 6:42
  • 1
    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
  • 2
    Tried this, only messed up my system further. "Just" reinstall with "Something Else" option, like here: askubuntu.com/questions/269880/… – Bill Kotsias Apr 7 '20 at 6:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.