Poubelle déplacée et autres dossiers! Comment les récupérer?

J'ai accidentellement déplacé tous les dossiers de la racine vers un sous-dossier. ( /bin, /etc, /home, /lib, /usr... tous déplacés) car ils étaient utilisés, sont les seuls qui ne sont pas déplacés, /bak, /boot, /dev, /proc, /sys.

Maintenant, aucune commande que j'essaie d'exécuter ne se produira tout simplement. Je reçois constamment "Aucun fichier ou répertoire".

Je suis connecté via ssh et via ftp, mais je ne peux pas déplacer de fichiers via ftp, car la connexion directe à SU est désactivée. J'ai également accès au serveur réel si j'ai besoin de faire quelque chose directement à partir de là.

Je suppose que je devrais modifier un fichier de configuration afin de lui dire où trouver le /bindossier et cela m'aiderait à accéder à nouveau, mais je ne sais pas quel fichier ce serait ni comment le faire (puisque je ne peut même pas s'exécuter chmodpour modifier les autorisations).

Y a-t-il un moyen de s'en sortir autre que la réinstallation?

Je travaille sur une ancienne version de CentOS.

_{Je suis extrêmement nouveau dans le monde de Linux, d'où cette action et la question ...}

Si vous avez toujours un shell racine, vous pouvez avoir une chance de réparer votre système. Disons que vous avez déplacé tous les répertoires communs ( /bin, /etc, /lib, /sbin, /usr- ce sont ceux qui pourraient rendre difficile la récupération) sous /oops.

Vous ne pourrez pas lancer la mvcommande directement, même si vous spécifiez le chemin complet /oops/bin/mv. C'est parce qu'il mvest lié dynamiquement ; parce que vous avez déplacé le /librépertoire, mvne peut pas s'exécuter car il ne peut pas trouver les bibliothèques qui font partie de son code. En fait, c'est encore pire que cela: mvimpossible de trouver le chargeur dynamique /lib/ld-linux.so.2 (le nom peut varier selon votre architecture et la variante Unix, et le répertoire peut être un nom différent tel que /lib32ou /lib64). Par conséquent, jusqu'à ce que vous ayez /libreplacé le répertoire, vous devez invoquer l'éditeur de liens de manière explicite et vous devez spécifier le chemin d'accès aux bibliothèques déplacées. Voici la commande testée sur Debian squeeze i386.

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

Vous devrez peut-être l'ajuster un peu pour d'autres distributions ou architectures. Par exemple, pour CentOS sur x86_64:

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

Lorsque vous avez foiré quelque chose /lib, il est utile d'avoir une boîte à outils liée statiquement. Certaines distributions (je ne connais pas CentOS) fournissent une copie liée statiquement de Busybox . Il y a aussi sash , un shell autonome avec de nombreuses commandes intégrées. Si vous en avez un, vous pouvez effectuer votre récupération à partir de là. Si vous ne les avez pas installés avant le fait, il est trop tard.

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

Si vous n'avez plus de shell racine, mais que vous avez toujours un démon SSH à l'écoute et que vous pouvez vous connecter directement en tant que root sur ssh, et que vous avez l'une de ces boîtes à outils liées statiquement, vous pourriez être en mesure de ssh. peut fonctionner si vous avez déménagé /libet /bin, mais pas /etc.

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

Certains administrateurs configurent un autre compte avec un shell lié statiquement, ou obligent le compte root à utiliser un shell lié statiquement, juste pour ce genre de problème.

Si vous n'avez pas de shell racine et n'avez pas pris de précautions, vous devrez démarrer à partir d'un CD / USB live Linux (tout le monde le fera aussi longtemps qu'il sera suffisamment récent pour pouvoir accéder à vos disques et systèmes de fichiers) et déplacer les fichiers en arrière.

Vous pouvez probablement récupérer sans redémarrer, donc ne redémarrez pas avant d'avoir essayé d'autres choses car il ne démarrera pas. Si votre session SSH est toujours ouverte, essayez-les:

• L'endroit où les programmes sont exécutés est défini à l'aide de la variable $ PATH. Vous pouvez ajouter votre nouvel emplacement de bac au chemin en exécutant export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". Vous devrez peut-être également ajouter les répertoires sbin correspondants . Vous pouvez également exécuter des programmes manuellement via leur chemin complet, /path/to/mv [from] [to]par exemple devrait fonctionner même si mv est dans un emplacement différent. La partie délicate est que la plupart des commandes vont vouloir accéder aux bibliothèques communes et vous dites avoir /libété déplacé, vous devez donc définir une variable pour l'endroit où cela se trouve également.export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• Une fois que vous pouvez exécuter certaines commandes de base, remettez les choses en place! mv /path/to/subfolder/* /serait en ordre! Une fois que tout est en place, le système devrait se comporter normalement.

En cas d'échec, le démarrage de TOUT LiveCD et le montage du lecteur devraient vous permettre de replacer les dossiers à leur place. Vous n'avez pas besoin de réinstaller ou même d'utiliser votre distros livecd, il vous suffit de monter le lecteur et de déplacer les dossiers au bon endroit sur le disque. De nombreux disques de secours basés sur Linux sont spécialisés dans la fourniture de quelques outils de console de base pour effectuer ce type de réparation.

Vous devriez pouvoir redémarrer l'ordinateur avec un CD d'installation en mode mono-utilisateur, monter le système de fichiers racine et déplacer les fichiers sous Linux. Je ne connais pas beaucoup de centos, mais c'est comme RHEL, donc ça devrait marcher.

Merci beaucoup à Gilles, 5 ans plus tard et vos messages m'ont encore sauvé la journée, sinon la semaine.

Je voulais déplacer le contenu d'un sous-dossier vers le dossier actuel, mais au lieu de cela mv sub/* ., je l'ai fait mv sub /* ., j'ai donc tout déplacé vers le dossier actuel. Heureusement, j'ai trouvé cette réponse et j'ai pu réparer ma machine avec une relative facilité. Cependant, j'ai dû ajuster légèrement les commandes car je travaille sur une machine x86_64 exécutant Ubuntu 16.04. Je voudrais laisser les instructions ici, au cas où quelqu'un aurait du mal:

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

Je voudrais ajouter quelques commandes supplémentaires après avoir appliqué la réponse de Ktipr aux systèmes modernes (machines x86_64 exécutant Unix), je n'ai pas pu déplacer les répertoires "etc." avec mv car cela montrait une erreur

Error : Directory not empty

donc j'ai dû utiliser

rsync -a source_file target_location

pour m'assurer que je pouvais tout remettre en ordre. Si vous ne l'avez pas déjà installé, vous devrez d'abord l'installer.