Перемещен бин и другие папки! Как вернуть их?

Я случайно переместил все папки из корня в подпапку. ( /bin, /etc, /home, /lib, /usr... все переехали) только те , которые не были перемещены, так как они были в использовании, являются /bak, /boot, /dev, /proc, /sys.

Теперь любой команды, которую я пытаюсь выполнить, просто не будет. Я постоянно получаю «Нет такого файла или каталога».

Я подключен через ssh и через ftp, но я не могу переместить файлы через ftp, так как прямой вход в SU отключен. У меня также есть доступ к реальному серверу, если мне нужно что-то сделать прямо оттуда.

Я предполагаю, что мне нужно будет отредактировать файл конфигурации, чтобы указать ему, где найти /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/* /

Возможно, вам придется немного изменить это для других дистрибутивов или архитектур. Например, для CentOS на x86_64:

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, и вы можете войти в систему как root через ssh, и у вас есть один из этих статически связанных наборов инструментов, вы можете войти в 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/* /

Некоторые администраторы создают альтернативную учетную запись со статически связанной оболочкой или заставляют корневую учетную запись использовать статически связанную оболочку, просто для такого рода проблем.

Если у вас нет корневой оболочки и вы не приняли мер предосторожности, вам нужно будет загрузиться с живого CD / USB-диска Linux (любой будет работать, если только он достаточно недавний, чтобы иметь доступ к вашим дискам и файловым системам) и переместить файлы обратно.

Вероятно, вы можете восстановить без перезагрузки, поэтому не перезагружайтесь, пока не попробуете другие вещи, потому что он не загружается. Если у вас все еще открыт сеанс 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 специализируются на предоставлении вам всего лишь нескольких базовых консольных инструментов для такого рода ремонта.

Вы должны быть в состоянии перезагрузить компьютер с установочного компакт-диска в однопользовательском режиме, смонтировать корневую файловую систему и переместить файлы обратно в Linux. Я не знаю много centos, но это как RHEL, так что это должно работать.

Большое спасибо Жилю, 5 лет спустя, и ваши посты все же сохранили мой день, если не неделю.

Я имел в виду , чтобы переместить содержимое вложенной папки в текущей папке , но вместо того mv sub/* ., я сделал mv sub /* ., так что я переехал все к текущей папке. К счастью, я нашел этот ответ и смог относительно легко починить свою машину. Однако мне пришлось немного подкорректировать команды, так как я работаю на компьютере x86_64 с Ubuntu 16.04. Я хотел бы оставить инструкции здесь, на случай, если кто-то борется:

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

Я хотел бы добавить еще пару команд после применения ответа Ktipr для современных систем (машины x86_64 с Unix), я не смог переместить каталоги и т. Д. С помощью mv, так как он показал ошибку

Error : Directory not empty

поэтому я должен был использовать

rsync -a source_file target_location

чтобы я смог вернуть все в порядок. Если он еще не установлен, вам необходимо установить его в первую очередь.