I accidentally overwrote the /bin/bash file with a dumb script that I intented to put inside the /bin folder.

How do I get the contents of that file back? Is there a way I can find the contents on the web, and just copy them back in? What are my options here, considering that terminal gives an error talking about "Too many Symbolic Links?"

I'm still a newcomer to this kind of thing, and I appreciate all the help I can get.

Edit: I forgot to mention I'm on Kali 2.2 Rolling, which is pretty much debian with some added features.

Edit 2: I also restarted the machine, as I didn't realize my mistake until a few days ago. That makes this quite a bit harder.

| improve this question | | | | |
  • 9
    Deleted bash? Just use zsh :-) </troll> – Kevin Oct 17 '17 at 18:40
  • 1
    serverfault.com/questions/451528/… and several others – skandigraun Oct 17 '17 at 19:38
  • physical or VM? – Ben Aveling Oct 18 '17 at 2:51
  • 9
    For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package. – spectras Oct 18 '17 at 17:56

bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.

So the first thing should be to change your shell to something safe. See what shells you have installed

cat /etc/shells

Then change your shell to one of the other shells listed there, for example

chsh -s /bin/dash

Update, because you already rebooted:

You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.

Then try to reinstall bash with

apt-get --reinstall install bash

If everything succeeded you can chsh back to bash.

Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.

| improve this answer | | | | |
  • 3
    @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...). – MSalters Oct 17 '17 at 13:15
  • 7
    That last sentence was harsh...:) – President James K. Polk Oct 17 '17 at 16:07
  • 6
    @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user. – derobert Oct 17 '17 at 16:30
  • 12
    @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali. – terdon Oct 18 '17 at 10:58
  • 3
    The last sentence is not harsh. It's the plain truth. – Andrea Lazzarotto Oct 21 '17 at 13:39

Don't shut down your machine.

Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)


sudo cp /proc/$$/exe /bin/bash

Voila, all is well.

Since someone in the comments doubts that this works:

[vagrant@localhost ~]$ cat /etc/shells 
[vagrant@localhost ~]$ grep root /etc/passwd
[vagrant@localhost ~]$ echo $0
[vagrant@localhost ~]$ sudo rm /bin/bash
[vagrant@localhost ~]$ bash
-bash: /bin/bash: No such file or directory
[vagrant@localhost ~]$ sudo su -
su: /bin/bash: No such file or directory
[vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
[vagrant@localhost ~]$ bash
[vagrant@localhost ~]$ exit
[vagrant@localhost ~]$ sudo su -
[root@localhost ~]# logout
[vagrant@localhost ~]$ 
| improve this answer | | | | |
  • 18
    In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash) – Giacomo Catenazzi Oct 17 '17 at 13:13
  • 4
    @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though. – Wildcard Oct 17 '17 at 18:02
  • 1
    The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)." – GarrukApex Oct 18 '17 at 0:56

If you can login, but you can’t open a terminal or otherwise access a shell, but you can access files through the GUI, go to /bin, look for files whose names end with sh (but not .sh) and run one (by double-clicking or right-clicking).  In particular, look for the following:

  • sh
  • dash
  • ash
  • ksh (or ksh followed by a number; e.g., ksh93)
  • zsh
  • yash

or, as a last resort,

  • tcsh or
  • csh

If you can get a shell running, then try Philippos’s answer.

Another approach is to boot into single-user mode following these instructions but specify init=/bin/sh (or one of the other shells) instead of init=/bin/bash.

| improve this answer | | | | |

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.