I try to connect to a server using ssh (authentification is fine).

I got this:

/bin/bash: No such file or directory
Connection to xxx closed.

Before, everything is working fine, Until I have really done something stupid and crushed the system, now I can't even connect.

I just installed the ubuntu 16.04 on that server. And I saw something I want is installed in /usr/local/lib64, but it used to be in /usr/lib64 in the previous version (12.04), so I did

mv /usr/local/lib64 /usr/

After this, nothing works. I can't even ls , the only command works is cd. When I exit and try to reconnect, I got this error. Now since that I can't connect, I can't even re-install.

Please help, Thanks.

  • Does ssh SERVER /bin/dash -i work? If not, what is the error message?
    – johnLate
    Apr 22, 2016 at 23:07
  • Wiping out the system library directory is problematic, in particular due to the common use of things like libc.so. Unless you've a means to run statically-compile binaries to repair the damage, a reinstall or rescue boot would be in order.
    – thrig
    Apr 22, 2016 at 23:11
  • Can you still log into your account or not? Your question is contradictory: you say that you can't log in, and then you say that cd works. What works, what doesn't work? And copy-paste the exact commands that you typed and the resulting output, don't just say “it doesn't work”. If not, you'll need to log into that machine in a different way. We can't help you with that since we don't know how you've set it up. You may need to access it physically or to use a remote console. Apr 23, 2016 at 0:09
  • cd works before I quit my session. But then I can't connect anymore.
    – Tony DING
    Apr 29, 2016 at 13:24

1 Answer 1


I don't have Ubuntu 16.04 installed anywhere yet, but based on current trends in Linux system layouts, I can make a pretty good guess at what happened here.

The old distinction between /bin and /usr/bin, and the distinction between /lib and /usr/lib has gone away, because it is no longer the case that we have to install systems on disks so small that we might not be able to get the full user environment onto it. That is to say, even a throwaway USB key is large enough these days for the full OS install, so we no longer need to make a distinction between single user mode tools that traditionally lived outside /usr and everything else, which was segregated under /usr somewhere.

Because a lot of software still believes in this distinction — for example, no current Unix or Linux type system has a /local or /share tree parallel to /usr/local or /usr/share, so you can't just get rid of /usr entirely — the common way for modern OSes to blur this old distinction away is to install everything in /usr and then symlink directories like /usr/bin out to /bin. (Or vice versa; it doesn't matter.)

Therefore, what you did with your mv command is blow away /usr, which was probably a symlink to the consolidated OS installation directory on your system. Not only does this replace /usr/bin and such, it also effectively replaces /bin.

In other words, because there was no /usr/local/lib64/bin/bash before you went in with your heavy-handed "fix", there is now no longer a /usr/bin/bash or a /bin/bash.

Solution: Boot your box into rescue mode and restore the /usr tree to its prior state. You might need an existing working Ubuntu 16.04 system as reference to see how it should be restored.

As for your original problem, your mv command never was a good solution. If you want programs living in /usr/local/lib64 to be runnable without an explicit path, add them to your shell's PATH variable. On Ubuntu, this probably means editing ~/.bash_profile.

Since you talk about a lib directory, you probably aren't dealing with executables, but libraries, in which case you probably need to add an entry to /etc/ld.so.conf.d so that directory is added to the global library cache. See man ldconfig for details.

Not the answer you're looking for? Browse other questions tagged .