Ubuntu пишет Permission denied: что делать с правами на файлы

Вы меняете конфиг, сохраняете скрипт или просто заходите в чужую папку по SSH - и вместо результата получаете одну и ту же строку: Permission denied. Она не говорит, что именно сломалось - файл, каталог или сам способ запуска - и это первая причина, почему на ней теряют часы. На деле Permission denied в Ubuntu почти всегда значит одно: вашему пользователю не хватает конкретного бита права - на чтение, запись или выполнение - для конкретного объекта в файловой системе. Разбираемся, как читать вывод ls -l, что реально означают числа вроде 644 и 755 в chmod, чем chown отличается от chmod и почему сайт может отдавать 403 Forbidden, даже когда права на сам файл выглядят правильно.

Коротко. Permission denied означает, что вашему пользователю не хватает права на конкретное действие с конкретным файлом или каталогом - а не то, что система сломана. chmod меняет права: числовой формат вроде 644 или 755 раскладывается на три группы по три бита - владелец, группа, остальные, где r=4, w=2, x=1. Для файла x значит «можно запустить», для каталога - совсем другое: «можно войти и обратиться к содержимому по имени», и путаница между этими двумя x - самая частая ошибка новичков. chown меняет владельца и группу (chown user:group файл) и почти всегда требует sudo, даже на своих файлах - в отличие от chmod, где sudo нужен только на чужих файлах. Классика с 403 Forbidden на сайте - права стоят только на последней папке, а веб-сервер не может пройти через один из родительских каталогов выше по пути. umask задаёт права, с которыми создаются новые файлы - у root это обычно 022, а у обычного пользователя на Ubuntu чаще 002 (из-за user-private групп), поэтому свежий файл у обычного пользователя обычно 664, а не 644. И главное: chmod -R 777 не чинит права, а маскирует симптом, открывая всё на запись буквально всем - для сложных случаев с несколькими пользователями лучше setfacl, чем «дать всем всё».

Что значит Permission denied - и почему это не одна ошибка, а три разных

Права доступа в Linux - это не общий переключатель «можно / нельзя», а три отдельных бита на три категории пользователей: чтение (r), запись (w) и выполнение (x). Ошибка Permission denied в Ubuntu возникает, когда системе не хватает конкретного бита для конкретного действия, и текст сообщения при этом обычно чуть отличается в зависимости от того, что именно вы пытались сделать - это полезная подсказка, если знать, куда смотреть.

• Пытаетесь прочитать или изменить содержимое файла, но у вас нет на это права: cat: secret.env: Permission denied.
• Пытаетесь запустить файл как программу через ./, но у файла нет бита выполнения: -bash: ./deploy.sh: Permission denied.
• Пытаетесь зайти в каталог, где у вас нет права на вход: -bash: cd: /root/private: Permission denied.
• Пытаетесь получить список файлов в каталоге, куда вам закрыт вход: ls: cannot open directory 'private': Permission denied.

Если такая же по смыслу ошибка вылезает не при работе с файлом на сервере, а в момент самого SSH-подключения - например, Permission denied (publickey) при попытке зайти по ssh - это отдельная история про аутентификацию, а не про права на файлы внутри сервера. Она разобрана отдельно в статье про вход под root и SSH.

Как читать вывод ls -l

Прежде чем что-то менять, стоит научиться видеть текущие права. Команда ls с флагом -l - выводит подробный (long) список файлов, включая права, владельца и размер:

ls -l site.conf

Что вы увидите: строку вида -rw-r--r-- 1 deploy deploy 1042 сен 10 09:14 site.conf. Разберём её по частям:

• первый символ - тип объекта: - для обычного файла, d для каталога, l для символической ссылки (файла-указателя на другой файл);
• следующие девять символов - права, тремя группами по три: rw- для владельца, r-- для группы, r-- для всех остальных;
• число после прав - количество жёстких ссылок на объект, для новичка можно не вникать;
• дальше два имени - владелец файла и группа, к которой он приписан;
• затем размер в байтах, дата изменения и имя файла.

