Как выяснить, что вызывает изменение владельца / usr / local с my-username на root


13

Я использую homebrewв качестве менеджера пакетов для определенного приложения веб-разработки. Чтобы быть brewв курсе, я бегаю update brewкаждые пару дней, а также бегаю brew doctor. Обычно это нормально и brewговорит мне, что я готов заваривать.

Время от времени, однако, я получаю следующую ошибку:

Предупреждение: / usr / local / etc не доступен для записи.

Это может произойти, если вы используете программу sudo make install, которой не управляет Homebrew. Если формула пытается записать файл в этот каталог, установка не удастся выполнить во время шага ссылки.

Вы должны вероятно chown/ usr / local / etc

Предупреждение: каталог / usr / local недоступен для записи. Даже если этот каталог был доступен для записи при установке Homebrew, другое программное обеспечение может изменить разрешения для этого каталога. Известно, что некоторые версии компонента InstantOn Airfoil делают это.

Вероятно, вам следует изменить владельца и права доступа к / usr / local для вашей учетной записи пользователя.

Достаточно просто сбросить разрешения обратно на мое имя пользователя. После, brewкажется, все в порядке.

Но что является причиной этого?

Есть ли журнал, который показывает, что вызывает изменение разрешений?


3
Нет журнала, но обратите внимание, что владение / usr / local принадлежит rood является стандартом Unix, и поэтому любая сборка будет ожидать этого. Решение состоит в том, чтобы не смешивать каталог с менеджером пакетов (Homebrew) и стандартной компиляцией Unix - используйте другой каталог для одного из них
user151019

3
Добавление программного обеспечения в то же место, что и менеджер пакетов, является плохой идеей, и поэтому меняется владелец и права доступа /usr/local. Но если вы настаиваете, то можете make installиспользовать sudoпакеты, которые вы устанавливаете сами.
fd0

1
Обновление OS X обычно сбрасывает / usr / локальное владение и разрешения.
mspasov

1
@ Другие ах, я прочитал цитату из Homebrew, а не вопрос
user151019

1
Что еще вы установили (вручную или через любой другой менеджер пакетов) на свой Mac, который был настроен для установки по умолчанию /usr/local?
дан

Ответы:


13

У меня была точно такая же проблема, и оказалось, что виновато автоматическое обновление Sophos. Я понял это, запустив:sudo fs_usage | grep "usr/local"

Это заняло некоторое время, но в конце концов я увидел, что демон Sophos по имени «Installation» портился с разрешениями / usr / local.

Я все еще пытаюсь найти подходящее решение для такого поведения.

РЕДАКТИРОВАТЬ: Я думаю, что Sophos исправил эту проблему, см. Ссылку в комментариях к этому ответу. Кажется, это исправлено для меня по крайней мере!


4
Здесь есть обсуждение: community.sophos.com/products/free-antivirus-tools-for-desktops/… Это должно быть исправлено в ноябре 2015 года
JoeZuntz

@JoeZuntz Хорошая находка! Удивительно, что они на самом деле настаивают на исправлении.
другие

@ другие спасибо за эту информацию. После обновления до 10.11.1 я смог все исправить и снова начал работать с homebrew, но чаще всего каждый раз, когда я делал обновление brew, разрешения менялись снова. Меня беспокоило то, что программное обеспечение постоянно меняло привилегии в / usr / local.
Тим Х

@TimX Да, это вроде отстой ... К счастью, похоже, что Sophos исправляет его в конце следующей недели, 20 ноября.
Другие

4

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


2

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

Как насчет написания сторожевого таймера в Automator или с помощью Hazel (действия с папками) для просмотра этой конкретной папки, но вместо добавления функции, такой как Scale images, вы просто используете скрипт-оболочку, который выполняет несколько команд оболочки:

  • Если папка каким-либо образом изменена, просто сделайте снимок прав доступа и идентификатора текущего процесса с помощью fuser <foldername>.
  • затем вы ищите в таблице процессов идентификатор процесса ( ps auxwwwwww | grep <process id>) и, наконец,
  • напишите себе электронное письмо с этой собранной информацией.

К сожалению, я не Automator sadhu, но я узнал от Google, что есть множество решений для подобной проблемы.


0

Если вы используете Time Machine, вы можете найти приблизительное время изменения разрешений, просматривая Backups.backupdbв Терминале. Использовать ls -ldв папках с метками времени, например

ls -ld /Volumes/Backup/Backups.backupdb/Mac/2015-12-25-120000/Macintosh\ HD/usr/local 

Который покажет информацию о владельце и группе.

Получив дату, когда произошло изменение, вы можете выяснить, что еще могло измениться в вашей системе. Простой способ - использовать Файл Finder ›Найти и добавить Last modified dateкритерий. Другие хорошие инструменты есть findи mdfindв Терминале.


-1

Это побочный эффект обновления вашей системы; OS X, вероятно, выполняет некоторые "общие" разрешения на "восстановление" в процессе обновления, так как / usr / local размещается в папке, принадлежащей корню.


AFAICT, переход на El Capitan - вот что вызвало у меня проблему
Джузеппе

-3

Использовали ли вы Disk Utilityselect, Macintosh HDзатем run Verify Disk Permissionи затем, Repair Disk Permissionесли необходимо, вместо того, чтобы делать это вручную?

Теперь это не должно исправить вашу проблему, но это хорошая «известная» отправная точка, чтобы увидеть, когда home-brew меняет разрешения. Это может показать основную проблему, если вам повезет.

Также new update -vдля более подробного вывода, плюс старые журналы здесь ~/Library/Logs/Homebrewв соответствии с Где журнал доморощенного?


2
Disk Utilityне будет проверять или восстанавливать разрешения, /usr/localтак как этот каталог не существует в новой установке Yosemite.
дан

Я полностью проверил эту гипотезу о Йосемити, создав новую /usr/localпринадлежность мне и запустив ее DU. Там нет ничего /usr/localв DUжурнале. И /usr/localдо сих пор принадлежит мне.
дан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.