#Что означает ошибка
Warning: session_start(): open(/var/lib/php/sessions/sess_xxx) failed: Permission denied
Предупреждение «session_start(): open(/var/lib/php/sessions/sess_xxx) failed: Permission denied» означает, что PHP не может создать или прочитать файл сессии. Процесс PHP работает от определённого пользователя (www-data, apache, nginx или отдельного пользователя пула PHP-FPM), и у него нет прав на каталог, указанный в session.save_path. Типичный повод — смена пользователя пула, перенос сайта или изменение прав при обновлении.
#Причины и решения
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Нет прав на каталог сессийВладелец каталога другой. | ls -ld показывает чужого владельца. | Выдайте права. |
| Неверный session.save_pathПуть не существует. | Каталог отсутствует. | Создайте или исправьте. |
| Нет места на дискеДиск или inode заполнены. | df -h, df -i показывают 100%. | Освободите. |
| Смена пользователя PHP-FPMПул работает от другого пользователя. | После изменения пула. | Приведите права в соответствие. |
#Пошаговое решение
- Найдите путьЭто действия администратора сайта. Откройте журнал ошибки PHP для конкретного сайта и пула в панели хостинга/на сервере и найдите полный путь после
session_start(): open(...) failed: Permission denied. Путь сессий может отличаться от/var/lib/php/sessions. Создайте временную закрытую диагностическую страницу и посмотритеini_get('session.save_path'),php_sapi_name()и версию PHP через веб-запрос; сразу удалите страницу.php -iв SSH показывает настройки CLI и может указывать другой каталог, поэтому не используйте его как единственный источник. - Определите пользователя PHPОпределите пользователя и группу того процесса, который обслуживает сайт: для PHP-FPM откройте конфигурацию соответствующего пула и найдите параметры
userиgroupлибо проверьте сведения об обработчике в панели управления. На Linux можно диагностически выполнитьps -eo user,group,pid,cmd | grep '[p]hp-fpm'; корневой управляющий процесс не равен рабочим дочерним процессам. При нескольких версиях PHP найдите нужный пул, а не типовой пример/etc/php/8.2/fpm/pool.d/www.confиз другой установки. - Проверьте праваВ SSH-терминале выполните
ls -ld /ФАКТИЧЕСКИЙ/КАТАЛОГиnamei -l /ФАКТИЧЕСКИЙ/КАТАЛОГ, подставив подтверждённый путь. Проверьте владельца и разрешение на проход (x) каждой родительской папки, а также запись (w) в каталоге сессий для нужного пользователя. Если директории нет, выясните, каким способом она должна создаваться. Не меняйте владельца всего системного каталога и не применяйтеchmod 777: другие сайты могут получить доступ к чужим файлам сессий. - Выдайте праваТолько после выяснения пользователя пула и требований PHP создайте отдельный каталог сессий для этого сайта, например внутри выделенного служебного каталога вне публичного web-каталога; установите владельца процесса PHP и права без доступа посторонним. Команды
mkdir,chownиchmodприменяйте только к новому точно проверенному пути, с согласованием администратора. Не выполняйтеchown -R www-data:www-data /var/lib/php/sessions: на Fastpanel и многосайтовых серверах пул может работать от другого пользователя, а общий каталог обслуживает и другие сайты. - Проверьте местоВ терминале Linux выполните
df -h /ПУТЬ_К_КАТАЛОГУиdf -i /ПУТЬ_К_КАТАЛОГУ— проверьте место и доступные индексные дескрипторы раздела. При заполнении не удаляйте все файлы сессий: пользователи потеряют сеансы, могут быть затронуты чужие сайты. Найдите источник заполнения по журналам и согласуйте штатную очистку устаревших сессий для нужного приложения. После устранения нехватки места повторите вход пользователя. - Используйте отдельный каталогЕсли требуется собственный путь PHP-FPM, откройте настройки конкретного пула и задайте
php_admin_value[session.save_path] = /точный/каталог/сайтатолько после создания каталога и проверки прав; на управляемом хостинге используйте штатный интерфейс панели, чтобы изменения не затёрлись при пересоздании конфигурации. Проверьте, какой PHP обработчик действительно активен, и убедитесь, что путь находится вне папки, доступной по HTTP. Перед изменением запишите исходную настройку для отката. - Проверьте SELinuxЕсли обычные права верны, а доступ отклоняется, на Linux проверьте ограничения SELinux (
getenforce, журнал аудита AVC) или AppArmor (aa-status, системный журнал), если механизмы применяются. Отсутствие записи AVC не доказывает отсутствие других ограничений. Исправление политики должен делать администратор после определения нужного пути; не используйтеsetenforce 0и не отключайте AppArmor ради проверки без разрешённой процедуры. На Windows-хостинге вместо этого проверьте ACL учётной записи процесса. - Перезапустите PHP-FPMПосле изменения конфигурации проверьте её корректность средствами вашей версии PHP-FPM и выполните перезагрузку конфигурации нужной службы, согласовав влияние на сайт. Например, в некоторых системах используется
systemctl reload php8.2-fpm, но на Fastpanel имя может отличаться. Затем откройте приложение в приватном окне браузера, войдите, обновите страницу и проверьте, что сеанс сохраняется, а в журнале больше нет Permission denied. Если ошибка повторяется, верните исходную настройку и уточните путь сессий и владельца процесса. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
Для хостингов с несколькими сайтами используйте отдельные каталоги сессий для каждого пула — так сайты не смогут читать сессии друг друга. Права 1733 (с sticky-битом) используются для общего каталога сессий Debian/Ubuntu, где session.save_path принадлежит root, а очистку выполняет системное задание. Если сессии хранятся в Redis или Memcached, проверьте доступность сервера и параметры session.save_handler. После исправления прав проверьте, что вход пользователей снова работает и журнал ошибок PHP (/var/log/php8.2-fpm.log, /var/log/nginx/error.log) не содержит новых записей. Справка — .