PHP on Windows - ps_files_cleanup_dir error

Question

I am occasionally getting the following error when loading a PHP page:

PHP Notice:  session_start(): ps_files_cleanup_dir: opendir(C:\Windows\TEMP) failed: No error (0) in C:\server\default.php on line 299

Month-old sess_ files in C:\Windows\TEMP still exist.

I am running PHP 5.6.5 on IIS on Windows 8.1.

Why is PHP unable to perform garbage collection, and how do I fix it?

Solution

Session temporary files are created in this directory as per the ‘session.save_path’ property in php.ini. Without the permissions to delete files in this directory PHP is unable to remove these files as part of its normal session garbage handling process and so they accumulate when they are no longer needed/you will occasionally see this error whenever garbage collection is performed.

The Application Pool user, which is the one that actually runs the PHP executable, needs at least modify permissions on C:\Windows\TEMP to perform garbage collection (this is not granted by default). If you have not changed this user from the default then it should be 'DefaultAppPool', or you can use the App Pool group, which will be similar to IUSRS.

Best practice is to create a new Application Pool for each site. When you do this IIS will create a Windows user which you can then grant modify permissions to. You can script this or do it from the command line using the following command:

icacls c:\windows\TEMP\ /inheritance:e /grant "IIS APPPOOL\your-user:(OI)(CI)M" /t /c /Q

Update: As Gremio notes, you should move the session files to a specific directory, so that you are not granting write access for this user (that may be exploited) to whatever else Windows stores in the TEMP directory. You can modify the sessions save settings in the php.ini, globally, or specifically for your application at run time (details here).

Comments

[Mooseman]

@kmindi It's been able to write the sess_ files.

[Gremio]

I would not grant Modify for C:\Windows\Temp to an account used by a web server (including IIS, phpcgi, Python, Etc.). There's just no telling what could end up there. You could instead change the path for sessions to something else where you can grant the account M. Or you could just give the account 'list folder' as users have everything they need by default (which these accounts are unspoken members of) except list folder. Granted, if a hacker can exploit the code and access that location, they're potentially taking over sessions no matter what you do.