Era Host hosting
EraHost – Free Domain, Cheap Hosting!
Client Area
Support 24/7
Menu

Fixing session_start() failed: Permission denied (13) — A System Administrator's Guide

4 min read
04.04.2026
Fix session_start Permission Denied (13) PHP Error
Permission denied (13) — PHP can't write to session.save_path.

For other PHP-session and file-permission errors, see Fixing "No Space Left on Device (28)" & Session Write Errors in PHP and Fix proc_open() Has Been Disabled for Security Reasons.

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.

Linux VDS
High performance for your projects
  • Root access and flexible setup
  • Control panel
  • NVMe disks
  • DDR5
Linux VDS

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

Issue Fix
Incorrect folder permissions chmod -R 770 /var/lib/php/sessions
Wrong ownership chown -R www-data:www-data /var/lib/php/sessions
SELinux/AppArmor blocking access chcon -R -t httpd_sys_rw_content_t /var/lib/php/sessions
Full disk space or inodes df -h, df -i, then clear space
Misconfigured php.ini Update session.save_path
Corrupt session files rm -rf /var/lib/php/sessions/*

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

Frequently asked questions
`getenforce` — if `Enforcing`, SELinux is on. Try `setenforce 0` temporarily; if sessions then work, SELinux is the cause. Don't leave it disabled — restore enforcing and apply the proper context: `chcon -R -t httpd_sys_rw_content_t /var/lib/php/sessions`. RedHat/CentOS hosts: it's almost always SELinux until proven otherwise.
Different php.ini files. PHP-FPM reads `/etc/php//fpm/php.ini`; Apache mod_php reads `/etc/php//apache2/php.ini`. Each can have a different session.save_path. Find the active path by running `php -i | grep session.save_path` under the correct SAPI — `php-fpm -i` for FPM, web phpinfo() for whatever serves the request.
Per-vhost session.save_path override in `.user.ini`, `php-fpm.d/.conf`, or vhost. PHP-FPM pools can have `php_value[session.save_path]` set per-pool — wins over global. Also check open_basedir: if it doesn't include the session path, PHP can't write even with right permissions. Grep all PHP/Apache configs for the session directory.
No. Other users on the server can read every active session — a session-hijack vulnerability. The right answer is 770 with the correct owner (`www-data:www-data` or whatever your PHP runs as). If you have multiple users sharing one session dir, give them a shared group and 770.
Related articles
Fixing phpMyAdmin "Error During Session Start" — Complete Guide
Fixing session_start(): Permission Denied (13) in XAMPP — System Administrator's Guide
Fixing session_start(): Permission Denied (13) — Failed to Read Session Data in PHP