Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I accidentally moved all folders from root to a subfolder. (/bin, /etc, /home, /lib, /usr... all moved) The only ones that were not moved, since they were in use, are /bak, /boot, /dev, /proc, /sys.

Now, any command that I try to execute will simply not happen. I constantly get "No such file or directory".

I am connected through ssh and through ftp, but I cannot move files through ftp, as direct SU login is disabled. I also have access to the actual server if I need to do something directly from there.

I'm assuming I would need to edit a configuration file in order to tell it where to find the /bin folder and that would help me get access again, but I don't know which file that would be or how to do it (since I can't even run chmod to change permissions).

Is there any way out of this other than re-installing?

I am working on an old version of CentOS.

I'm extremely new to the world of Linux, hence this action and the question...

share|improve this question
While not a solution to your problem I recommend reading this: lug.wsu.edu/node/414 Similar situation but he actually deleted /bin. – stribika Jul 26 '11 at 18:44
up vote 18 down vote accepted

If you still have a root shell, you may have a chance to repair your system. Let's say that you moved all the common directories (/bin, /etc, /lib, /sbin, /usr — these are the ones that could make recovery difficult) under /oops.

You won't be able to issue the mv command directly, even if you specify the full path /oops/bin/mv. That's because mv is dynamically linked; because you've moved the /lib directory, mv can't run because it can't find the libraries that constitute part of its code. In fact, it's even worse than that: mv can't find the dynamic loader /lib/ld-linux.so.2 (the name may vary depending on your architecture and unix variant, and the directory could be a different name such as /lib32 or /lib64). Therefore, until you've moved the /lib directory back, you need to invoke the linker explicitly, and you need to specify the path to the moved libraries. Here's the command tested on Debian squeeze i386 (you may need to adjust it a little for other distributions or architectures).

export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /

When you've screwed up something /lib, it helps to have a statically linked toolbox lying around. Some distributions (I don't know about CentOS) provide a statically-linked copy of Busybox. There's also sash, a standalone shell with many commands built-in. If you have one of these, you can do your recovery from there. If you haven't installed them before the fact, it's too late.

# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit

If you don't have a root shell anymore, but you still have an SSH daemon listening and you can log in directly as root over ssh, and you have one of these statically-linked toolboxes, you might be able to ssh in. This can work if you've moved /lib and /bin, but not /etc.

ssh root@broken.example.com /oops/bin/sash
root@broken.example.com's password:
Stand-alone shell (version 3.7)
> -mv /oops/* /

Some administrators set up an alternate account with a statically-linked shell, or make the root account use a statically-linked shell, just for this kind of trouble.

If you don't have a root shell and haven't taken precautions, you'll need to boot from a Linux live CD/USB (any will do as long as it's recent enough to be able to access your disks and filesystems) and move the files back.

share|improve this answer
Thank you Gilles. You have provided some very useful information about what I should be careful of in the future. – Menelaos Jul 27 '11 at 0:06

You can probably recover without rebooting, so don't reboot until you've tried some other things because it will not boot up. If you still have your SSH session open try these:

  • Where programs get run from is set using the $PATH variable. You can add your new bin location to path by running export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". You may need to add the corresponding sbin directories as well. You can also run programs manually via their full path /path/to/mv [from] [to] for example should work even if mv is in a diffeent location. The tricky part is that most commands are going to want to access common libraries and you say /lib got moved so you need to set a variable for where that is too. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

  • Once you can execute some basic commands, move the stuff back! mv /path/to/subfolder/* / would be in order! Once everything is back in place the system should behave normally.

If that fails, booting up ANY LiveCD and mounting the drive should allow you to move the folders back where they belong. You don't need to re-install or even use your distros livecd, you just need to mount the drive and move the folders back to the right location on the disk. Lots of linux based rescue disk specialize in giving you just a few basic console tools to do this kind of repair.

share|improve this answer
Working through SSH failed, so I downloaded a liveCD and I'm trying to get things to work. I'm at grub and trying to mount the drive, but it won't let me because the kernel is not loaded. and not being able to see the exact path of the existing paths is clearly making this difficult... – Menelaos Jul 26 '11 at 19:22
Boot to live, mount your disk, move things back to their proper places, reboot to your system ... and good luck. – Caleb Jul 26 '11 at 19:23
It's not enough to set LD_LIBRARY_PATH, you also need to invoke the dynamic loader explicitly, e.g. LD_LIBRARY_PATH=/newpath/to/lib /newpath/to/lib/ld-linux.so.2 /newpath/to/bin/mv. – Gilles Jul 26 '11 at 23:21
Thanks again Caleb. You're been extremely helpful. – Menelaos Jul 27 '11 at 0:06

You should be able to reboot the computer with an installation CD in single user mode, mount the root filesystem and move the files back on Linux. I do not know much centos, but it is like RHEL, so this should work.

share|improve this answer
Thank you.I'm downloading it as we speak. Does it make a difference if it's the live cd or the whole installation dvd? – Menelaos Jul 26 '11 at 16:59
@Menelaos: You don't want to install, you want something you can run live for this solution. Some instalation disks have live versions, but some just want to isntall straight away. Some do have "rescue" modes which is what you want actually, but there are also dedicated linux rescue disks. It doesn't have to be your distro, it just has to be something that can mount a linux file system and move the folders back. See my answer. – Caleb Jul 26 '11 at 17:54
Looks at sysresccd.org to see one of rescue CDs if you like It has extensive documentation to see how to use it. Helping on using it to resolve this problem may be difficult in this forum and beyond my available time. Else, centos CDs should help. Latest live CD may or may not work...So keeping these kind of problems in mind, you should always keep a installation media/iso of version you installed. Also create a backup of entire filesystems. – Jamess Jul 27 '11 at 4:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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