Для каталога первая буква будет d, а не -: например, drwxr-xr-x 3 deploy deploy 4096 сен 10 09:14 public. Дальше в статье разница между правами на файл и на каталог станет центральной темой - у каталогов x значит совсем не то же самое, что у файлов.

chmod числами: что реально означают 644, 755, 700

chmod (от change mode) - команда, которая меняет права на файл или каталог. Числовой формат из трёх цифр самый быстрый способ ей пользоваться, если понять, откуда эти цифры берутся. Каждая цифра - это сумма трёх значений: чтение (r) стоит 4, запись (w) стоит 2, выполнение (x) стоит 1. Три цифры подряд относятся, в этом порядке, к владельцу файла, к группе и ко всем остальным пользователям системы.

chmod 644 site.conf

Что вы увидите после этого в ls -l: -rw-r--r--. Разложим 644 по цифрам: первая 6 = 4+2 = владелец может читать и писать, но не выполнять; вторая 4 = группа может только читать; третья 4 = все остальные тоже только читать. Это стандартные права для обычного файла - конфига, HTML-страницы, изображения.

Теперь важная вещь, которую легко упустить: значение x в этой сумме означает разное в зависимости от того, файл это или каталог. Для файла x значит «этот файл можно запустить как программу». Для каталога x означает совсем другое действие - «можно войти в этот каталог и обратиться к файлам внутри него по имени», это иногда называют правом прохода. Без x на каталоге вы не сможете зайти в него через cd, даже если у вас есть право на чтение (r) - право на чтение каталога даёт только список имён файлов внутри через ls, но не доступ к самим файлам. Именно поэтому у рабочих каталогов почти всегда стоит 755 (владелец - всё, остальные - вход и просмотр, но не запись), а не 644 - без x каталог был бы практически бесполезен, в него нельзя было бы попасть.

chmod буквами: когда цифры неудобны

Буквенный формат chmod меняет не все три группы прав разом, а только то, что вы явно указали - удобно, когда нужно поправить один конкретный бит, не пересчитывая всё число заново. Буквы u, g, o, a обозначают владельца (user), группу (group), остальных (other) и всех сразу (all); знаки +, -, = означают добавить право, убрать право или задать права точно такими, как указано:

chmod u+x deploy.sh
chmod go-w site.conf
chmod a+r image.png

• u+x - добавляет право на выполнение только владельцу, остальные права файла не трогает;
• go-w - убирает право на запись у группы и у всех остальных, оставляя владельца как был;
• a+r - добавляет право на чтение сразу всем трём категориям.

На практике оба формата равноправны, числовой быстрее печатать, буквенный понятнее читать в скрипте, когда меняется только одна вещь - переключаться между ними не обязательно, выбирайте по ситуации.

chown: кто владелец, и при чём тут sudo

У каждого файла в Linux есть не только права, но и два конкретных атрибута - владелец (пользователь) и группа, оба видны в третьей и четвёртой колонках вывода ls -l. chown (от change owner) меняет один из этих атрибутов или оба сразу:

sudo chown deploy:deploy site.conf

• chown user:group файл - меняет и владельца, и группу одновременно;
• chown user файл - без двоеточия - меняет только владельца, группа файла остаётся прежней;
• chown :group файл - меняет только группу, владелец остаётся прежним (для этого есть и отдельная команда chgrp, делает то же самое).

Здесь есть развилка, в которой путаются: когда нужен sudo, а когда нет. Для chmod правило простое - если файл ваш собственный, sudo не нужен, менять права на своём файле разрешено без повышения привилегий; sudo нужен, только когда файл принадлежит другому пользователю или root - например, при правке чего-то в /etc/. Для chown правило строже, но только в части владельца: смена владельца файла почти всегда требует sudo, даже если файл сейчас ваш - иначе рядовой пользователь мог бы просто передать файл кому-то ещё, а вместе с ним и место, которое файл занимает в дисковой квоте. А вот смена группы (chown :group файл или chgrp group файл) sudo не требует, если вы и так состоите в целевой группе - именно так на практике чаще всего и открывают файл для www-data без root: не меняют владельца, а добавляют файл в группу, в которой уже состоит веб-сервер.

Классика: сайт отдаёт 403 Forbidden, хотя права на файл вроде верные

