Przeniesiono kosz i inne foldery! Jak je odzyskać?

Przypadkowo przeniosłem wszystkie foldery z katalogu głównego do podfolderu. ( /bin, /etc, /home, /lib, /usr... wszystko przeniesiony) jedynymi, które nie zostały przeniesione, ponieważ były one w użyciu, są /bak, /boot, /dev, /proc, /sys.

Teraz każde polecenie, które próbuję wykonać, po prostu się nie wydarzy. Ciągle pojawia się komunikat „Brak takiego pliku lub katalogu”.

Jestem połączony przez ssh i przez ftp, ale nie mogę przenosić plików przez ftp, ponieważ bezpośrednie logowanie SU jest wyłączone. Mam również dostęp do rzeczywistego serwera, jeśli muszę coś zrobić bezpośrednio z tego miejsca.

Zakładam, że musiałbym edytować plik konfiguracyjny, aby powiedzieć mu, gdzie znaleźć /binfolder, co pomogłoby mi uzyskać dostęp ponownie, ale nie wiem, który to plik i jak to zrobić (ponieważ nie można nawet uruchomić, chmodaby zmienić uprawnienia).

Czy jest na to wyjście poza ponownym zainstalowaniem?

Pracuję nad starą wersją CentOS.

_{Jestem niezwykle nowy w świecie Linuksa, stąd ta akcja i pytanie ...}

Jeśli nadal masz powłokę root, możesz mieć szansę naprawić swój system. Powiedzmy, że przeniósł wszystkich wspólnych katalogów ( /bin, /etc, /lib, /sbin, /usr- są to te, które mogłyby spowodować odzyskanie trudną) pod /oops.

Nie będziesz mógł wydać mvpolecenia bezpośrednio, nawet jeśli podasz pełną ścieżkę /oops/bin/mv. To dlatego, że mvjest dynamicznie powiązany ; ponieważ /libkatalog został przeniesiony , mvnie można go uruchomić, ponieważ nie można znaleźć bibliotek, które stanowią część jego kodu. W rzeczywistości jest nawet gorzej: mvnie można znaleźć dynamicznego modułu ładującego /lib/ld-linux.so.2 (nazwa może się różnić w zależności od architektury i wariantu unix, a katalog może mieć inną nazwę, taką jak /lib32lub /lib64). Dlatego, dopóki nie przeniesiesz /libkatalogu z powrotem, musisz jawnie wywołać konsolidator i określić ścieżkę do przeniesionych bibliotek. Oto polecenie przetestowane na ściśnięciu Debiana i386.

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

Może być konieczne dostosowanie tego nieco w przypadku innych dystrybucji lub architektur. Na przykład dla CentOS na x86_64:

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

Kiedy coś spieprzysz /lib, pomoże Ci mieć statycznie połączony zestaw narzędzi. Niektóre dystrybucje (nie wiem o CentOS) zapewniają statycznie połączoną kopię Busybox . Jest też sash , samodzielna powłoka z wieloma wbudowanymi poleceniami. Jeśli masz jeden z nich, możesz odzyskać stamtąd. Jeśli nie zainstalowałeś ich wcześniej, jest za późno.

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

Jeśli nie masz już powłoki roota, ale nadal nasłuchujesz demona SSH i możesz zalogować się bezpośrednio jako root przez ssh, a masz jeden z tych statycznie połączonych zestawów narzędzi, możesz być w stanie ssh. może działać, jeśli zostały przeniesione /libi /bin, ale nie /etc.

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

Niektórzy administratorzy zakładają alternatywne konto ze statycznie połączoną powłoką lub zmuszają konto root do korzystania ze statycznie połączonej powłoki, tylko dla tego rodzaju problemów.

Jeśli nie masz root-a i nie podjąłeś żadnych środków ostrożności, będziesz musiał uruchomić system z Live CD / USB na Linuksa (każdy będzie działał tak długo, jak będzie wystarczająco nowy, aby mieć dostęp do twoich dysków i systemów plików) i przenieś pliki z powrotem.

Prawdopodobnie możesz odzyskać bez ponownego uruchamiania, więc nie uruchamiaj ponownie, dopóki nie wypróbujesz innych rzeczy, ponieważ nie uruchomi się. Jeśli nadal masz otwartą sesję SSH, spróbuj wykonać następujące czynności:

• Miejsce uruchamiania programów ustawia się za pomocą zmiennej $ PATH. Możesz dodać nową lokalizację kosza do ścieżki, uruchamiając export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". Konieczne może być również dodanie odpowiednich katalogów sbin . Możesz także uruchamiać programy ręcznie przez ich pełną ścieżkę, /path/to/mv [from] [to]na przykład powinno działać, nawet jeśli mv znajduje się w innym miejscu. Trudna część polega na tym, że większość poleceń będzie chciała uzyskać dostęp do wspólnych bibliotek i mówisz, że zostałeś /libprzeniesiony, więc musisz ustawić zmienną dla tego, gdzie to jest.export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• Gdy będziesz w stanie wykonać kilka podstawowych poleceń, cofnij to! mv /path/to/subfolder/* /byłoby w porządku! Gdy wszystko wróci na miejsce, system powinien działać normalnie.

Jeśli to się nie powiedzie, uruchomienie KAŻDEJ płyty LiveCD i zamontowanie napędu powinno umożliwić przeniesienie folderów z powrotem do ich miejsca. Nie musisz ponownie instalować ani nawet korzystać z dystrybucji na żywo, wystarczy zamontować dysk i przenieść foldery z powrotem do właściwej lokalizacji na dysku. Wiele dysków ratunkowych opartych na systemie Linux specjalizuje się w udostępnianiu zaledwie kilku podstawowych narzędzi konsoli do wykonania tego rodzaju naprawy.

Powinieneś być w stanie ponownie uruchomić komputer z instalacyjną płytą CD w trybie pojedynczego użytkownika, zamontować główny system plików i przenieść pliki z powrotem na Linux. Nie znam dużo centów, ale to jest jak RHEL, więc to powinno działać.

Wielkie dzięki dla Gillesa, 5 lat później, a twoje posty wciąż uratowały mi dzień, jeśli nie tydzień.

Chciałem przenieść zawartość podfolderu do bieżącego folderu, ale zamiast tego mv sub/* .zrobiłem mv sub /* ., więc przeniosłem wszystko do bieżącego folderu. Na szczęście znalazłem tę odpowiedź i byłem w stanie naprawić moją maszynę ze względną łatwością. Musiałem jednak nieco dostosować polecenia, ponieważ pracuję na maszynie x86_64 z systemem Ubuntu 16.04. Chciałbym zostawić instrukcje tutaj, na wypadek, gdyby ktoś miał problemy:

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

Chciałbym dodać jeszcze kilka poleceń do wykonania po zastosowaniu odpowiedzi Ktipr dla nowoczesnych systemów (maszyny x86_64 z systemem Unix), nie byłem w stanie uzyskać przeniesienia katalogów „etc” z mv, ponieważ pokazywał błąd

Error : Directory not empty

więc musiałem użyć

rsync -a source_file target_location

aby upewnić się, że udało mi się odzyskać wszystko w porządku. Jeśli jeszcze go nie masz, musisz go najpierw zainstalować.