Lixeira movida e outras pastas! Como recuperá-los?

Mudei acidentalmente todas as pastas da raiz para uma subpasta. ( /bin, /etc, /home, /lib, /usr... tudo mudou) Os únicos que não foram movidos, uma vez 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 "Não existe esse 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 da SU está desativado. Também tenho acesso ao servidor real se precisar fazer algo diretamente a partir daí.

Suponho que precisaria editar um arquivo de configuração para informar onde encontrar a /binpasta e isso me ajudaria a ter acesso novamente, mas não sei qual arquivo seria ou como fazê-lo (desde que eu nem pode ser executado chmodpara alterar as permissões).

Existe alguma maneira de sair disso além da reinstalação?

Estou trabalhando em uma versão antiga do CentOS.

_{Sou extremamente novo no mundo do Linux, portanto, essa ação e a pergunta ...}

Se você ainda possui um shell raiz, pode ter a chance de reparar seu sistema. Vamos dizer que você moveu todos os diretórios comuns ( /bin, /etc, /lib, /sbin, /usr- estas são as únicas que podem tornar difícil recuperação) sob /oops.

Você não poderá emitir o mvcomando diretamente, mesmo se especificar o caminho completo /oops/bin/mv. Isso porque mvé dinamicamente vinculado ; porque você moveu o /libdiretório, mvnão pode ser executado porque não consegue encontrar as bibliotecas que fazem parte do seu código. De fato, é ainda pior do que isso: mvnão é possível encontrar o carregador dinâmico /lib/ld-linux.so.2 (o nome pode variar dependendo da sua arquitetura e da variante unix, e o diretório pode ser um nome diferente, como /lib32ou /lib64). Portanto, até que você mova o /libdiretório de volta, é necessário chamar explicitamente o vinculador e especificar o caminho para as bibliotecas movidas. Aqui está o comando testado no Debian squeeze i386.

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

Pode ser necessário ajustar um pouco isso para outras distribuições ou arquiteturas. Por exemplo, para o CentOS em x86_64:

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

Quando você estraga alguma coisa /lib, ajuda ter uma caixa de ferramentas vinculada estaticamente por aí. Algumas distribuições (não sei sobre o CentOS) fornecem uma cópia do Busybox vinculada a estaticamente . 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 os 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 possui mais um shell raiz, mas ainda tem um daemon SSH ouvindo e pode efetuar login diretamente como root pelo ssh, e você possui uma dessas caixas de ferramentas vinculadas estaticamente, poderá fazer o ssh. pode funcionar se você se mudou /libe /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 raiz use um shell vinculado estaticamente, apenas para esse tipo de problema.

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

Provavelmente, você pode se recuperar sem reiniciar, portanto, não reinicie até que tenha tentado outras coisas, porque ele não inicializa. Se você ainda tiver sua sessão SSH aberta, tente o seguinte:

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

• Depois de executar alguns comandos básicos, mova o material de volta! mv /path/to/subfolder/* /estaria em ordem! Quando tudo estiver de volta no lugar, o sistema deverá se comportar normalmente.

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

Você poderá reiniciar 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 no Linux. Eu não sei muito centos, mas é como o RHEL, então isso deve funcionar.

Muito obrigado a Gilles, cinco anos depois e suas postagens ainda salvaram meu dia, se não uma semana.

Eu pretendia mover o conteúdo de uma subpasta para a pasta atual, mas em vez disso mv sub/* ., mv sub /* .mudei tudo para a pasta atual. Felizmente, encontrei esta resposta e pude consertar minha máquina com relativa facilidade. No entanto, tive que ajustar um pouco os comandos, pois estou trabalhando em uma máquina x86_64 executando o Ubuntu 16.04. Gostaria de deixar as instruções aqui, caso alguém esteja lutando:

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

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 fazer com que os diretórios "etc" fossem movidos com mv, pois mostrava erro

Error : Directory not empty

então eu tive que usar

rsync -a source_file target_location

para garantir que eu pudesse recuperar tudo em ordem. Se você ainda não o instalou, precisará instalá-lo primeiro.