Один из самых частых кейсов на практике - вы поставили права на конечный файл или последнюю папку сайта, всё выглядит правильно, а браузер всё равно показывает 403 Forbidden. Причина почти всегда в том, что права проверены не там: веб-сервер работает от отдельного системного пользователя - на Ubuntu и Debian это обычно www-data - и для доступа к файлу ему нужны сразу две вещи: право на чтение самого файла и право на проход (x) через каждый родительский каталог на пути к нему, а не только через последний.

Представьте путь /var/www/mysite/public/index.html. Если каталог /var/www/mysite стоит с правами 700 и принадлежит вашему пользователю deploy, а public/ и сам index.html настроены идеально - www-data всё равно получит отказ, потому что не может пройти самый первый каталог в цепочке. Права на конечный файл в этой ситуации вообще не имеют значения: до него просто не добираются.

Проверить всю цепочку разом помогает namei с флагом -l - команда построчно раскладывает путь и показывает права на каждый его сегмент:

namei -l /var/www/mysite/public/index.html

Что искать в выводе: строку за строкой для каждого каталога в пути, где нужно, чтобы у группы или у остальных стоял бит x (в зависимости от того, как настроен доступ) - если на каком-то из промежуточных каталогов, включая сам /var/www/mysite, x отсутствует у всех, кроме владельца, - вот и причина 403. Без sudo вывод оборвётся ровно на первом непроходимом каталоге («Permission denied» вместо продолжения списка) - это тоже полезно: место обрыва само указывает на виновника, даже не нужно доходить до конца. Исправление - добавить проход именно туда, где его не хватает, не трогая остальное:

sudo chmod o+x /var/www/mysite

Это открывает вход в каталог всем, оставляя запись закрытой - обычно этого достаточно и безопаснее, чем менять владельца сайта на www-data целиком. На практике 403 Forbidden после правки прав почти никогда не про сам файл - это почти всегда один из родительских каталогов, который забыли.

Забыли chmod +x: Permission denied при ./script.sh

Ещё один частый сценарий: вы только что создали или скачали скрипт, пробуете запустить его напрямую - и получаете отказ:

./deploy.sh

Что вы увидите: -bash: ./deploy.sh: Permission denied. Причина простая - у файла нет бита выполнения, а запуск через ./ просит систему выполнить файл напрямую как программу. Строка #!/usr/bin/env bash в начале файла (шебанг - она указывает, каким интерпретатором запускать остальное содержимое) тут не спасает: система сначала проверяет, можно ли вообще выполнять этот файл, и только потом смотрит, что в нём написано.

chmod +x deploy.sh
./deploy.sh

После chmod +x та же команда сработает. Но есть развилка, которую стоит знать: если вместо прямого запуска вы вызываете скрипт через интерпретатор явно - bash deploy.sh, а не ./deploy.sh - бит выполнения вообще не нужен. В этом случае файл не запускается системой как отдельная программа, его открывает и построчно читает уже сам bash, а для чтения достаточно обычного права r. Если видите готовый туториал, где скрипт запускают через bash script.sh, а не ./script.sh, и при этом нет ошибки о правах - это не опечатка в инструкции, а сознательный выбор автора.

umask: почему новый файл не открыт всем сразу

Права новых файлов и каталогов не берутся из воздуха - ими управляет umask, значение, которое снимает указанные биты с базовых прав в момент создания объекта (это маска, а не вычитание - ниже будет важная оговорка). У обычного файла база - 666 (чтение и запись всем, без выполнения - большинство файлов изначально не должны быть программами), у каталога база - 777 (каталогу всегда нужен x, иначе в него нельзя будет войти). Посмотреть текущее значение можно так:

umask

Что вы увидите: для root это обычно 0022, а для обычного пользователя на Ubuntu - чаще 0002. Разница не случайна: Ubuntu по умолчанию включает USERGROUPS_ENAB в /etc/login.defs, и каждый обычный пользователь получает свою собственную группу того же имени - в этой схеме групповые права специально приравниваются к правам владельца, поэтому маска мягче. На практике: у root новый файл выйдет 644, у обычного пользователя - 664 (группа тоже может писать), у каталога соответственно 755 у root и 775 у обычного пользователя. Проверить на практике:

