2

So, I accidentally ran chmod -x / instead of what I meant to, and therefore broke a load of stuff on my server. Because of this, I can't do things like log into the normal way, and am having to use other methods.

I tried this Fix permissions of server after accidental chmod but just got tons of permission issues that look a bit like "changing permission of '/proc/sys/net/etc.." and then it still does not work. I also get this for a lot of other directories.

If you could let me know how to fix this or any other information you need, that would be great.

mook765
  • 18,644
Zak Shearman
  • 21
  • 1

1 Answers1

4

The command chmod -x / only removes the executable bit from the root-directory. If you'd be still logged in as root, you could easily reverse the change with chmod +x /.

Obviously you are not logged in as root anymore, so you have locked out yourself from the system. This can still be fixed. I just did the same, I ran chmod -x /, closed the terminal and I broke the system, I can't even reboot.

I solved this booting from Live-USB, the problem is, that we can't use chmod to restore the correct permissions of the damaged root-filesystem because it doesn't have a name. But we know that the root-filesystem is stored as inode number 2. We can use the command debugfs to restore the correct permissions.

With lsblk | grep -v loop we can determine the device-name of the damaged filesystem.

Then we can run debugfs -w /dev/sdXY as root, take a look at my example below:

# debugfs -w /dev/sdb2
debugfs 1.44.1 (24-Mar-2018)
debugfs:  modify_inode <2>
                          Mode    [040644] 040755   # here enter correct permissions and hit enter
                       User ID    [0]               # here and in the following prompts only hit enter
                      Group ID    [0] 
                          Size    [4096] 
                 Creation time    [1564191527] 
             Modification time    [1564191527] 
                   Access time    [1567339087] 
                 Deletion time    [0] 
                    Link count    [24] 
              Block count high    [0] 
                   Block count    [8] 
                    File flags    [0x80000] 
                    Generation    [0x0] 
                      File acl    [0] 
           High 32bits of size    [0] 
              Fragment address    [0] 
               Direct Block #0    [127754] 
               Direct Block #1    [4] 
               Direct Block #2    [0] 
               Direct Block #3    [0] 
               Direct Block #4    [1] 
               Direct Block #5    [9265] 
               Direct Block #6    [0] 
               Direct Block #7    [0] 
               Direct Block #8    [0] 
               Direct Block #9    [0] 
              Direct Block #10    [0] 
              Direct Block #11    [0] 
                Indirect Block    [0] 
         Double Indirect Block    [0] 
         Triple Indirect Block    [0] 
debugfs: quit                                       # here we quit

The permissions of this root-filesystem are correct now and I can reboot into the former damaged system.

mook765
  • 18,644