Fix PHP Warning: session_start() with MAMP on macOS 11 Big Sur

While continuing to work on one of my PHP projects after installing the macOS 11 Big Sur Beta, I got some weird behaviour when trying to initiate a user session – while not having had any changes in a previously working code:

PHP Warning: session_start(): open(/Applications/MAMP/tmp/php/sess_qgnf2q45ccfveb55ocppep1o86, O_RDWR) failed: No such file or directory (2) in /webproject/script.php on line 1

Problem analysis

The requested directory was simply not present: /Applications/MAMP/tmp/php was truly missing.

Turns out I broke this thing myself, because I deleted the MAMP /tmp/php-folder recently while trying to resolve an issue with an unexpected «mysql.pid ended» error.

Based on this error message from MAMP’s php_error.log I remembered that macOS Big Sur has tightened up on the OS security, in particular by limiting applications’ access to files and folders when not having granted permissions to do so explicitly.

Resolving the PHP Warning session_start() failed

Give PHP what PHP wants

Recreate the /MAMP/tmp/php-folder, either using Finder or e.g. by using the following Terminal command:

mkdir /Applications/MAMP/tmp/php

Alternative approach: use a custom session_save_path()

Good thing, you can control which directory a PHP project is using for storing the temporary session file(s) of a user. Either globally in the php.ini – or per script/project using the session_save_path() directive.

Thus fixing the PHP session handling to be working again with MAMP under macOS Big Sur was pretty easy can also be achieved as follows:

• by defining a session_save_path() within the PHP project’s $_Server['DOCUMENT_ROOT'] got things back to “normal”
• make sure the custom session_save_path() is set before session_start()

/** Use a custom PHP Session Save path in your project */
session_save_path(__DIR__.'/tmp/sessions');
ini_set('session.gc_probability', 1);
session_start();

(using ini_set('session.gc_probability', 1) is optional – it controls the deletion of old and expired PHP sessions within a custom session storage, because usually this is done through a cron job , as stated and explained here)