ビンと他のフォルダーを移動しました！それらを取り戻す方法は？

誤ってすべてのフォルダーをルートからサブフォルダーに移動しました。（/bin、/etc、/home、/lib、/usr彼らが使用されていたことから、移動しなかったものだけを...すべてが移動）、です /bak、/boot、/dev、/proc、/sys。

これで、私が実行しようとするコマンドはまったく発生しなくなります。「そのようなファイルやディレクトリはありません」というメッセージが常に表示されます。

sshとftpで接続していますが、直接SUログインが無効になっているため、ftpでファイルを移動できません。そこから直接何かをする必要がある場合、実際のサーバーにもアクセスできます。

私は、/binフォルダを見つける場所を伝えるために構成ファイルを編集する必要があり、それが再びアクセスを得るのに役立つと仮定していますが、どのファイルになるのか、それを行う方法はわかりません（私はchmod権限を変更するために実行することさえできません）。

再インストール以外の方法はありますか？

私はCentOSの古いバージョンに取り組んでいます。

_{私はLinuxの世界に非常に新しいので、このアクションと質問...}

ルートシェルがまだある場合は、システムを修復する可能性があります。あなたはすべての共通のディレクトリを移動するとしましょう（/bin、/etc、/lib、/sbin、/usr-これらは回復困難を作ることができるものです）の下で/oops。

mvフルパスを指定しても、コマンドを直接発行することはできません/oops/bin/mv。それmvはが動的にリンクされているためです; /libディレクトリを移動したmvため、そのコードの一部を構成するライブラリが見つからないため、実行できません。実際には、それよりもさらに悪いことだ：mv見つけることができない、ダイナミックローダー /lib/ld-linux.so.2（名前はあなたのアーキテクチャおよびUNIXバリアントによって異なる場合があり、およびディレクトリのような別の名前かもしれません/lib32か/lib64）。したがって、/libディレクトリを元に戻すまで、リンカーを明示的に呼び出す必要があり、移動したライブラリへのパスを指定する必要があります。Debian squeeze i386でテストされたコマンドは次のとおりです。

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

他のディストリビューションやアーキテクチャのためにこれを少し調整する必要があるかもしれません。たとえば、x86_64上のCentOSの場合：

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

何かを台無しにしたとき/libは、静的にリンクされたツールボックスが横になっていると役立ちます。一部のディストリビューション（CentOSについては知りません）はBusyboxの静的にリンクされたコピーを提供します。また、多くのコマンドが組み込まれたスタンドアロンのシェルであるsashもあります。これらのいずれかがある場合、そこから回復を行うことができます。実際にそれらをインストールしていない場合は、手遅れです。

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

ルートシェルはもうないが、まだSSHデーモンがリッスンしていて、sshを介してrootとして直接ログインでき、これらの静的にリンクされたツールボックスの1つがある場合、sshでログインできる可能性があります。あなたが移動した場合には働くことができる/libと/bin、ではなく/etc。

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

一部の管理者は、この種の問題のために、静的にリンクされたシェルで代替アカウントをセットアップするか、rootアカウントに静的にリンクされたシェルを使用させます。

ルートシェルがなく、予防策を講じていない場合は、LinuxライブCD / USBから起動する必要があります（ディスクおよびファイルシステムにアクセスできるのに十分な最新のものであればどれでもかまいません）。ファイルを元に戻します。

おそらく再起動せずに回復できるので、起動しないため、他のことを試すまで再起動しないでください。SSHセッションがまだ開いている場合は、次を試してください。

• プログラムの実行元は、$ PATH変数を使用して設定されます。を実行すると、新しいビンの場所をパスに追加できますexport PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin"。対応するsbinディレクトリも追加する必要がある場合があります。/path/to/mv [from] [to]たとえば、mvが別の場所にある場合でも機能するはずのフルパスを介してプログラムを手動で実行することもできます。トリッキーな部分は、ほとんどのコマンドが共通のライブラリにアクセスすることを望んでいる/libので、移動されたと言うので、そこにも変数を設定する必要があります。export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• いくつかの基本的なコマンドを実行できたら、それらを元に戻します！mv /path/to/subfolder/* /順番になります！すべてが元に戻ったら、システムは正常に動作するはずです。

それが失敗した場合、任意のLiveCDを起動してドライブをマウントすると、フォルダーを元の場所に戻すことができます。再インストールしたり、ディストリビューションlivecdを使用したりする必要はありません。ドライブをマウントし、フォルダをディスク上の正しい場所に戻すだけです。多くのLinuxベースのレスキューディスクは、この種の修復を行うためのいくつかの基本的なコンソールツールの提供に特化しています。

シングルユーザーモードでインストールCDを使用してコンピューターを再起動し、ルートファイルシステムをマウントし、Linuxでファイルを戻すことができるはずです。私は多くのセントスを知りませんが、それはRHELに似ているので、これはうまくいくはずです。

5年後のGillesに感謝し、あなたの投稿は1週間ではないにしても私の一日を救ってくれました。

サブフォルダーの内容を現在のフォルダーに移動するつもりでしたが、代わりにmv sub/* .を実行したmv sub /* .ため、すべてを現在のフォルダーに移動しました。幸いなことに、私はこの答えを見つけ、比較的簡単にマシンを修正することができました。ただし、Ubuntu 16.04を実行しているx86_64マシンで作業しているため、コマンドを少し調整する必要がありました。誰かが苦労している場合のために、ここに指示を残したいと思います：

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/* /

最新のシステム（Unixを実行しているx86_64マシン）にKtiprの答えを適用した後 、エラーを示したため、mvでディレクトリ "etc"を移動することができませんでした。

Error : Directory not empty

だから私は使用しなければならなかった

rsync -a source_file target_location

すべてを正常に戻すことができたことを確認します。まだインストールしていない場合は、最初にインストールする必要があります。