Jak dowiedzieć się, co powoduje zmianę własności / usr / local z mojej nazwy użytkownika na root


13

Używam homebrewjako menedżera pakietów dla niektórych aplikacji do tworzenia stron internetowych. Aby brewbyć na bieżąco, biegam update brewco kilka dni, a także biegam brew doctor. Zwykle jest to w porządku i brewmówi mi, że jestem gotowy do zaparzenia.

Od czasu do czasu pojawia się jednak następujący błąd:

Ostrzeżenie: / usr / local / etc nie jest zapisywalny.

Może się tak zdarzyć, jeśli oprogramowanie „sudo make install” nie jest zarządzane przez Homebrew. Jeśli formuła spróbuje zapisać plik w tym katalogu, instalacja nie powiedzie się podczas kroku łączenia.

Powinieneś prawdopodobnie chown/ usr / local / etc

Ostrzeżenie: katalogu / usr / local nie można zapisywać. Nawet jeśli ten katalog był zapisywalny po zainstalowaniu Homebrew, inne oprogramowanie może zmienić uprawnienia do tego katalogu. Niektóre wersje komponentu „InstantOn” Airfoil są znane z tego.

Prawdopodobnie powinieneś zmienić własność i uprawnienia / usr / local z powrotem na swoje konto użytkownika.

Zresetowanie uprawnień z powrotem do mojej nazwy użytkownika jest dość łatwe. Potem brewwydaje się być w porządku.

Ale co powoduje to?

Czy istnieje dziennik pokazujący, co powoduje zmianę uprawnień?


3
Nie ma dziennika, ale zauważ, że posiadanie / usr / local przez rood jest standardem Unix, więc każda kompilacja w nim się tego spodziewa. Rozwiązaniem jest nie mieszanie katalogu zarówno z menedżerem pakietów (Homebrew), jak i standardową kompilacją Uniksa - Użyj innego katalogu dla jednego z nich
użytkownik151019

3
Dodanie oprogramowania do tej samej lokalizacji, z której korzysta menedżer pakietów, jest złym pomysłem, podobnie jak zmiana własności i uprawnień /usr/local. Ale jeśli nalegasz, możesz to zrobić make installbez użycia sudopakietów, które sam instalujesz.
fd0,

1
Aktualizacja OS X zwykle resetuje / usr / local własność i uprawnienia.
mspasov

1
@Inne ah Czytam cytat z Homebrew zamiast pytania
151019

1
Co jeszcze zainstalowałeś (ręcznie lub za pomocą dowolnego innego menedżera pakietów) na komputerze Mac, który został skonfigurowany do instalacji domyślnej /usr/local?
dan

Odpowiedzi:


13

Miałem dokładnie ten sam problem i okazało się, że winna była automatyczna aktualizacja Sophos. Zrozumiałem to, uruchamiając:sudo fs_usage | grep "usr/local"

Minęło trochę czasu, ale w końcu zobaczyłem pomocnego demona Sophosa o nazwie „Instalacja”, który bałagał się uprawnieniami / usr / local.

Nadal próbuję znaleźć odpowiednią metodę obejścia tego zachowania.

EDYCJA: Wierzę, że Sophos naprawił ten problem, patrz link w komentarzach do tej odpowiedzi. Wydaje mi się, że przynajmniej zostało to naprawione!


4
Dyskusja tutaj: community.sophos.com/products/free-antivirus-tools-for-desktops/… Powinno to zostać naprawione w listopadzie 2015 r.
JoeZuntz

@JoeZuntz Ładne znalezisko! Niesamowite, że oni naprawiają.
Inni

@ inne dzięki za tę informację. Byłem w stanie naprawić wszystko po aktualizacji do 10.11.1 i ponownie uruchomiłem homebrew, ale częściej niż nie, za każdym razem, gdy robiłem aktualizację naparu, uprawnienia ponownie się zmieniały. Denerwowało mnie to, jakie oprogramowanie zmieniało perms na / usr / local.
Tim X

@TimX Tak, to trochę do bani ... Na szczęście wygląda na to, że Sophos załatał to pod koniec przyszłego tygodnia, 20 listopada.
Inni

4

Okazuje się, że winowajcą jest Filewave. Filewave to oprogramowanie do zarządzania systemem używane przez naszą szkołę do przekazywania aktualizacji oprogramowania. Dzięki za wkład.


2

Mam tylko przybliżony pomysł, jak zdobyć złodzieja zezwoleń. To nie jest rozwiązanie twojego problemu, ale coś w rodzaju obejścia.

Co powiesz na napisanie watchdoga w Automatorze lub Hazel (akcje folderów) do oglądania tego konkretnego folderu, ale zamiast dodania funkcji takiej jak Skalowanie obrazów, po prostu używasz shellscript, który wykonuje kilka poleceń powłoki:

  • Jeśli folder zostanie zmieniony w jakikolwiek sposób, po prostu zrób migawkę uprawnień i identyfikatora procesu, który aktualnie uzyskuje dostęp za pomocą fuser <foldername>.
  • następnie sprawdzasz w tabeli procesów id procesu ( ps auxwwwwww | grep <process id>) i na końcu
  • napisz do siebie wiadomość e-mail z tymi zebranymi informacjami.

Niestety nie jestem sadhu Automatora, ale dowiedziałem się od Google, że istnieje wiele rozwiązań podobnych problemów.


0

Jeśli korzystasz z Wehikułu Czasu, możesz znaleźć przybliżony czas zmiany uprawnień, eksplorując Backups.backupdbw Terminalu. Użyj ls -ldw folderach ze znacznikami czasu, np

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

Które pokażą informacje o właścicielu i grupie.

Po ustaleniu daty zmiany możesz dowiedzieć się, co jeszcze mogło się zmienić w twoim systemie. Prostą techniką jest użycie Pliku Findera ›Znajdź i dodaj Last modified datekryterium. Inne narzędzia są dobre findi mdfindw terminalu.


-1

Jest to efekt uboczny aktualizacji systemu; OS X prawdopodobnie dokonuje „ogólnej” naprawy „uprawnień” podczas procesu aktualizacji, ponieważ / usr / local jest zagnieżdżony w folderze będącym własnością root.


AFAICT, uaktualnienie do El Capitan było tym, co spowodowało problem
Giuseppe,

-3

Czy używałeś polecenia Disk Utilityselect, Macintosh HDa następnie uruchom, Verify Disk Permissiona następnie w Repair Disk Permissionrazie potrzeby, zamiast robić to ręcznie?

Teraz to nie powinno rozwiązać problemu, ale jest to dobry „znany” punkt wyjścia, aby zobaczyć, kiedy home-brew zmieni uprawnienia. Jeśli masz szczęście, może pojawić się podstawowy problem.

Również w new update -vcelu uzyskania bardziej szczegółowych informacji, a także starych dzienników, ~/Library/Logs/Homebrewjak w artykule Gdzie dziennik homebrew?


2
Disk Utilitynie weryfikuje ani nie naprawia uprawnień, /usr/localponieważ ten katalog nie istnieje w nowej instalacji Yosemite.
dan

W pełni sprawdziłem tę hipotezę na Yosemite, tworząc nową własność /usr/locali działając DU. Nie ma żadnego /usr/localw DUdzienniku. I /usr/localwciąż należy do mnie.
dan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.