Fixing session_start() failed: Permission denied (13) – A System Administrator’s Guide

Contents: Common Causes Check PHP Session Directory Fix Directory Permissions Check SELinux/AppArmor Restrictions Check Disk Space & Inodes Verify PHP Configuration (php.ini) Clear Existing Session Files Debugging with Error Logs Summary of Fixes

This error occurs when PHP cannot start a session due to permission issues, misconfiguration, or web server restrictions.

Common Causes:

1. Incorrect permissions on /var/lib/php/sessions/.
2. Wrong ownership (Apache/Nginx cannot write session files).
3. SELinux/AppArmor blocking access to session files.
4. Full disk space or inodes preventing file creation.
5. Incorrect php.ini settings for session storage.
6. Corrupt session files or missing session directory.

Check PHP Session Directory

First, verify where PHP is trying to store session files.

Find the Session Save Path

Run:

php -i | grep "session.save_path"

Expected output:

session.save_path => /var/lib/php/sessions

If the directory is missing or incorrect, note the path and proceed.

Fix Directory Permissions

If PHP cannot write to the session directory, adjust permissions.

Ensure Correct Permissions

sudo chmod -R 770 /var/lib/php/sessions

Ensure Correct Ownership

For Apache:

sudo chown -R www-data:www-data /var/lib/php/sessions

For Nginx:

sudo chown -R nginx:nginx /var/lib/php/sessions

Restart Web Server

For Apache:

sudo systemctl restart apache2

For Nginx:

sudo systemctl restart nginx php8.0-fpm

Test if the session issue is resolved.

Check SELinux/AppArmor Restrictions

If SELinux is enabled, it may prevent PHP from writing session files.

Check SELinux Status

sestatus

If enabled, allow PHP to write session files:

sudo chcon -R -t httpd_sys_rw_content_t /var/lib/php/sessions

Alternatively, disable SELinux temporarily:

sudo setenforce 0

Check AppArmor (Debian/Ubuntu)

If using AppArmor, allow PHP-FPM access:

sudo aa-complain /usr/sbin/php-fpm

Try restarting the server and check if the issue is fixed.

Check Disk Space & Inodes

If the disk is full, PHP cannot create session files.

Check Disk Space

df -h

If /var or /tmp is 100% full, delete unnecessary files:

sudo rm -rf /var/lib/php/sessions/*

Check Inodes

df -i

If inodes are full, clear old files:

sudo rm -rf /tmp/*

Try running the session script again.

Verify PHP Configuration (php.ini)

If sessions are misconfigured in php.ini, update the settings.

Locate php.ini

Find the active PHP configuration:

php --ini | grep "Loaded Configuration File"

Edit the file:

sudo nano /etc/php/8.0/apache2/php.ini

or (for PHP-FPM)

sudo nano /etc/php/8.0/fpm/php.ini

Update Session Settings

Find and update:

session.save_handler = files
session.save_path = "/var/lib/php/sessions"
session.gc_maxlifetime = 3600
session.cookie_secure = 0
session.use_strict_mode = 1

Restart PHP & Web Server

sudo systemctl restart php8.0-fpm
sudo systemctl restart apache2

Test if the session issue is resolved.

Clear Existing Session Files

Corrupt session files can cause issues.

Clear Old Session Files

sudo rm -rf /var/lib/php/sessions/*

Create a Test Session Script

<?php
session_start();
$_SESSION['test'] = 'Session Working!';
echo "Session started successfully.";
?>

Save this as session_test.php and run it in your browser.

If no errors appear, the issue is fixed.

Debugging with Error Logs

If the problem persists, check logs.

Check Apache Logs

sudo tail -f /var/log/apache2/error.log

Check Nginx Logs

sudo tail -f /var/log/nginx/error.log

Summary of Fixes

By following these systematic fixes, a server administrator can resolve session_start() permission issues and restore PHP session functionality.