touch newfile.txt && ls -l newfile.txt
mkdir newdir && ls -ld newdir

Под обычным пользователем на образе Ubuntu первая команда обычно покажет -rw-rw-r--, вторая - drwxrwxr-x - не пугайтесь лишнего w у группы, это и есть 002. Значение umask не высечено в камне и меняется на время сессии, например командой umask 027. Но важно: для 022 и 002 арифметика «база минус umask» случайно совпадает с побитовым снятием прав, а для многих других значений - нет. Например, 027 не даёт 666−027=639 (числа такого режима не существует): маска 027 снимает у группы бит записи и у остальных - чтение, запись и выполнение, реальный результат для файла - 640, для каталога - 750. Если нужно закрыть новые файлы от посторонних, проверяйте результат командой umask 027 && touch test && ls -l test, а не считайте вычитанием в столбик.

Чего не делать: chmod -R 777 и рекурсия не глядя

Флаг -R у chmod и chown применяет изменение рекурсивно, ко всему поддереву каталогов и файлов сразу - удобно, когда действительно нужно поправить права массово, и опасно, когда команда набрана не задумываясь. chmod -R 777 - самый частый пример: он «чинит» ошибку доступа, потому что делает буквально всё доступным всем, и именно поэтому его стоит избегать, а не потому что это просто «плохая практика» без объяснения.

Что именно ломается:

• файлы становятся доступны на запись не только вам, а вообще любому пользователю или процессу на сервере - если туда попадёт скомпрометированный скрипт или чужой аккаунт на общем хостинге, он сможет переписать содержимое сайта без каких-либо дополнительных барьеров;
• пропадает разница между файлом и каталогом - даже обычные данные вроде картинок и текстовых файлов получают бит выполнения, который им не нужен и ничего не даёт, кроме путаницы при следующей проверке прав;
• некоторые программы сами отказываются работать со слишком открытыми правами - например, ssh откажется использовать приватный ключ, если он доступен на чтение группе или всем (тут не нужна даже запись - хватает лишнего r), и откажется использовать каталог ~/.ssh, если он открыт на запись группе или всем - для ключа и для каталога проверяются разные биты, но оба отказа выглядят как «too open»/«bad permissions»;
• рекурсивная команда, запущенная не в том каталоге - опечатка в пути или лишний пробел рядом с / - меняет права далеко за пределами того, что вы хотели поправить, и для системных каталогов это может привести к тому, что сервер вообще перестанет нормально работать.

Правильный путь - чинить конкретное место, где не хватает конкретного бита, а не выравнивать всё дерево под одно число. Если действительно нужно массово привести права в порядок после переноса файлов, разумнее развести файлы и каталоги, а не задавать им одинаковые права:

sudo find /var/www/mysite -type d -exec chmod 755 {} \;
sudo find /var/www/mysite -type f -exec chmod 644 {} \;

Первая команда ставит 755 только на каталоги (им нужен x, чтобы в них можно было заходить), вторая - 644 только на файлы (им бит выполнения обычно не нужен вовсе). Для более сложных случаев - когда над одной и той же папкой должны работать сразу несколько пользователей с разным уровнем доступа, например ваш деплой-пользователь с правом записи и www-data только с правом чтения - классической триады владелец/группа/остальные иногда не хватает. Тогда есть ACL (списки контроля доступа, Access Control Lists) - более гибкий механизм, который позволяет назначить права конкретному дополнительному пользователю или группе поверх обычных. Пакет с утилитами для этого на Ubuntu обычно нужно поставить отдельно:

sudo apt install acl
sudo setfacl -m u:www-data:rX /var/www/mysite
getfacl /var/www/mysite

Это тема отдельной статьи, но как направление для сложных случаев - держите в уме: если классических прав не хватает, следующий шаг это ACL, а не поголовное 777.

Что значит Permission denied в Ubuntu?

Это означает, что вашему текущему пользователю не хватает конкретного права - на чтение, запись или выполнение - для конкретного файла или каталога. Точная причина зависит от того, что вы пытались сделать: открыть файл, запустить его напрямую через ./ или зайти в каталог - у каждого случая своя типичная формулировка ошибки, но смысл один и тот же.

