Ошибка Permission denied на macOS: причины и 5 способов исправить

Что такое ошибка «Permission denied» на macOS?

Ошибка «Permission denied» (рус. «Отказано в доступе») — это системное сообщение, которое появляется, когда текущий пользователь macOS не имеет прав на выполнение операции (чтение, запись, выполнение) с файлом или папкой. В отличие от Windows, macOS использует UNIX-подобную модель прав доступа, а также добавляет собственные механизмы защиты, такие как SIP (System Integrity Protection) и ACL (Access Control Lists). Это делает диагностику иногда более сложной, но и более гибкой.

Симптомы:

• В Терминале: zsh: permission denied: <файл> или cp: <файл>: Permission denied.
• В Finder: кнопка «Открыть» неактивна, или появляется попап «Вы не имеете разрешения на доступ к этому элементу».
• Приложения (например, VS Code, Docker) не могут сохранить конфигурационные файлы в системных папках.

Основные причины ошибки

1. Владелец файла другой — файл создан другим пользователем (например, root), а ваш аккаунт не входит в группу с правами.
2. Права доступа (chmod) слишком строгие — например, -rw------- (только владелец).
3. Активна ACL — расширенные правила доступа, которые могут явно запрещать вашему пользователю доступ, даже если стандартные права (chmod) разрешают.
4. SIP (System Integrity Protection) — защищает системные папки (/System, /usr, /bin, /sbin) от модификации даже администратором.
5. App Translocation — когда приложение из неизвестного источника запускается в изолированной временной папке, и оно не может писать в свои собственные ресурсы.
6. Файл заблокирован (locked) в Finder (флажок «Заблокировать» в «Get Info»).

Пошаговое решение

Шаг 1: Определите точный путь и текущие права

Откройте Терминал (Терминал → Стандартная). Выполните команду, подставив ваш путь:

ls -l /путь/к/файлу_или_папке

Пример вывода:

drwxr-xr-x  5 root    wheel    160 Feb 14 10:00 SomeFolder
-rw-r--r--  1 root    wheel      0 Feb 14 10:00 file.txt

Расшифровка:

• drwxr-xr-x — папка (d), права: владелец (rwx), группа (r-x), остальные (r-x).
• root — владелец, wheel — группа.
• Если владелец не ваш ($(whoami)), это вероятная причина.

Шаг 2: Смените владельца (chown)

Если владелец — root или другой пользователь, смените его на вашего. Для папки рекурсивно:

sudo chown -R $(whoami) /путь/к/папке

Для отдельного файла (без -R):

sudo chown $(whoami) /путь/к/файлу

Введите пароль администратора (символы не отображаются).

Шаг 3: Обновите права доступа (chmod)

После смены владельца дайте права. Самые частые варианты:

• Владелец: чтение + запись (файл):

  chmod u+rw /путь/к/файлу
  

• Владелец: полный доступ, группа/остальные: чтение (папка):

  chmod -R u=rwx,go=rx /путь/к/папке
  

• Все: полный доступ (осторожно, только для временных решений!):

  chmod -R 777 /путь/к/папке
  

Проверьте результат:

ls -l /путь/к/файлу

Права должны измениться (например, -rw-r--r--).

Шаг 4: Проверьте и сбросьте ACL

ACL может переопределять стандартные права. Проверьте:

ls -le /путь/к/файлу

Если в выводе есть строки после стандартных прав (например, 0: group:everyone deny delete), ACL активна.

Сбросить ACL (удалить все расширенные правила, вернуться к chmod):

chmod -N /путь/к/файлу
# или для папки рекурсивно:
chmod -R -N /путь/к/папке

После этого снова проверьте ls -le — ACL-строки должны исчезнуть.

Шаг 5: Временное отключение SIP (для системных файлов)

Внимание: SIP защищает критически важные системные файлы. Отключайте его только если ошибка связана с папками /System, /usr (кроме /usr/local), /bin, /sbin, и другие методы не помогли.

1. Перезагрузите Mac, удерживая Command (⌘) + R до появления логотипа Apple → войдите в Recovery Mode.
2. В меню сверху выберите Утилиты → Терминал.
3. Выполните:

   csrutil disable
   

4. Перезагрузитесь в обычный режим.
5. Вернитесь к шагам 2–3 для нужного системного файла/папки.
6. Сразу после исправления снова включите SIP:
   • Перезагрузитесь в Recovery Mode.
   • В Терминале: csrutil enable.
   • Перезагрузитесь.

