12

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...

  • 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
32

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.

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

You may need to adjust this a little for other distributions or architectures. For example, for CentOS on x86_64:

export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.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.

  • 1
    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
  • Thanks Gilles! This saved me. I've added an edit for 64-bit linux env. In my case, 64-bit CentOS 7 – CompEng88 Jan 16 at 23:28
  • @ComputerEngineer88 Thanks, but when you make edits, please don't add “EDIT” markers or add them at the end of the post where they don't belong. Keep the flow of the text. Posts have an edit history if people want to know what the post contained before. When people read the post normally, they don't care that some bit was added later. – Gilles Jan 16 at 23:33
  • Really? I always focus on the edits. Means something new was learned and to me that's most important. All the same -- as long as people benefit! – CompEng88 Jan 17 at 16:29
  • @ComputerEngineer88 I had the same reflex back when I started to use Stack Overflow. But in fact a Stack Exchange post is in many ways closer to a Wikipedia article than to a post on a discussion forum. You expect people to read forum posts soon after they're posted, so it makes sense to have a visible indication if they've been edited. But let's say someone sees this thread in 2027: they wouldn't care whether a paragraph had been there since 2011 or had been added in 2019. – Gilles Jan 17 at 17:11
11

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.

  • 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
  • 1
    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
  • 2
    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
4

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.

  • 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
2

Thanks a lot to Gilles, 5 years later and your posts still saved my day, if not week.

I meant to move the contents of a subfolder to the current folder but instead of mv sub/* ., I did mv sub /* ., so I moved everything to the current folder. Luckily I found this answer, and was able to fix my machine with relative ease. However, I had to adjust the commands slightly since I am working on a x86_64 machine running Ubuntu 16.04. I would like to leave the instructions here, in case anyone is struggling:

export LD_LIBRARY_PATH=/oops/lib:/oops/lib/x86_64-linux-gnu
/oops/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /
0

I would like to add a couple more commands to do after you apply Ktipr’s answer for modern systems (x86_64 machines running Unix), I was not able to get directories "etc" moved with mv as it showed error

Error : Directory not empty

so I had to use

rsync -a source_file target_location

to ensure that I was able to get everything back in order. If you don't have it already installed you will need to install it first.

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.