Ошибка «Permission denied» в Linux — причины появления и способы исправления

Ошибка Permission denied — одна из самых распространенных в Linux. Она может появиться при запуске программы, работе с файлами, подключении по SSH, настройке Nginx, использовании Docker или выполнении обычной команды.

Оно означает что текущему пользователю запрещено выполнять нужное действие.

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

• Что означает ошибка Permission denied
• С чего начать
• Причина №1. Пользователь не имеет административных прав
• Причина №2. Нет прав на выполнение файла
• Причина №3. Недостаточно прав на файл
• Причина №4. Нет прав на каталог
• Как быстро проверить права
• Где искать информацию
• Полезный чек-лист диагностики
• Заключение

Что означает ошибка Permission denied

В Linux почти каждое действие проверяется системой безопасности. Например, когда программа пытается открыть файл или записать данные ОС сначала проверяет, есть ли у пользователя необходимые права. Если разрешения отсутствуют, выполнение прекращается, а система возвращает ошибку:

Permission deniedCopy

Иногда доступ запрещает каталог, SELinux, AppArmor или даже неправильный пользователь, от имени которого запущена служба.

С чего начать

Можно последовательно проверить:

1. От имени какого пользователя выполняется команда.
2. Какие права имеет файл или каталог.
3. Кто является владельцем.
4. Не мешает ли SELinux или AppArmor.
5. Не пытается ли приложение получить доступ к неправильному пути.

Причина №1. Пользователь не имеет административных прав

Некоторые операции в Linux доступны только пользователю root или пользователям, которым разрешено использовать sudo.

Например, если выполнить:

sudo apt updateCopy

можно увидеть сообщение:

testuser is not in the sudoers file.Copy

Это означает, что текущий пользователь не имеет административных прав. В этом случае сама команда sudo не поможет.

Проверьте, от имени какого пользователя вы работаете:

whoamiCopy

Затем посмотрите, в какие группы он входит:

idCopy

Если среди групп нет sudo (Ubuntu, Debian) или wheel (CentOS, Rocky Linux, AlmaLinux), выполнять административные команды не получится.

Чтобы добавить пользователя в группу sudo в Ubuntu или Debian, войдите под пользователем с административными правами и выполните:

sudo usermod -aG sudo testuserCopy

Для CentOS, Rocky Linux и AlmaLinux используется группа wheel:

sudo usermod -aG wheel testuserCopy

После этого выйдите из текущего сеанса и войдите снова. Новое членство в группах применяется только после повторного входа в систему.

Если пользователь уже состоит в группе sudo, но команда все равно завершается ошибкой Permission denied, значит проблема связана с доступом к файлам или каталогам, а не с административными привилегиями.

Причина №2. Нет прав на выполнение файла

Очень часто ошибка возникает при запуске скриптов.

Например:

./install.shCopy

Если файл не имеет права на выполнение, появится сообщение:

Permission deniedCopy

Проверьте разрешения.

ls -l install.shCopy

Например:

-rw-r--r-- 1 user user 2048 install.shCopy

Здесь отсутствует символ x, который означает право на выполнение.

Исправить можно так:

chmod +x install.shCopy

После этого скрипт станет исполняемым.

Причина №3. Недостаточно прав на файл

Даже если файл существует и путь указан правильно, операция может завершиться ошибкой Permission denied. Обычно это происходит, когда текущий пользователь пытается изменить файл, владельцем которого является другой пользователь.

Посмотреть владельца и права можно командой:

ls -l filenameCopy

Например:

-rw-r--r-- 1 root root 1250 Jul 15 12:30 filenameCopy

В этом случае обычный пользователь сможет прочитать файл, но изменить его уже не получится.

Например:

echo "test" >> filenameCopy

Результат:

bash: filename: Permission deniedCopy

Если файл действительно должен принадлежать текущему пользователю, измените владельца:

sudo chown user:user filenameCopy

Для каталога вместе со всем содержимым:

sudo chown -R user:user projectCopy

Такая ситуация часто возникает после копирования файлов с помощью sudo, распаковки архива от имени root или восстановления проекта из резервной копии. В результате приложение запускается от обычного пользователя, но не может изменить собственные файлы.

Причина №4. Нет прав на каталог

Доступ нужен не только к файлу, но и ко всем каталогам на пути к нему.

Например, файл может иметь права:

-rw-r--r--Copy

но если каталог закрыт для чтения или выполнения, открыть файл все равно не получится.

Проверьте права каталогов:

ls -ld /path/to/directoryCopy

Для доступа к каталогу пользователю требуется право x. Без него система даже не сможет перейти внутрь, независимо от разрешений самого файла.

 sudo chmod 755 /tmp/secretCopy

Как быстро проверить права

Для большинства ситуаций достаточно команды.

ls -lahCopy

Она показывает:

• владельца;
• группу;
• права доступа;
• размер файла;
• дату изменения.

Если нужно узнать права сразу для всей цепочки каталогов, удобно использовать:

namei -l /полный/путь/к/файлуCopy

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

Где искать информацию

Если ошибка возникает при работе службы, откройте ее журнал.

Например:

journalctl -u nginx -n 100Copy

или

journalctl -u postgresql -n 100Copy

Также полезно посмотреть системный журнал.

journalctl -xeCopy

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

Полезный чек-лист диагностики

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

whoami
id
ls -l filename
ls -ld /path/to/directory
namei -l /path/to/file
getenforce
journalctl -xeCopy

Такого набора обычно достаточно, чтобы определить, связана ли проблема с правами, владельцем, каталогом или дополнительными механизмами защиты.

Заключение

Ошибка Permission denied означает, что Linux сознательно запретил выполнение операции из-за недостаточных прав или ограничений безопасности. Чаще всего причина связана с владельцем файла, разрешениями, доступом к каталогу или политиками SELinux и AppArmor.