Любое выздоровление от этого? sudo chmod 600. *

Уоу, восстановление здесь было более плавным, чем я ожидал, и все снова появляется в довольно хорошей форме.

Огромное спасибо @CharlesGreen за объяснение того, как эта команда расширила каталог. Также благодаря @Panther для получения информации о входе в режим восстановления для некоторой связанной проблемы. (если вы оба хотите поделиться своими комментариями в качестве ответов, я бы их повысил)

К счастью, в отличие от связанного сообщения это похоже на очень простое исправление. Кажется, что когда я запускал команду sudo chmod 600 .* только из одного каталога в /, он расширил часть .* UP до истинного корневого каталога, изменяя разрешения . из /, вызывая все другие разрешения. [ ! d2]

«Исправить» для этого было загрузка в режим восстановления, повторная установка диска как чтение / запись, переход к основному корню (cd /), а затем chmod +rx .. После перезагрузки все выглядит нормально.

Мораль истории, выполняющая команду на .*, может по крайней мере иногда воздействовать на каталог ВЫШЕ тока. Я решил использовать только файлы, начатые с . ... oops.

Огромное спасибо всем, кто прокомментировал и помог.

Чтобы быть понятным для будущих читателей, которые могли бы встретить это как принятый ответ, есть проблемы с решением chmod +x в качестве общего решения. Этот конкретный вопрос, похоже, был домашним каталогом пользователей, поэтому некоторые из нижеприведенных проблем могут быть низкими, но если это было применено к бизнес-серверу и повлияло на несколько пользователей или другие каталоги данных, решение не предлагается.

С положительной стороны, этот шаг позволит пользователю восстановить доступ к файлам, чтобы их можно было скопировать на резервный носитель, чтобы предотвратить дальнейшую потерю. И в конце концов, это основная цель во время любых усилий по восстановлению данных.

Самая большая проблема заключается в том, что исходные файлы могли иметь определенные разрешения, которые теперь отсутствуют. Некоторые программы - в частности, ssh - обеспечивают права доступа к файлам, чтобы обеспечить их безопасность и не будут работать, если разрешение +rw установлено в его папке и файлах.

Еще одна проблема заключается в том, что это применяется к корню ( /) рекурсивно, будут доступны другие файлы, которые могут быть открыты для всех, кто в системе просматривает и изменяет. В бизнес-настройке, где сервер может содержать конфиденциальные данные (PCI / financial или healthcare / HIPAA information), этот доступ может привести к результатам аудита и последствиям.

В личной / домашней среде это восстановление, вероятно, идеально приемлемо. Просто обратите внимание, что некоторые вещи могут быть тихо сломаны или действуют странно.

В бизнес-среде можно использовать это восстановление для восстановления доступа к данным, но в конечном итоге любые драматические изменения, подобные этому, должны быть разрешены re - установка сервера и восстановление из резервной копии.

( С положительной стороны )

Уоу, восстановление здесь было более плавным, чем я ожидал, и все снова появляется в довольно хорошей форме.

Огромное спасибо @CharlesGreen за объяснение того, как эта команда расширила каталог. Также благодаря @Panther для получения информации о входе в режим восстановления для некоторой связанной проблемы. (если вы оба хотите поделиться своими комментариями в качестве ответов, я бы их повысил)

К счастью, в отличие от связанного сообщения это похоже на очень простое исправление. Кажется, что когда я запускал команду sudo chmod 600 .* только из одного каталога в /, он расширил часть .* UP до истинного корневого каталога, изменяя разрешения . из /, вызывая все другие разрешения. [ ! d2]

«Исправить» для этого было загрузка в режим восстановления, повторная установка диска как чтение / запись, переход к основному корню (cd /), а затем chmod +rx .. После перезагрузки все выглядит нормально.

Мораль истории, выполняющая команду на .*, может по крайней мере иногда воздействовать на каталог ВЫШЕ тока. Я решил использовать только файлы, начатые с . ... oops.

Огромное спасибо всем, кто прокомментировал и помог.

Чтобы быть понятным для будущих читателей, которые могли бы встретить это как принятый ответ, есть проблемы с решением chmod +x в качестве общего решения. Этот конкретный вопрос, похоже, был домашним каталогом пользователей, поэтому некоторые из нижеприведенных проблем могут быть низкими, но если это было применено к бизнес-серверу и повлияло на несколько пользователей или другие каталоги данных, решение не предлагается.

С положительной стороны, этот шаг позволит пользователю восстановить доступ к файлам, чтобы их можно было скопировать на резервный носитель, чтобы предотвратить дальнейшую потерю. И в конце концов, это основная цель во время любых усилий по восстановлению данных.

Самая большая проблема заключается в том, что исходные файлы могли иметь определенные разрешения, которые теперь отсутствуют. Некоторые программы - в частности, ssh - обеспечивают права доступа к файлам, чтобы обеспечить их безопасность и не будут работать, если разрешение +rw установлено в его папке и файлах.

Еще одна проблема заключается в том, что это применяется к корню ( /) рекурсивно, будут доступны другие файлы, которые могут быть открыты для всех, кто в системе просматривает и изменяет. В бизнес-настройке, где сервер может содержать конфиденциальные данные (PCI / financial или healthcare / HIPAA information), этот доступ может привести к результатам аудита и последствиям.

В личной / домашней среде это восстановление, вероятно, идеально приемлемо. Просто обратите внимание, что некоторые вещи могут быть тихо сломаны или действуют странно.

В бизнес-среде можно использовать это восстановление для восстановления доступа к данным, но в конечном итоге любые драматические изменения, подобные этому, должны быть разрешены re - установка сервера и восстановление из резервной копии.

( С положительной стороны )