Любое восстановление от этого? sudo chmod 600. *

ВНИМАНИЕ - НЕ ЗАПУСКАЙТЕ НАМЕРЕННУЮ КОМАНДУ

Так что, кажется, я сделал что-то довольно глупое здесь, мягко говоря. Я пытался изменить разрешения для нескольких файлов в каталоге, с которого все начиналось, .на чтение / запись только для sudo / root.

Моя попытка изменить несколько файлов одновременно, похоже, сделала нечто ужасно глобальное. В то время как внутри директории (не находящейся в корневом каталоге) я запустился sudo chmod 600 .*и хорошо, я выкладываю это с моего телефона сейчас ... У меня все еще есть окно терминала, открытое в данный момент, но я совершенно уверен, что ноутбук работает спать я полностью закончила Весело это означает, что есть небольшая срочность в этом вопросе.

Ох, и это, кажется, изменило разрешения, черт побери, почти везде, я думаю. Я даже не могу запустить команды lsили cd ... Попытка cd /home/brianили cd ~дать ошибку, bash: cd: /home/brian: Permission Deniedи любая попытка sudoкоманды просто говоритbash: /usr/bin/sudo: Permission Denied

Я боюсь перезагрузки, не знаю, есть ли какие-то встроенные средства восстановления от чего-то такого тупого, но подумал, что я постараюсь спросить здесь, прежде чем все станет хуже. Я довольно новый Linux, так как моя основная операционная система конвертирует и в последнее время немного отстаиваю его, но ой, этот укус немного. Любые мысли о том, что можно попробовать, будут безмерно оценены.

РЕДАКТИРОВАТЬ: я хотел бы дать разъяснение о том, как / где эта команда была выполнена. Это было выполнено из /.atx $, просто произвольного каталога, но более подробно ниже.

Когда я вошел в систему под своим обычным именем пользователя brian, у меня был открытый терминал, в /.atxкотором содержались три текстовых файла типа конфигурации. Каждое имя файла начинается с .. Этот каталог / имя / файлы не являются частью общего пакета, это просто произвольный набор конфигураций, которые я программно перемещал. Файлы содержали некоторую информацию о строке подключения к SQL-серверу и просто хотели их скрыть.

— Брайан Джорден
источник

Без описания, в каком каталоге вы находились, я предполагаю, что вы были внутри /rootне / тогда, когда вы сделали это (из того, что я вижу в вашем вопросе), что означает саму .*захваченную глобальную /rootпапку ( .ссылки на текущий рабочий каталог) вместе со всеми файлами / каталогами это начинается с ведущей точки. Не уверен, есть ли способ изменить его из вашей системы, но вы, вероятно, могли бы загрузиться с живого USB и отменить что-то оттуда. Не воспринимайте это как 100% ответ, только мысль.

— Сергей Колодяжный

В любом случае оцените мысли и отзывы и рассмотрите их в зависимости от того, как идут дела. Это на самом деле просто глупо ... Я собираюсь обновить основной текст, указав детали того, откуда я запускал команду (часть того, почему я так запутался здесь, что это не казалось опасным в то время)

— Брайан Джорден

Возможный дубликат « Что делать, если я случайно запустил команду« chmod -R »в системных каталогах (/, / etc, ...)

— Panther

Я собираюсь сделать предположение, что .*в вашей команде было расширено включение ..родительского каталога каталога, в котором вы находились. Например, если бы вы были в нем, /home/brianто разрешения /homeбыли бы установлены на 600, а у вас не было бы разрешения заглянуть в /homeкаталог. Можете ли вы в своем открытом терминале казнитьls -ld /*

— Чарльз Грин

Вы можете попытаться восстановить разрешение, см. Askubuntu.com/questions/43621/… . Там есть несколько сценариев, но я опубликовал метод, использующий apt-get из режима восстановления (который я предпочитаю сценариям), на ваш выбор. Поскольку вы не можете использовать sudo, вам придется загрузиться в режиме восстановления. wiki.ubuntu.com/RecoveryMode не забудьте перемонтировать / rx (см. вики)

— Panther

Ответы:

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

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

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

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

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

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

— Брайан Джорден
источник

Вероятно, это повлияло на родительский каталог, потому что ..соответствует .*glob.

— Ктулху

Еще одна причина использовать более рациональную оболочку. Zsh, например, не включает .или ..в расширение .*по умолчанию.

— Муру

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

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

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

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

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

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

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

( У вас есть текущая резервная копия, не так ли? ;-) )

— dan_linder
источник

Мы пошли вперед и проголосовали, потому что здесь есть несколько полезных советов / информации. В моей конкретной ситуации мне повезло, что единственные разрешения, которые были изменены, были непосредственно внутри /и не касались рекурсивно ни в какие другие каталоги. Также стоит отметить, что это было только на моем личном ноутбуке, и, хотя я мог потерять часть рабочего дня (еще не сделал git push), это было бы просто хлопотно и досадно для переустановки моего «пользователя», связанного Приложения. Я бы согласился, что если бы это был какой-либо сервер, меньше времени и усилий, чтобы просто стереть / восстановить.

— Брайан Джорден