How can I fix the Permission error when I call session_start()?

Question

when I uploaded the script to the server I got this error

Warning: Unknown: open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0

the error appeared when I call session_start(); although I set the permission of /tmp folder to 777 .

Answer 1

Change session path where you can write data or contact server administrator about /tmp problem

http://php.net/manual/en/function.session-save-path.php

Answer 2

you will need to change your session.save_path php.ini directive

You can do that using session_save_path

Answer 3

If you have SSH access, here is how to correct the permission and ownership

sudo chown -R NAME_OF_USER /tmp

Replace NAME_OF_USER by the user under which runs php. You can find it by simply putting these lines in a php file:

$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;

Answer 4

Check that you're not running into diskspace issues. If all the permissions are correct (and 777 ought to do it for you), then you might still get this error (for some versions of PHP and Apache) if there isn't enough space to write to the disk.

Answer 5

Additionally, you may want to use ini_set('session.save_path', '/dir/here'); assuming you have access to this function. The other ways suggested are valid.

Answer 6

I've just had exactly the same problem with one of my PHP scripts and I was like what did I break 'cos it worked perfectly the day before and I'm running it from my own local Puppy Linux machine so it's not even a host or anything.

The only thing I'd been doing before that was trying to get Java to work in the web browser, so some how I'd managed to get Java to work but broke PHP - oops!

Anyway I did remember that whilst trying to get Java to work I had deleted the contents of the /tmp folder to wipe anything out that may be causing a problem (it actually turned out with Java I was using the old plugin oij with the new Firefox)

To solve this problem I opened up Rox File Manager, went to the / folder and right clicked on the tmp folder -> Mount Point 'tmp' and clicked properties.

I noticed the permissions were set as Owner - Read, Write, Exec, but Group and World were only set at Read and Exec and not Write. I put a tick in Write for both Group and World and now PHP works fine again.

I don't know at what point the permissions for tmp must have changed but for PHP to use them it must be set to have Write permissions.

Answer 7

I had this problem in the following situation:

1. I filled some session vars with PHP
2. While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
3. Reloading the page gave the error, described above.
4. Reset the PHP version to 5.4 again.
5. Used session_unset(); and session_destroy(); to clean the current session.
6. Changed the PHP version back to 5.3.
7. Now it works again.

Conclusion: For an irrelevant reason I had to change my PHP version, and while switching with sessions alive, the sessions get corrupted.

Answer 8

Add following line

ini_set('session.save_path', getcwd() . '/tmp');

before

session_start(); 

Answer 9

I realize that this is an old post, however I just ran into this problem, and found an easy solution.

For me, the issue was happening with one of my websites deployed locally. I hadn't tried accessing the websites using other browsers, but it was happening every time I tried to access this site via Chrome. I decided to go into the Chrome developer tools, under the application tab -- and clicking "Clear Storage". Voila -- everything is working like magic again.

Hope this helps someone else!

Answer 10

I have the same problem of permission, but on /var/lib/php/session/.

To fix it, I delete the file and restart php-fpm.

rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart

Now all works well.

Answer 11

If :

• session.gc_probability > 0
• session files are created by different user(s) (e.g. root and apache).
• session files are all stored in the same place (e.g. /var/lib/php/session)

Then you'll see this error when e.g. the Apache PHP process attempts to run garbage collection on the session files.

Fixes :

1. Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
2. Have each different user save their session files in separate place(s) (session_save_path() etc).

Answer 12

if you are using Apache web server, the quick fix is to go to your command line and type:

open /etc/apache2/

then from the window opened, open the file called httpd.conf and search for User or Group change these 2 lines to:

User  _www
Group _www

This is because you want your server to have permission to your systems directories, especially you want to change the User or you can leave your Group to either staff or admin.

Answer 13

For me the problem seems to be a WHM bug! I have a bunch of add on domains and all work fine but with a subdomain it brings this error.

Strange thing but if I use the full URL with the main domain it works fine:

main-domain.com/my.subdomain.com

If I use the subdomain directly it brings "Permission denied (13)":

my.subdomain.com

The thing is all addon domains root is:

/home/xx/

But for my subdomain, don't know why, the root is: (I shouldn't have access to that dir)

/

So it´s really trying to reach: /tmp instead of /home/xx/tmp

Which also exists but don't have the right permissions

To clarify this are examples of the whole path:

/home/my-account/public_html

/home/my-account/tmp

/tmp

The workaround I used was:

session_save_path('/home/my-account/tmp');

session_start();

Answer 14

I initially had this issue due to nginx owning the /tmp location and php-fpm was running under 'apache' user and group due to the www.conf. I swapped out the user/group in that file and then it worked ok. You may want to check <?php echo exec('whoami'); ?> to verify.

Answer 15

Using PHP 5.6 I had already used session_save_path() to point to a directory within the domain's structure. It worked fine until I upgraded to PHP 7.0, at which time I received the noted error. At PHP.net I found several comments that indicated assigning a direct path didn't always work, so I used their suggestion.

session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));

worked perfectly. Remember to change /../session to the relative location of your actual session directory.