Как namei помогает быстро найти причину Permission denied!
Наверняка у вас была такая ситуация: файл существует, права на него вроде бы выставлены правильно, но вместо доступа получаете:
Permission denied
Смотришь на права файла — всё нормально. Меняешь владельца, проверяешь chmod — ничего не помогает. Во многих случаях проблема находится не в самом файле, а в одном из каталогов на пути к нему.
Чтобы обратиться к файлу, процесс должен иметь право прохода (x) через каждый каталог в цепочке. Именно поэтому проверка только ls -l у файла нередко ничего не показывает — проблема может быть на несколько уровней выше.
Быстро найти проблемное место помогает утилита namei. Например:
namei -l /var/www/app/storage/logs/app.log
Пример вывода:
f: /var/www/app/storage/logs/app.log
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-x--- root www-data www
drwxr-xr-x app app app
drwx------ app app storage
drwxr-xr-x app app logs
-rw-r--r-- app app app.log
namei разбивает путь на отдельные компоненты и показывает права, владельца и группу для каждого каталога и самого файла. Благодаря этому не нужно вручную выполнять ls -ld для каждого каталога на пути — вся цепочка сразу перед глазами.
Но стоит помнить, что для каталогов право x означает возможность пройти через каталог и обратиться к объекту по известному имени, а не выполнить его. Поэтому даже если файл имеет права 644, процесс всё равно получит Permission denied, если хотя бы на одном из родительских каталогов отсутствует право x. Например, каталог:
drwx------ app app storage
доступен только владельцу. Поэтому процесс, запущенный от имени www-data, не сможет открыть файл внутри этого каталога, даже если сам файл доступен на чтение.
Чтобы убедиться, что проблема действительно в правах доступа, попробуйте открыть файл от имени пользователя, под которым фактически работает приложение:
sudo -u www-data cat /var/www/app/storage/logs/app.log
И не забудьте проверить, от какого пользователя действительно запущен процесс, который обращается к файлу. Например, для nginx:
ps -o user,group,pid,cmd -C nginx
Если права выглядят корректными, проверьте ACL. Желательно не только у файла, но и у каталогов на пути к нему:
getfacl /var/www/app/storage
getfacl /var/www/app/storage/logs
getfacl /var/www/app/storage/logs/app.log
Если и здесь всё в порядке, обратите внимание на SELinux или AppArmor — они тоже нередко становятся причиной Permission denied.
🔥 namei -l — одна из тех команд, которые экономят много времени при поиске причин Permission denied. Вместо проверки каждого каталога вручную вы сразу видите весь путь и права доступа на каждом уровне.
🚪 Linux Ready | #практика
Наверняка у вас была такая ситуация: файл существует, права на него вроде бы выставлены правильно, но вместо доступа получаете:
Permission denied
Смотришь на права файла — всё нормально. Меняешь владельца, проверяешь chmod — ничего не помогает. Во многих случаях проблема находится не в самом файле, а в одном из каталогов на пути к нему.
Чтобы обратиться к файлу, процесс должен иметь право прохода (x) через каждый каталог в цепочке. Именно поэтому проверка только ls -l у файла нередко ничего не показывает — проблема может быть на несколько уровней выше.
Быстро найти проблемное место помогает утилита namei. Например:
namei -l /var/www/app/storage/logs/app.log
Пример вывода:
f: /var/www/app/storage/logs/app.log
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-x--- root www-data www
drwxr-xr-x app app app
drwx------ app app storage
drwxr-xr-x app app logs
-rw-r--r-- app app app.log
namei разбивает путь на отдельные компоненты и показывает права, владельца и группу для каждого каталога и самого файла. Благодаря этому не нужно вручную выполнять ls -ld для каждого каталога на пути — вся цепочка сразу перед глазами.
Но стоит помнить, что для каталогов право x означает возможность пройти через каталог и обратиться к объекту по известному имени, а не выполнить его. Поэтому даже если файл имеет права 644, процесс всё равно получит Permission denied, если хотя бы на одном из родительских каталогов отсутствует право x. Например, каталог:
drwx------ app app storage
доступен только владельцу. Поэтому процесс, запущенный от имени www-data, не сможет открыть файл внутри этого каталога, даже если сам файл доступен на чтение.
Чтобы убедиться, что проблема действительно в правах доступа, попробуйте открыть файл от имени пользователя, под которым фактически работает приложение:
sudo -u www-data cat /var/www/app/storage/logs/app.log
И не забудьте проверить, от какого пользователя действительно запущен процесс, который обращается к файлу. Например, для nginx:
ps -o user,group,pid,cmd -C nginx
Если права выглядят корректными, проверьте ACL. Желательно не только у файла, но и у каталогов на пути к нему:
getfacl /var/www/app/storage
getfacl /var/www/app/storage/logs
getfacl /var/www/app/storage/logs/app.log
Если и здесь всё в порядке, обратите внимание на SELinux или AppArmor — они тоже нередко становятся причиной Permission denied.
🔥 namei -l — одна из тех команд, которые экономят много времени при поиске причин Permission denied. Вместо проверки каждого каталога вручную вы сразу видите весь путь и права доступа на каждом уровне.
🚪 Linux Ready | #практика