Accidentalmente moví todas las carpetas de la raíz a una subcarpeta. (/bin , /etc , /home , /lib , /usr … todos movidos) Los únicos que no se movieron, ya que estaban en uso, son /bak , /boot , /dev , /proc , /sys .
Ahora, cualquier comando que intente ejecutar simplemente no sucederá. Constantemente recibo "No existe tal archivo o directorio".
Estoy conectado a través de ssh y ftp, pero no puedo mover archivos a través de ftp, ya que el inicio de sesión SU directo está deshabilitado. También tengo acceso al servidor real si necesito hacer algo directamente desde allí.
Supongo que necesitaría editar un archivo de configuración para decirle dónde encontrar el /bin carpeta y eso me ayudaría a obtener acceso nuevamente, pero no sé qué archivo sería o cómo hacerlo (ya que ni siquiera puedo ejecutar chmod para cambiar los permisos).
¿Hay alguna forma de solucionar esto que no sea reinstalar?
Estoy trabajando en una versión antigua de CentOS.
Soy extremadamente nuevo en el mundo de Linux, de ahí esta acción y la pregunta...
Respuesta aceptada:
Si aún tiene un shell raíz, es posible que tenga la oportunidad de reparar su sistema. Digamos que movió todos los directorios comunes (/bin , /etc , /lib , /sbin , /usr — estos son los que podrían dificultar la recuperación) en /oops .
No podrá emitir el mv comando directamente, incluso si especifica la ruta completa /oops/bin/mv . Eso es porque mv está vinculado dinámicamente; porque has movido el /lib directorio, mv no puede ejecutarse porque no puede encontrar las bibliotecas que constituyen parte de su código. De hecho, es incluso peor que eso:mv no puedo encontrar el cargador dinámico /lib/ld-linux.so.2 (el nombre puede variar dependiendo de su arquitectura y variante de Unix, y el directorio podría tener un nombre diferente, como /lib32 o /lib64 ). Por lo tanto, hasta que haya movido /lib directorio de nuevo, debe invocar el enlazador explícitamente y debe especificar la ruta a las bibliotecas movidas. Aquí está el comando probado en Debian squeeze i386.
export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /
Es posible que deba ajustar esto un poco para otras distribuciones o arquitecturas. Por ejemplo, para CentOS en x86_64:
export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /
Cuando has estropeado algo /lib , ayuda tener una caja de herramientas enlazada estáticamente por ahí. Algunas distribuciones (no sé sobre CentOS) proporcionan una copia vinculada estáticamente de Busybox. También hay sash, un shell independiente con muchos comandos integrados. Si tiene uno de estos, puede hacer su recuperación desde allí. Si no los ha instalado antes, es demasiado tarde.
# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit
Si ya no tiene un shell raíz, pero todavía tiene un demonio SSH escuchando y puede iniciar sesión directamente como raíz sobre ssh, y tiene una de estas cajas de herramientas vinculadas estáticamente, es posible que pueda ingresar ssh. Esto puede funcionar si ha movido /lib y /bin , pero no /etc .
ssh [email protected] /oops/bin/sash
[email protected]'s password:
Stand-alone shell (version 3.7)
> -mv /oops/* /
Algunos administradores configuran una cuenta alternativa con un shell vinculado estáticamente, o hacen que la cuenta raíz use un shell vinculado estáticamente, solo para este tipo de problemas.
Relacionado:Permisos de CentOS para usuario de FTP – 550 ¿Falló la operación de creación de directorio?Si no tiene un shell raíz y no ha tomado precauciones, deberá arrancar desde un CD/USB en vivo de Linux (cualquiera funcionará siempre que sea lo suficientemente reciente como para poder acceder a sus discos y sistemas de archivos) y mover los archivos hacia atrás.