Какое-либо восстановление после этого? sudo chmod 600.*
ПРЕДУПРЕЖДЕНИЕ - НЕ ВЫПОЛНЯЕТ УПОМЯНУТУЮ КОМАНДУ
Таким образом, кажется, что я сделал что-то довольно немое здесь мягко говоря. Я пытался изменить полномочия для нескольких файлов в каталоге, с которого все запустились . к чтению-записи для sudo/root только.
Моя попытка изменения нескольких файлов сразу, кажется, сделала что-то довольно ужасно глобальное. В то время как в каталоге (не был в корневом каталоге) я работал sudo chmod 600 .* и хорошо, я отправляю это со своего телефона теперь... У меня все еще есть окно терминала, открытое в данный момент, но я совершенно уверен, если ноутбук засыпает, я полностью сделан. Весело это означает, что существует небольшая безотлагательность к этому вопросу.
О, и это, кажется, имеет измененные полномочия чертовски рядом везде, я предполагаю. Я не могу даже работать ls или cd .. команды. Попытка cd /home/brian или cd ~ дайте ошибку bash: cd: /home/brian: Permission Denied и любая попытка a sudo команда просто говорит bash: /usr/bin/sudo: Permission Denied
Я боюсь перезагрузки, никакая подсказка, если бы существует, любой встроил, восстанавливают с чего-то этих немых, но полагал, что я попытался бы спросить здесь прежде, чем сделать вещи немного хуже. Я - довольно новый Linux, поскольку моя основная ОС преобразовывает и защита для него немного в последнее время, но ай, эти жала немного. Любые мысли о вещах попробовать очень ценились бы.
Править: Я хотел предоставить разъяснение о том, как/где эта команда выполнялась. Это выполнялось от /.atx $, просто произвольный каталог, но больше деталей ниже.
В то время как зарегистрированный как мое регулярное имя пользователя brian, У меня был терминал, открытый для /.atx те содержавшие три текста типа конфигурации только файлы. Каждое имя файла запускается с a .. Это directory/name/the файлы не являются никакой частью общего пакета, просто произвольный набор конфигураций, которые я программно перемещал. Файлы содержали некоторую информацию о строке подключения SQL-сервера и просто хотели их полузатененный.
2 ответа
Ух, восстановление здесь было на самом деле более гладким, чем я ожидал, и все КАЖЕТСЯ в довольно хорошей форме снова.
Огромный благодаря @CharlesGreen для объяснения как та команда, расширенная каталог. Также благодаря @Panther для получения информации о вхождении в режим восстановления для несколько связанной проблемы. (если Вы оба хотите повторно совместно использовать свои комментарии как ответы, я был бы upvote их),
К счастью, в отличие от связанного сообщения, это, кажется, имело очень простую фиксацию. Кажется, когда я работал sudo chmod 600 .* команда только из одного каталога под / это расширилось .* часть До истинных полномочий изменения корневого каталога . от / порождение любого разрешения упасть.
"Фиксация" для этого должна была загрузиться в режим восстановления, повторно монтируя диск как чтение-запись, идя в основной корень (cd /), и затем chmod +rx .. После перезагрузки все надеется вернуться к нормальному.
Мораль истории, выполняя команду на .* может по крайней мере иногда влиять на каталог ВЫШЕ тока. Я намеревался только повлиять на файлы, которые запустились с .... ой.
Огромный благодаря всем, которые прокомментировали и помогли.
"Фиксация" для этого должна была загрузиться в режим восстановления, повторно монтируя диск как чтение-запись, идя в основной корень (CD/), и затем chmod +rx.. После перезагрузки все надеется вернуться к нормальному.
Только, чтобы быть ясными для будущих читателей, которые могли бы столкнуться с этим принятого ответа, существуют проблемы с chmod +x решение как общее решение. Этим конкретным вопросом, кажется, был пользовательский корневой каталог, таким образом, некоторые проблемы ниже могут быть низкими, но если это было применено к бизнес-серверу и затронутым многочисленным пользователям или другим каталогам данных, решение не предлагается.
На положительной стороне этот шаг разрешил бы пользователю возвращать доступ к файлам, таким образом, они могут быть скопированы прочь в резервный носитель для предотвращения дальнейшей потери. И в конце дня, это - основная цель во время любого усилия по восстановлению данных.
Самое большое беспокойство - то, что исходным файлам, возможно, применили определенные полномочия, которые теперь отсутствуют. Некоторые программы - конкретно ssh - осуществляют полномочия файла далее гарантировать их безопасность и не будут работать если +rw разрешение установлено на его папке и файлах.
Другое беспокойство - то, если это применяется в корне (/) папка рекурсивно, будут другие файлы, которые могли бы быть открыты для любого в системе, чтобы просмотреть и изменить. В установке бизнеса, где сервер мог бы содержать уязвимые данные (PCI / финансовая, или healthcare/HIPAA информация) этот доступ мог вести для аудита результатов и последствий.
В персональной / домашней среде это восстановление, вероятно, совершенно приемлемо. Просто обратите внимание, что некоторые вещи могли бы быть тихо повреждены или действовать странно.
В деловой среде, с помощью этого восстановления для восстановления доступа к данным мог бы использоваться, но в конечном счете любая разительная перемена как это должна быть разрешена путем переустановки сервера и восстановления с резервного копирования.
(У Вас ДЕЙСТВИТЕЛЬНО есть актуальная резервная копия, не так ли?;-))