1

I accidently ran

sudo chmod 555 /

and now all users have lost access to the server

Error:

Last login: Thu Oct 18 16:50:55 2023
Could not chdir to home directory /home/User1: Permission denied
/bin/bash: Permission denied

How could I solve this error?

Greenonline
  • 2,081
hergo herna
  • 11
  • 2
    Good suggestion above but the OP actually got "lucky" and didn't do a recursive chmod. So all that needs to be fixed are the permissions for the subdirectories and a few links. The system might be salvageable. – jones0610 Oct 20 '23 at 00:07
  • Many of us will have done something similar (when learning); mine including a -R which had me create an equivalent install so I could create a script and reset the permissions back to what they should have been (mostly as a learning exercise; as it took time I ensured I wouldn't forget that mistake) with backups the usually fastest fix. – guiverc Oct 20 '23 at 00:10
  • Your /bin/chmod binary should still be usable ... Drop into a root shell from recovery mode and do /bin/chmod 755 / then reboot and it should be solved. – Raffa Oct 20 '23 at 07:54
  • 1
    "I accidently ran sudo chmod 555 /..." - That command is not dangerous, and does not result in the problems you describe. What command did you really run? Did you include -r? – marcelm Oct 20 '23 at 09:53
  • If you didn't add the -R option to make it recursive, most likely, it is just the root directory that has changed. So, that should be easy to fix. If you have a second computer (i.e., a notebook), you can boot it up with a bootable Ubuntu USB drive and then compare a working system with the system you made the mistake on. You just need something to compare with. Good luck! – Ray Oct 20 '23 at 10:08

1 Answers1

2

I did a similar mistake 30-odd years ago. I thought I was in a subdirectory and did a chmod only to realize that I was in the root directory. But in my case I did a wildcard chmod so it not only changed the permissions in / but in it's subdirectories. I quickly realized that the command execution was taking too long and stopped it but by then it was too late.

If you don't have a backup you are pretty much up the creek.

If you don't want to reinstall the OS (which is probably your most reasonable recourse) you might look at the permissions on the subdirectories to see if adding write privileges and fixing links to what's there them might help.

This is more or less what it should look like:

frankie@ubuntu-m8h:~/Downloads$ ls -l /
total 16777308
lrwxrwxrwx   1 root root           7 Oct  5  2022 bin -> usr/bin
drwxr-xr-x   5 root root        4096 Oct 15 19:09 boot
drwxrwxr-x   2 root root        4096 Jul 19  2018 cdrom
drwxr-xr-x  21 root root        5480 Oct 15 14:44 dev
drwxr-xr-x 161 root root       12288 Oct 17 06:50 etc
drwxr-xr-x   4 root root        4096 Nov  4  2020 home
lrwxrwxrwx   1 root root          34 Oct 21  2020 initrd.img -> boot/initrd.img-4.15.0-122-generic
lrwxrwxrwx   1 root root          34 Oct 21  2020 initrd.img.old -> boot/initrd.img-4.15.0-121-generic
lrwxrwxrwx   1 root root           7 Oct  5  2022 lib -> usr/lib
lrwxrwxrwx   1 root root           9 Oct  5  2022 lib64 -> usr/lib64
lrwxrwxrwx   1 root root          10 Oct  5  2022 libx32 -> usr/libx32
drwx------   2 root root       16384 Jul 19  2018 lost+found
drwxr-xr-x   6 root root        4096 Nov  6  2022 media
drwxr-xr-x   2 root root        4096 Apr 26  2018 mnt
drwxr-xr-x   5 root root        4096 Oct 15 14:45 opt
dr-xr-xr-x 401 root root           0 Sep  5 08:09 proc
drwx------   8 root root        4096 Mar 16  2023 root
drwxr-xr-x  42 root root        1220 Oct 19 16:56 run
lrwxrwxrwx   1 root root           8 Oct  5  2022 sbin -> usr/sbin
drwxr-xr-x   2 root root        4096 Sep 30  2022 scratch
drwxr-xr-x  38 root root        4096 Oct 15 14:44 snap
drwxr-xr-x   2 root root        4096 Apr 26  2018 srv
-rw-------   1 root root 17179869184 Mar 16  2023 swapfile_1
dr-xr-xr-x  13 root root           0 Sep  5 08:09 sys
drwxrwxrwt  24 root root       12288 Oct 19 16:55 tmp
drwxr-xr-x  14 root root        4096 Oct  5  2022 usr
drwxr-xr-x  14 root root        4096 Apr 26  2018 var
lrwxrwxrwx   1 root root          31 Oct 21  2020 vmlinuz -> boot/vmlinuz-4.15.0-122-generic
lrwxrwxrwx   1 root root          31 Oct 21  2020 vmlinuz.old -> boot/vmlinuz-4.15.0-121-generic

You have learned a great lesson that anyone seeking to be a *NIX admin needs to learn. And that is that unlike other operating systems, Ubuntu assumes you know what you are doing and will faithfully execute your commands as ill-advised as they may be. So welcome to the domain of the *NIX veterans.

Good luck!

I'll add the link to an answer that is way overkill for your situation for the benefit of anyone having this problem in the future. Please credit the user who put this in a comment with an upvote.

What if I accidentally run command "chmod -R" on system directories (/, /etc, ...)

jones0610
  • 2,157
  • 2
    thanks for the welcome, you're right, what I've learned from this mistake, I will never forget. To resolve it, I read that the best option, if I didn't want to reinstall the OS, was to use a bootable USB drive to access and mount the disk with the affected system and modify the permissions for the directory again. Could this work? And if there's any other option, it would be valuable to hear about it.

    Context: This server is located in a remote area where I'm not present, so I will physically approach the server tomorrow and I want to bring as many possible solutions to address the issue."

     – hergo herna Oct 20 '23 at 00:44
  • You're welcome. Fear is an attribute I look for in anyone I'm considering hiring. *NIX is not an OS for fools. I didn't realize you have locked yourself out of the system. But yes, the advice in the answer you referenced will indeed work. Painful and time consuming process but with determination you could get it up and running again. Always remember: BACKUPS! Cheap insurance. – jones0610 Oct 20 '23 at 00:49