1

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.

  • Still not had any luck with this after lots more troubleshooting on ways that I can restore it to a similar state. If anyone has any idea on what I can do, it would be highly appreciated. – Zak Shearman Sep 21 at 10:33
  • 1
    Frankly, I'd give up. Move your /home and other server data to a backup location, list your installed packages with ` dpkg --get-selection, backup /etc/` in case you need to look up some settings later, and reinstall. – Jos Sep 21 at 10:59
  • Anything that I could do though, because I would have to move a lot of databases over. – Zak Shearman Sep 21 at 11:09
  • 2
    The question you linked is about fixing a system after running chmod recursively (with the -R option) - the answers there (in particular the accepted one) will likely have done more harm than good if the command you ran was actually just chmod -x / – steeldriver Sep 21 at 11:41
3

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.

  • I do not completely get what you have said, is it possible for me to contact you by a more 'live' means? To clarify what I do not get, when I do the initial command, I get this zak.pink/19-09-13-12-33_2226.png but I am now unsure what it is that I can use from there, and how I can use it. – Zak Shearman Sep 21 at 12:12
  • You have to do that for sda2. debugfs -w /dev/sda2 would be the correct command for you. I did the repair while booted from Live-USB, means my installer media. – mook765 Sep 21 at 12:18
  • 1
    Yes, this looks already correct, you don't need to change anything, just hit enter, also in the following prompts until the prompt debugfs: appears, then type quit and hit enter. Your problem seems to be different from what you described in your question. – mook765 Sep 21 at 12:29
  • 2
    In your question you say chmod -x, now you say chmod + x, the latter wouldn't have been a problem since permissions of / are set this way by default. Most probably you made other changes which led to your problem. You should open a new question with correct details. – mook765 Sep 21 at 12:36
  • 1
    Whether or not this is exactly the OP's problem, it is a very clever answer. +1 – Jos Sep 21 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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