Как дать права на файл в Ubuntu через chmod?

Командой chmod, либо числами (chmod 644 файл - владелец читает и пишет, остальные только читают), либо буквами (chmod u+w файл - добавить владельцу право записи). Менять права можно только на своих файлах без sudo; для файлов, принадлежащих другому пользователю или root, нужен sudo chmod.

Что означает chmod 755 и чем он отличается от 644?

755 даёт владельцу полный доступ (читать, писать, выполнять), а группе и всем остальным - право читать и выполнять, но не записывать; это стандартные права для каталогов и исполняемых скриптов. 644 не даёт права на выполнение вообще никому, только чтение остальным и чтение с записью владельцу - это стандартные права для обычных файлов вроде конфигов и HTML-страниц.

Чем chown отличается от chmod?

chmod меняет, что именно разрешено делать с файлом - права на чтение, запись, выполнение. chown меняет, кому файл принадлежит - владельца и группу. chmod на своём файле не требует sudo, а chown требует его почти всегда, потому что передавать файл другому владельцу разрешено только пользователю с административными правами.

Почему сайт выдаёт 403 Forbidden, если права на сам файл в порядке?

Чаще всего дело не в самом файле, а в одном из родительских каталогов на пути к нему - веб-серверу (обычно это пользователь www-data) нужен не только доступ к файлу, но и право на проход через каждый каталог по пути, начиная от корня. Диагностировать всю цепочку разом помогает команда namei -l /путь/к/файлу - она построчно покажет права на каждый сегмент пути.

Почему ./script.sh пишет Permission denied, хотя файл только что создан?

Потому что у файла нет бита выполнения - запуск через ./ требует, чтобы система могла выполнить файл напрямую как программу. Решение - chmod +x script.sh. Если вместо этого вызвать скрипт через интерпретатор явно, например bash script.sh, бит выполнения вообще не нужен - файл в этом случае просто читается, а не запускается напрямую.

Можно ли сделать chmod -R 777, чтобы точно всё заработало?

Технически да, ошибка доступа пропадёт - но вместе с ней пропадёт и всякая защита: файлы станут доступны на запись любому пользователю или процессу на сервере, а не только вам. Это не решение проблемы, а маскировка симптома с широким побочным эффектом. Правильнее найти конкретное место, где не хватает конкретного бита - например, через namei -l для случая с сайтом - и поправить только его.

Коротко

• Permission denied означает нехватку конкретного бита прав - чтения, записи или выполнения - для конкретного файла или каталога, а не сломанную систему.
• chmod меняет права: три цифры для владельца/группы/остальных, где r=4, w=2, x=1; для файла x значит «можно запустить», для каталога - «можно войти и обратиться к содержимому по имени», это разные вещи.
• chown user:group файл меняет владельца и группу; почти всегда требует sudo, даже на своих файлах - в отличие от chmod, где sudo нужен только на чужих файлах.
• 403 Forbidden при верных правах на файл почти всегда означает, что веб-сервер не может пройти через один из родительских каталогов - проверяйте всю цепочку через namei -l, а не только последнюю папку.
• Permission denied при ./script.sh обычно значит «забыли chmod +x» - но не нужен, если скрипт запускают через bash script.sh явно.
• umask определяет права новых файлов и каталогов - у root обычно 022 (файл 644), у обычного пользователя на Ubuntu чаще 002 (файл 664) - это не случайные числа, но и не «вычитание», а снятие битов маской.
• chmod -R 777 не решает проблему прав, а открывает всё на запись всем и всему на сервере - для сложных случаев с несколькими пользователями используйте setfacl, а не плоское «дать всем всё».

Что дальше

Если вместо ошибки в правах у вас команда вообще не находится - это другая история, разобранная в статье command not found в Ubuntu. Если Permission denied появляется не при работе с файлами, а в момент самого входа на сервер - через su, sudo или прямое SSH-подключение под root - смотрите статью про вход под root в Ubuntu. А полный список типичных проблем на свежем Linux-сервере собран в материале частые проблемы Linux-сервера.