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

Fixing session_start(): Permission Denied (13) in XAMPP — SELinux/AppArmor Restrictions

3 min read
09.03.2025

Check SELinux Status

SELinux (Security-Enhanced Linux) enforces security policies that can restrict access to session files.

XAMPP SELinux AppArmor Sessions
XAMPP + SELinux/AppArmor — relabel or temporarily complain-mode.

For closely related XAMPP and session_start topics, see XAMPP session_start — sysadmin guide variant, session_start() failed: Permission denied (13), and Verify PHP Configuration (php.ini).

Run:

sestatus

If it returns:

SELinux status: enabled
SELinux mode: enforcing

SELinux is blocking access to /opt/lampp/temp/.

Allow Apache/PHP to Access the Session Directory

Since PHP sessions are stored in /opt/lampp/temp/, grant the necessary SELinux permissions.

Check SELinux Logs for Denied Requests

Run:

sudo journalctl -xe | grep AVC

or:

sudo grep "denied" /var/log/audit/audit.log

Look for entries related to /opt/lampp/temp/.

Grant Access to the Session Directory

Run the following command:

sudo chcon -R -t httpd_sys_rw_content_t /opt/lampp/temp/

This assigns the correct SELinux context to allow Apache (httpd) to read and write session files.

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

Check and Modify AppArmor (Ubuntu/Debian)

If you're running Ubuntu or Debian, AppArmor may be blocking PHP.

Check AppArmor Profiles

Run:

sudo aa-status

If AppArmor is enforcing restrictions on /opt/lampp/temp/, switch it to complain mode:

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

Restart Apache & PHP

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

Test again to see if the session issue is resolved.

Disable SELinux Temporarily (For Testing)

If SELinux still blocks access, temporarily disable it to confirm.

Run:

sudo setenforce 0

Then restart XAMPP:

sudo /opt/lampp/lampp restart

If sessions now work, then SELinux is the problem, and you should configure SELinux properly instead of disabling it permanently.

Check & Fix File Permissions

If SELinux/AppArmor is not the issue, fix the session folder permissions.

sudo chmod -R 770 /opt/lampp/temp/
sudo chown -R daemon:daemon /opt/lampp/temp/

For Apache on Linux:

sudo chown -R www-data:www-data /opt/lampp/temp/

Restart services and test again.

Debugging Further Issues

If the error persists, check logs:

  • Check Apache Logs:
    sudo tail -f /opt/lampp/logs/error_log
  • Check PHP Logs:
    sudo tail -f /opt/lampp/logs/php_error_log
  • Check System Logs for Security Blocks:
    sudo dmesg | grep php

Summary of Fixes

Issue Fix
SELinux blocking session directory chcon -R -t httpd_sys_rw_content_t /opt/lampp/temp/
AppArmor restricting access aa-complain /usr/sbin/apache2
Wrong folder permissions chmod -R 770 /opt/lampp/temp/
Incorrect ownership chown -R daemon:daemon /opt/lampp/temp/
Still not working? setenforce 0 (temporary SELinux disable)

By following these server-level fixes, you can resolve SELinux/AppArmor restrictions and restore PHP session functionality in XAMPP.

Frequently asked questions
`tail -f /var/log/audit/audit.log` while reproducing. Lines with `type=AVC` and `denied` are SELinux blocks. `audit2why < /var/log/audit/audit.log` translates to human-readable. If you see XAMPP's httpd trying to write to /opt/lampp/tmp and getting denied, SELinux context is wrong.
`chcon` is temporary — survives until `restorecon` resets. `semanage fcontext -a -t httpd_sys_rw_content_t '/opt/lampp/tmp(/.*)?'` + `restorecon -R /opt/lampp/tmp` is permanent. For dev XAMPP, chcon is fine; for any production XAMPP (rare), semanage so policy survives restorecon and reboots.
`sudo dmesg | grep DENIED` shows recent AppArmor blocks. The profile name is in the message. For Apache via XAMPP, it's not usually under default profile (XAMPP installs its own bin), but on Ubuntu derivatives shipping AppArmor-enforced httpd, the system httpd profile may block. Either complain-mode that profile or run XAMPP's bin path.
On dev VM: fine. On production server (where XAMPP shouldn't be running anyway): bad — removes a security layer. The right fix is per-path labels, not blanket disable. Disabling teaches you nothing about configuration; per-path labels make subsequent deployments correct.
Related articles
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
Fixing session_start(): No Such File or Directory Error in PHP