Я собирался изменить владельца каталога на apache:apache, но в итоге я запустил:
chown -R apache:apache /
Плохой! Очень плохо! Я знал, что происходит, когда он начал говорить:
chown: изменение владельца `/ proc / 2694 / fd / 48 ': в доступе отказано
Вот тогда я все и остановил (Ctrl + C).
Текущая система у меня - это сервер, на котором запущен виртуальный ящик с CentOS 5. Эта проблема возникла внутри виртуальной машины.
На данный момент вроде все работает, но я еще не перезагружал систему и, честно говоря, боюсь, что если я сделаю что-то сломается.
Я не знаю chownпорядок, должен ли я быть обеспокоен и предположить, что что-то сломается после перезагрузки? Есть ли способ исправить эту проблему, не полагаясь на резервные копии? У меня есть ежедневный, но я подумал, что может быть выход попроще.
rpm --setugids восстановит права собственности на переданные ему пакеты. Проходить -a восстановить все пакеты. Вам также может понадобиться --setperms для восстановления разрешений setuid / setgid.
Было бы хорошо иметь старую резервную копию, но ИМХО этого было бы достаточно, чтобы иметь возможность извлечь данные о владельце.
Я бы сделал так:
Сначала сделайте резервную копию текущего состояния.
Затем восстановите исходные свойства в соответствии с RPMDB. Это, вероятно, восстановит много ваших файлов
Чтобы определить и исправить оставшиеся, найдите все файлы, которые все еще подвержены этой проблеме. Это файлы, принадлежащие apache:apache и находятся в "порядке поиска" перед /proc . Может ты
ls -U /
сначала и получите список записей корневого уровня перед /proc (Я полагаю, здесь вы отменили процесс).
Затем сделайте
find /foo /bar /baz -user apache -group apache
замена foo, bar, baz с записями, идентифицированными ранее. Перенаправить findвывод в файл.
Извлеките все данные о владельцах данных файлов из резервной копии и примените их к файлам.
Честно говоря, сейчас проще всего запланировать правильное восстановление из последней резервной копии. К счастью, вы все еще можете сделать еще одну, последнюю резервную копию, чтобы сохранить ваши текущие пользовательские данные; затем восстановите старую резервную копию и, наконец, восстановите данные пользователя / клиента из последней резервной копии, убедившись, что вы сохраняете разрешения для каждой группы файлов при этом.
Поскольку ты один из счастливый Достаточно умные люди, чтобы внедрить ежедневное резервное копирование, вот что я предлагаю:
Если у вас есть прямой доступ к каталогу резервных копий, вы можете использовать его для очистки прав доступа ко всем файлам. Bacula, например, хранит метаданные в базе данных, а данные файлов можно просматривать с помощью запросов SQL.
Также можно восстановить все ваши файлы в отдельное место и прочитать оттуда файловую систему, чтобы определить соответствующие разрешения.
Для каждого файла в системе, который вы удалили с помощью chown (find / -user apache -group apache), проверьте соответствующий файл в своей резервной копии. Если он существует, восстановите пользователя и группу. Если его нет, отметьте его для последующего просмотра и продолжайте.
Этот процесс обеспечит актуальность всех ваших данных и предотвратит потерю рабочего дня или двух. Восстановление разрешений базы данных RPM - хорошая идея, но там, где у вас есть резервные копии, вы можете выполнить большую часть работы за один проход.