¿Alguna recuperación de esto? sudo chmod 600. *

ADVERTENCIA : NO EJECUTE EL COMANDO MENCIONADO

Entonces parece que hice algo bastante tonto aquí para decirlo suavemente. Intenté cambiar los permisos de algunos archivos en un directorio con el que todos comenzaron .a leer / escribir solo para sudo / root.

Mi intento de cambiar varios archivos a la vez parece haber hecho algo terriblemente global. Mientras estaba dentro de un directorio (no estaba en el directorio raíz) corrí sudo chmod 600 .*y bueno, estoy publicando esto desde mi teléfono ahora ... Todavía tengo la ventana de terminal abierta en este momento, pero estoy bastante seguro de si la computadora portátil se apaga para dormir estoy completamente hecho. Hilarantemente, eso significa que hay una leve urgencia en esta pregunta.

Ah, y esto parece haber cambiado los permisos casi en todas partes, supongo. Ni siquiera puedo ejecutar los comandos lso cd ... Un intento de cd /home/briano cd ~dar el error bash: cd: /home/brian: Permission Deniedy cualquier intento de un sudocomando solo dicebash: /usr/bin/sudo: Permission Denied

Tengo miedo de reiniciar, no tengo idea si hay alguna recuperación integrada de algo tan tonto, pero pensé que trataría de preguntar aquí antes de empeorar las cosas. Soy un Linux bastante nuevo como mi principal convertidor de SO y he estado abogando por él un poco últimamente, pero ay, este duele un poco. Cualquier idea de cosas para probar sería inmensamente apreciada.

EDITAR: quería proporcionar una aclaración sobre cómo / dónde se ejecutó este comando. Esto se ejecutó desde /.atx $, solo un directorio arbitrario, pero más detalles a continuación.

Mientras estaba conectado como mi nombre de usuario normal brian, tenía un terminal abierto /.atxque contenía tres archivos de solo texto de configuración. Cada nombre de archivo comenzó con un .. Ese directorio / nombre / los archivos no son parte de un paquete común, solo un conjunto arbitrario de configuraciones que estaba moviendo programáticamente. Los archivos contenían información de la cadena de conexión del servidor SQL y solo los querían semi oscurecidos.

Menos mal, la recuperación aquí fue más fluida de lo que esperaba y todo parece estar en muy buena forma nuevamente.

Muchas gracias a @CharlesGreen por una explicación de cómo ese comando extendió un directorio. También gracias a @Panther por la información sobre cómo ingresar al modo de recuperación por un problema algo relacionado. (si ambos quieren volver a compartir sus comentarios como respuestas, los votaré)

Afortunadamente, a diferencia de la publicación vinculada, esto parece haber tenido una solución muy sencilla. Parece que cuando me encontré con el sudo chmod 600 .*comando desde un único directorio en el /que se expandió la .*porción a la verdadera permisos directorio raíz de alterar .de /causar cualquier otro permiso para caerse.

La "solución" para esto fue iniciar en modo de recuperación, volver a montar la unidad como lectura / escritura, ir a la raíz principal ( cd /) y luego chmod +rx .. Después de reiniciar, todo parece volver a la normalidad.

Moraleja de la historia, la ejecución de un comando en .*al menos a veces puede afectar el directorio por encima de la actual. Tenía la intención de afectar solo los archivos que comenzaron con. ... ¡Uy!

Muchas gracias a todos los que comentaron y ayudaron.

La "solución" para esto fue iniciar en modo de recuperación, volver a montar la unidad como lectura / escritura, ir a la raíz principal (cd /), y luego chmod + rx .. Después de un reinicio, todo parece estar de vuelta a normal.

Solo para que quede claro para los futuros lectores que puedan encontrar esto como la respuesta aceptada, existen preocupaciones con la chmod +xsolución como una solución general. Esta pregunta específica parece haber sido el directorio de inicio de los usuarios, por lo que algunas de las inquietudes a continuación pueden ser bajas, pero si esto se aplicó a un servidor comercial y afectó a múltiples usuarios u otros directorios de datos, no se sugiere la solución.

En el lado positivo , este paso permitiría al usuario recuperar el acceso a los archivos para que puedan copiarse en un medio de copia de seguridad para evitar una mayor pérdida. Y al final del día, ese es el objetivo principal durante cualquier esfuerzo de recuperación de datos.

La mayor preocupación es que los archivos originales podrían haber tenido permisos específicos aplicados que ahora faltan. Algunos programas, específicamente ssh, aplican permisos de archivo para garantizar aún más su seguridad y no funcionarán si el +rwpermiso se establece en su carpeta y archivos.

Otra preocupación es que si esto se aplica en la /carpeta raíz ( ) de forma recursiva, habrá otros archivos que podrían estar abiertos para que cualquiera en el sistema los vea y modifique. En un entorno empresarial en el que el servidor puede contener datos confidenciales (información PCI / financiera o de salud / HIPAA), este acceso podría conducir a resultados y repercusiones de la auditoría.

En un entorno personal / doméstico, esta recuperación es probablemente perfectamente aceptable. Solo tenga en cuenta que algunas cosas pueden romperse silenciosamente o actuar de manera extraña.

En un entorno empresarial, puede usarse esta recuperación para recuperar el acceso a los datos, pero en última instancia, cualquier cambio dramático como este debería resolverse reinstalando el servidor y recuperándose de una copia de seguridad.

( TIENES una copia de seguridad actual, ¿no? ;-) )