I'm having trouble getting a number of scripts running because PHP-FPM can't write to my session folder:

"2009/10/01 23:54:07 [error] 17830#0: *24 FastCGI sent in stderr: "PHP Warning:
    Unknown: open(/var/lib/php/session/sess_cskfq4godj4ka2a637i5lq41o5, O_RDWR)
    failed: Permission denied (13) in Unknown on line 0
PHP Warning:  Unknown: Failed to write session data (files). Please verify
    that the current setting of session.save_path is correct
    (/var/lib/php/session) in Unknown on line 0" while reading upstream"

Obviously this is a permission issue; my session folder's owner/group is the webserver's user, NGINX. PHP-FPM runs as nobody though, and hence adding it to the nginx group is not so trivial.

A temporary solution is to set the permissions of /var/lib/php/session to 777 - I have a feeling that's not the "best practice" though.

What is the best practice when you need to assign a daemon write access to a folder, but it is running as nobody ?

9 Answers 9


The correct permissions for us where

chown -R nobody:nogroup /var/lib/php/session

as php-cgi runs as nobody, even though NGinx runs as user nginx

  • In my case it wasn't a question of ownership/permissions. Remove the "3;" from session.save_path = "3;/var/lib/php/sessions"
    – John Doe
    Mar 1, 2018 at 21:02
  • 2
    I get the following error: Invalid group <<nobody:nogroup>> :(
    – Pathros
    Jun 23, 2018 at 18:29
  • 1
    i was able to see which is my nobody user that runs php with this line of code: <?php echo exec('whoami'); ?> (in my case www-data) and after that it was simple as just wrote chown -R www-data:www-data /var/lib/php/sessions this is an underrated google result as it was the only answer that it helped me after hours of searching! thanks!
    – Dimitar
    Aug 22, 2018 at 6:13

If you use nginx you might run into this when running a system update.

Sometimes when you update the system, the group of /var/lib/php/session is changed to apache.

Try executing sudo chgrp nginx /var/lib/php/* instead of setting permissions to 777 which is a bad practice.

That worked for me at least.


Use /etc/php.ini session.save_path directive.

A temporary solution is to set the permissions of /var/lib/php/session to 777 - I have a feeling that's not the "best practice" though.

"If you leave this set to a world-readable directory, other users on the server may be able to hijack sessions by getting the list of files in that directory. "

  • Sorry I think I may not have been clear: session.save_path is already set to /var/lib/php/session . The problem is I can't figure out what permissions and ownership to assign to the session path directory in order to both enable PHP-FPM to write to it, as well as keep it safe. Having the directory set as owner/group "nginx"(The web server I'm running) and permissions 755 doesn't seem to do the trick Oct 2, 2009 at 12:17
  • 4
    1. Use same user:group for nginx and php-fpm (via either nginx.conf or php-fpm.conf), so you can keep this directory 700. 2. Use chown -R nginx:nobody /var/lib/php/session && chmod -R 770 /var/lib/php/session so i think both nginx and php-fpm can use it Oct 2, 2009 at 14:32
  • 2
    I can confirm that using nginx:nobody (or nginx:nogroup in some circumstances) works. If it is possible, I'd lean towards SaveTheRbtz' option 1, though. Oct 22, 2009 at 3:24

I had to create folder with 0700 rights in /var/lib/php/session for each php-fpm pool.

Owner of this folder is user and group from php-fpm pool.

And /var/lib/php/session now 0777.

I think this method is most secure. Only php-fpm pool user will see this sessions.


The correct way should be changing the ownership of the session folder to nginx. However, PHP-FPM does not run using the nginx user by default. It uses apache by default.

With that said, you must change the user that's used by PHP-FPM by editing /etc/php-fpm.d/www.conf.

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

Restart PHP-FPM and you should be good to go.

service php-fpm restart

PHP session path location can be found in /etc/php.ini under session.save_path. /var/lib/php/session is the default.

Command to update ownership and group of php session folder

chown -R nginx:nginx /var/lib/php/session

And you should be good to go even with chmod of 700.


Directory /var/lib/php/sessions should have sticky bit permissions.

sudo chmod 1773 /var/lib/php/sessions

ls -al /var/lib/php/
drwxr-xr-x  4 root root   .
drwxr-xr-x 51 root root   ..
drwxr-xr-x  3 root root   modules
drwx-wx-wt  2 root root   sessions

I had the same problem and I solved it. I went to /tmp (that's where my ses_* files are) and deleted them all. After that everything was OK.

As nears as I could tell the system was trying to write on old locked files.

The problem occured after I was playing with php.ini. I lost a couple years from my life but eventually I found the solution.


Based on @Judder answer, to make it work i had to add the following command to give read and write permissions to nobody and nogroup:

chown -R nobody:nogroup /var/lib/php/session

sudo chmod -R ug+rw /var/lib/php/sessions

chmod will change the permissions on the given folder
-R will apply the same permissions to the folders and files created within the given folder
u for user
g for group
r for read permission
w for write permission


I'm running Apache and Nginx Reverse Proxy Server and I experienced this same issue. This is what I did to resolve the errors.

chown -R apache:nobody /var/lib/php/*
chmod g+w /var/lib/php/session

Hope this helps someone with the same problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .