Movido bin e outras pastas! Como recuperá-los?

Question

Eu acidentalmente movi todas as pastas do root para uma subpasta. ( /bin , /etc , /home , /lib , /usr ... todos movidos) Os únicos que não foram movidos, desde que estavam em uso, são /bak , /boot , /dev , /proc , /sys .

Agora, qualquer comando que eu tente executar simplesmente não acontecerá. Eu constantemente recebo "Nenhum tal arquivo ou diretório".

Estou conectado através do ssh e do ftp, mas não consigo mover arquivos pelo ftp, pois o login direto do SU está desabilitado. Eu também tenho acesso ao servidor real se eu precisar fazer algo diretamente de lá.

Estou assumindo que precisaria editar um arquivo de configuração para informar onde encontrar a pasta /bin e que me ajudaria a obter acesso novamente, mas não sei qual arquivo seria ou como para fazer isso (desde que eu não posso nem correr chmod para alterar as permissões).

Existe alguma maneira de fazer isso além de reinstalar?

Estou trabalhando em uma versão antiga do CentOS.

_{Eu sou extremamente novo no mundo do Linux, daí esta ação e a questão ...}

    

Answer 1

Se você ainda tiver um shell de root, poderá ter a chance de reparar seu sistema. Digamos que você moveu todos os diretórios comuns ( /bin , /etc , /lib , /sbin , /usr - esses são os que podem dificultar a recuperação) em /oops .

Você não poderá emitir o comando mv diretamente, mesmo que você especifique o caminho completo /oops/bin/mv . Isso porque mv é dinamicamente vinculado ; porque você moveu o diretório /lib , mv não pode ser executado porque não consegue encontrar as bibliotecas que fazem parte de seu código. Na verdade, é ainda pior do que isso: mv não consegue encontrar o carregador dinâmico /lib/ld-linux.so.2 (o nome pode variar dependendo da sua arquitetura e variante unix, e o diretório pode ser um nome diferente, como /lib32 ou /lib64 ). Portanto, até que você tenha movido o diretório /lib de volta, é necessário chamar o vinculador explicitamente e especificar o caminho para as bibliotecas movidas. Aqui está o comando testado no Debian squeeze i386 (você pode precisar ajustá-lo um pouco para outras distribuições ou arquiteturas).

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

Quando você errou algo em /lib , ajuda ter uma caixa de ferramentas vinculada estaticamente. Algumas distribuições (não sei sobre o CentOS) fornecem uma cópia vinculada estaticamente da Busybox . Há também sash , um shell autônomo com muitos comandos embutidos. Se você tiver um desses, poderá fazer sua recuperação a partir daí. Se você não instalou antes do fato, é tarde demais.

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

Se você não tem mais um shell de root, mas ainda tem um daemon SSH escutando e você pode logar diretamente como root sobre ssh, e você tem uma destas toolboxes vinculadas estatisticamente, você pode ser capaz de fazer ssh Isso pode funcionar se você tiver movido /lib e /bin , mas não /etc .

ssh [email protected] /oops/bin/sash
[email protected]'s password:
Stand-alone shell (version 3.7)
> -mv /oops/* /

Alguns administradores configuram uma conta alternativa com um shell vinculado estaticamente ou fazem com que a conta root use um shell vinculado estaticamente, apenas para esse tipo de problema.

Se você não tiver um shell de root e não tiver tomado precauções, precisará inicializar a partir de um live CD / USB do Linux (qualquer um será feito, desde que seja recente o suficiente para poder acessar seus discos e sistemas de arquivos) e mova os arquivos de volta.

    

Answer 2

Você provavelmente pode recuperar sem reinicializar, por isso não reinicialize até que tenha tentado algumas outras coisas, porque ele não será inicializado. Se você ainda tiver sua sessão SSH aberta, tente estas:

• Onde os programas executados são definidos usando a variável $ PATH. Você pode adicionar seu novo local de depósito ao caminho executando export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin" . Você pode precisar adicionar os diretórios sbin correspondentes também. Você também pode executar programas manualmente através de seu caminho completo /path/to/mv [from] [to] , por exemplo, deve funcionar mesmo se mv estiver em um local diferente. A parte complicada é que a maioria dos comandos vai querer acessar bibliotecas comuns e você diz que /lib foi movido, então você precisa definir uma variável para onde está também. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• Uma vez que você possa executar alguns comandos básicos, mova o material de volta! mv /path/to/subfolder/* / estaria em ordem! Quando tudo estiver de volta, o sistema deve se comportar normalmente.

Se isso falhar, a inicialização de QUALQUER UM LiveCD e a montagem da unidade permitirão que você mova as pastas de volta para onde elas pertencem. Você não precisa reinstalar ou mesmo usar suas distros ao vivo, você só precisa montar a unidade e mover as pastas de volta para o local correto no disco. Muitos discos de recuperação baseados em linux se especializam em dar a você apenas algumas ferramentas básicas de console para fazer esse tipo de reparo.

    

Answer 3

Você deve conseguir reinicializar o computador com um CD de instalação no modo de usuário único, montar o sistema de arquivos raiz e mover os arquivos de volta para o Linux. Eu não sei muito centos, mas é como o RHEL, então isso deve funcionar.

    

Answer 4

Muito obrigado a Gilles, 5 anos depois, e seus posts ainda salvaram meu dia, se não a semana.

Eu pretendia mover o conteúdo de uma subpasta para a pasta atual, mas em vez de mv sub/* . , eu fiz mv sub /* . , então mudei tudo para a pasta atual. Por sorte, encontrei essa resposta e consegui consertar minha máquina com relativa facilidade. No entanto, eu tive que ajustar os comandos um pouco desde que eu estou trabalhando em uma máquina x86_64 rodando o Ubuntu 16.04. Eu gostaria de deixar as instruções aqui, caso alguém esteja com dificuldades:

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

    

Answer 5

Gostaria de adicionar mais alguns comandos para fazer depois de aplicar A resposta do Ktipr para sistemas modernos (máquinas x86_64 executando o Unix), não consegui obter diretórios "etc" movido com mv como mostrou erro

Error : Directory not empty

então eu tive que usar

rsync -a source_file target_location

para garantir que eu consiga colocar tudo de volta em ordem. Se você não o tiver instalado, precisará instalá-lo primeiro.