Шаг 6: Проверьте блокировку файла в Finder

Иногда файл просто заблокирован:

1. Найдите файл в Finder, нажмите Command (⌘) + I (или правой кнопкой → «Get Info»).
2. Внизу окна «Get Info» снимите галочку «Заблокировать».
3. Попробуйте снова выполнить действие.

Шаг 7: Решите проблему App Translocation (для приложений)

Если ошибка возникает в приложении из ~/Downloads или стороннего источника:

1. Перетащите приложение в папку /Applications (требуется пароль администратора).
2. Запустите приложение из папки /Applications (не из Downloads).
3. Если проблема осталась, откройте Системные настройки → Конфиденциальность и безопасность → Безопасность и разрешите запуск приложения.

Частые вопросы (FAQ)

❓ Почему sudo не помогает, а sudo chmod 777 работает?

sudo даёт вам права администратора, но если владелец файла — root, а вы пытаетесь изменить права без смены владельца, chmod может не сработать в некоторых контекстах (например, при SIP). sudo chmod 777 работает, потому что администратор может менять права любого файла, кроме защищённых SIP. Но лучше сначала сменить владельца на ваш (chown), чтобы не оставлять файлы с владельцем root.

❓ Можно ли сделать команду chmod постоянной для папки?

Да, но будьте осторожны. Для папки, которая должна быть доступна для записи всем (например, общий /tmp), можно установить sticky bit и права 1777:

sudo chmod 1777 /путь/к/папке

Это разрешит создание/удаление файлов только их владельцам, даже если папка доступна на запись всем.

❓ Ошибка «Operation not permitted» вместо «Permission denied» — это то же самое?

Частично да. «Operation not permitted» часто возникает при попытке изменить защищённые SIP-файлы без отключения SIP или при работе с файлами на зашифрованном диске (FileVault), когда диск разблокирован не для текущей сессии. Проверьте, не пытаетесь ли вы изменить файл в /System.

❓ Как дать права на папку, чтобы все пользователи Mac могли в неё писать?

1. Смените владельца на root или группу staff:

   sudo chown -R root:staff /путь/к/папке
   

2. Дайте группе (g) права на запись:

   sudo chmod -R g+w /путь/к/папке
   

3. Установите setgid bit, чтобы новые файлы в папке наследовали группу:

   sudo chmod g+s /путь/к/папке
   

Профилактика ошибки

• Не храните рабочие файлы в системных папках (/System, /usr). Используйте ~/Documents или ~/Downloads.
• При создании скриптов/файлов через Терминал сразу задавайте правильного владельца (ваш пользователь) и группу.
• Для общих папок (например, на сетевом диске) настройте ACL заранее через chmod +a:

  sudo chmod +a "username allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit" /путь/к/папке
  

• Обновляйте macOS — в новых версиях улучшена обработка прав доступа.

Что делать, если ничего не помогло?

1. Перезагрузите Mac — иногда кэш прав доступа (например, у launchd) сбрасывается.
2. Проверьте, не на внешнем диске ли файл? Если да, убедитесь, что диск смонтирован с правами на запись.
3. Если файл — символьная ссылка (symlink), проверьте права на целевом объекте, а не на самой ссылке.
4. Используйте sudo lsof | grep <файл>, чтобы увидеть, какой процесс использует файл, и завершите его (kill -9 <PID>).
5. Для домашней папки (/Users/username) проверьте, не повреждены ли права через diskutil verifyPermissions / (требует SIP) или восстановите из Time Machine.

Связанные проблемы

• Если ошибка возникает при запуске Docker или других контейнеров, проверьте права на /var/run/docker.sock (ls -l /var/run/docker.sock). Обычно нужно добавить вашего пользователя в группу docker: sudo dseditgroup -o edit -a $(whoami) -t user docker.
• При установке Homebrew пакетов могут потребоваться права на /usr/local. Решение: sudo chown -R $(whoami) /usr/local/* (осторожно, не трогайте /usr/local/bin системных утилит).
• Ошибки «Operation not permitted» при попытке изменить файл в ~/Library/Containers — это защита sandbox. Изменяйте файлы только через API приложения или в его папке Application Support.

Статья обновлена: 14 февраля 2026. Проверено на macOS Sonoma 14.5.