Переміщений контейнер для сміття та інші папки! Як їх повернути?

Я випадково перемістив усі папки з root у підпапку. ( /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 стисканні 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 . Там також стулка , автономні оболонки з багатьма командами вбудованих. Якщо у вас є одне з них, ви можете відновити звідти. Якщо ви їх не встановили раніше, то вже пізно.

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

Якщо у вас більше немає кореневої оболонки, але ви все ще маєте прослуховування демона 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. Я не знаю багато центсів, але це як 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

щоб переконатися, що мені вдалося повернути все в порядок. Якщо у вас його ще не встановлено, спочатку потрібно буде встановити його.