Ho spostato accidentalmente tutte le cartelle dalla radice a una sottocartella. (/bin , /etc , /home , /lib , /usr …tutti spostati) Gli unici che non sono stati spostati, poiché erano in uso, sono /bak , /boot , /dev , /proc , /sys .
Ora, qualsiasi comando che provo a eseguire semplicemente non accadrà. Ricevo costantemente "Nessun file o directory del genere".
Sono connesso tramite ssh e tramite ftp, ma non riesco a spostare i file tramite ftp, poiché l'accesso diretto SU è disabilitato. Ho anche accesso al server effettivo se devo fare qualcosa direttamente da lì.
Presumo che avrei bisogno di modificare un file di configurazione per dirgli dove trovare il /bin cartella e questo mi aiuterebbe ad accedere di nuovo, ma non so quale file sarebbe o come farlo (dal momento che non riesco nemmeno a eseguire chmod per modificare i permessi).
C'è un'altra soluzione oltre alla reinstallazione?
Sto lavorando su una vecchia versione di CentOS.
Sono estremamente nuovo nel mondo di Linux, quindi questa azione e la domanda...
Risposta accettata:
Se hai ancora una shell di root, potresti avere la possibilità di riparare il tuo sistema. Diciamo che hai spostato tutte le directory comuni (/bin , /etc , /lib , /sbin , /usr — questi sono quelli che potrebbero rendere difficile il ripristino) in /oops .
Non potrai emettere il mv comando direttamente, anche se specifichi il percorso completo /oops/bin/mv . Questo perché mv è collegato dinamicamente; perché hai spostato il /lib directory, mv non può essere eseguito perché non riesce a trovare le librerie che costituiscono parte del suo codice. In effetti, è anche peggio di così:mv non riesco a trovare il caricatore dinamico /lib/ld-linux.so.2 (il nome può variare a seconda dell'architettura e della variante unix e la directory potrebbe essere un nome diverso come /lib32 o /lib64 ). Pertanto, fino a quando non avrai spostato il /lib directory back, è necessario richiamare il linker in modo esplicito e specificare il percorso delle librerie spostate. Ecco il comando testato su Debian squeeze i386.
export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /
Potrebbe essere necessario adattarlo un po' per altre distribuzioni o architetture. Ad esempio, per CentOS su x86_64:
export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /
Quando hai sbagliato qualcosa /lib , aiuta ad avere una cassetta degli attrezzi collegata staticamente in giro. Alcune distribuzioni (non conosco CentOS) forniscono una copia di Busybox con collegamento statico. C'è anche sash, una shell standalone con molti comandi integrati. Se hai uno di questi, puoi fare il tuo recupero da lì. Se non li hai installati prima del fatto, è troppo tardi.
# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit
Se non hai più una shell di root, ma hai ancora un demone SSH in ascolto e puoi accedere direttamente come root su ssh, e hai uno di questi toolbox collegati staticamente, potresti essere in grado di entrare in ssh. Questo può funzionare se hai spostato /lib e /bin , ma non /etc .
ssh [email protected] /oops/bin/sash
[email protected]'s password:
Stand-alone shell (version 3.7)
> -mv /oops/* /
Alcuni amministratori configurano un account alternativo con una shell collegata in modo statico o fanno in modo che l'account root utilizzi una shell collegata in modo statico, solo per questo tipo di problemi.
Correlati:autorizzazioni CentOS per l'utente FTP – 550 Operazione di creazione della directory non riuscita?Se non hai una shell di root e non hai preso precauzioni, dovrai eseguire l'avvio da un CD/USB live di Linux (qualsiasi funzionerà purché sia abbastanza recente da poter accedere ai tuoi dischi e filesystem) e sposta indietro i file.