php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69136 Session file empty when session-path on NFS mount
Submitted: 2015-02-27 10:56 UTC Modified: 2016-08-21 04:22 UTC
Votes:6
Avg. Score:4.3 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:2 (33.3%)
Same OS:3 (50.0%)
From: maggus dot staab at googlemail dot com Assigned: yohgaki (profile)
Status: No Feedback Package: Session related
PHP Version: 5.6.6 OS: Ubuntu 14 LTS
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: maggus dot staab at googlemail dot com
New email:
PHP Version: OS:

 

 [2015-02-27 10:56 UTC] maggus dot staab at googlemail dot com
Description:
------------
php -v
PHP 5.6.5-1+deb.sury.org~trusty+1

Test script:
---------------
<?php

$path = '/path/to/a/dir/mounted/via/nfs/';

if (!is_dir($path) || !is_writable($path) || !is_readable($path)) {
    throw new Exception("$path is not a proper dir");
}
//ini_set("session.save_path", $path); // neither this works
session_save_path($path); // nor this does
session_start();

$_SESSION['cnt'] = $_SESSION['cnt']+1;
var_dump($_SESSION['cnt']);

if ($_SESSION['cnt'] > 1) {
    echo "<h1>WORKS</h1>";
    session_destroy();
}
exit();

Expected result:
----------------
on each 2nd request "WORKS" is printed.

Actual result:
--------------
session is not persisted. session file gets created but does not contain any content. therefore subsequent calls will never echo "WORKS" because session cannot be continued.

with default Ubuntu php.ini a error/warning doesnt show up at all.

After adding 
ini_set("display_errors", "On");
error_reporting(E_ALL);

I get a warning 
"Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/XX..ZZ..YY/tmp/www/session/) in Unknown on line 0"


Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-27 10:59 UTC] maggus dot staab at googlemail dot com
1) I dont understand why the session cannot be written, since I checked is_dir, is_writable and is_readable beforehand. Even setting the dir to "0777" makes it work.

2) when basic things like writing a session doesnt work, I would expect a ERROR instead of a WARNING
 [2015-02-27 11:08 UTC] me at kelunik dot com
Same thing happens with a NTFS partition mounted with under Ubuntu 14.10
ntfs defaults,umask=0000,permissions,uid=1000 0 0.
 [2015-03-28 21:14 UTC] yohgaki@php.net
-Assigned To: +Assigned To: yohgaki
 [2015-03-28 21:14 UTC] yohgaki@php.net
Locking under shared directory is unreliable. I guess this is the reason why.

Better approach to share sessions across servers is to use databases/caches like memcached/mongodb/redis/etc.

Anyway, I may look into details...
 [2016-01-17 07:39 UTC] yohgaki@php.net
-Status: Assigned +Status: Feedback
 [2016-01-17 07:39 UTC] yohgaki@php.net
Sorry for the delay, but I couldn't reproduce this on my Fedora23 and CentOS7. "files" handler is working as it should. 

Do you have this issue still? I think you have some kind of permission issue such as you are writing session data by multiple user IDs. It wouldn't work with multiple user IDs or root ID.
 [2016-01-26 18:19 UTC] sprunka at gmail dot com
Two separate vagrant VM instances.
1)
CentOS release 6.5 (Final)
PHP 5.6.17
Session save path is shared with host machine via vagrant default sync settings (not NFS, SMB, RSync, or VirtualBox)

2)
CentOS release 6.7 (Final)
PHP 5.6.17 (Also tested with PHP 7 -- not sure which build, ame problem existed)
Session save path is shared with host machine via vagrant default sync settings (not NFS, SMB, RSync, or VirtualBox) However, I have also tried this setup using the NFS sync type and it also failed.
 [2016-01-31 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2016-01-31 05:03 UTC] yohgaki@php.net
-Status: No Feedback +Status: Re-Opened
 [2016-01-31 05:03 UTC] yohgaki@php.net
It seems this is some kind of permission issue, but
Re-Opened because reporter has this issue still.

Those who have this issue, please check session data file owner/group of processes trying to write/read session data file. i.e. sess_{session_id} in session.save_path. It MUST match and it must not be root for many setups.
 [2016-01-31 05:28 UTC] yohgaki@php.net
-Status: Re-Opened +Status: Feedback
 [2016-01-31 05:28 UTC] yohgaki@php.net
I think users who have this problem is using user ID mapping or root squashing

http://manpages.ubuntu.com/manpages/intrepid/man5/exports.5.html

Make sure you are not loosing permission due to ID mapping. Since files handler does not anything fancy for NFS/etc, if your PHP process has permission, it should not have permission issue.
 [2016-02-01 14:33 UTC] sprunka at gmail dot com
As noted, this is occurring with CentOS 6.x as well.
I am currently writing log files and other file data to the same location with the same permissions. PHP is generating the session file, but will not write to it or read from it. (I've tried manually populating the file with known good session data.)

Moving the session save dir internal to the VM has no issues whatsoever.

Identical user definitions, file and directory permissions are being used in both locations.

When the session save dir is on the host computer, PHP writes an empty session file only. When the session save dir is internal to the VM, PHP handles sessions completely normally.
 [2016-02-14 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2016-02-14 05:54 UTC] requinix@php.net
-Status: No Feedback +Status: Open
 [2016-03-04 19:45 UTC] sprunka at gmail dot com
UPDATE:

I'm using a vagrant VM. host machine is Mac OS, session storage point is being mounted via nfs, though I've also tested with "default" (whatever mount type that might be)

VM OS is CentOS 6.something

php -v
PHP 7.0.4 (cli) (built: Mar  2 2016 18:12:39) ( NTS )

using maggus's test script, customized to my paths I get the same result.

Log files can be written and read form the mounted path.
an empty (0 byte) session file is being created at the path location.
Creating a session file on a path internal to the VM works fine.
 [2016-04-25 16:00 UTC] dimiter dot ivanov at yahoo dot com
I think this is related to the changes introduced in this Bug fix #66171

https://bugs.php.net/bug.php?id=66171

I've experienced this problem in PHP 5.5.21, after updating from 5.5.6
OS is CentOS 6.7
 [2016-08-10 06:36 UTC] yohgaki@php.net
-Status: Assigned +Status: Feedback
 [2016-08-10 06:36 UTC] yohgaki@php.net
Could anyone who has this problem analyze strace?
I'm sure this is permission issue. It's not PHP issue.
 [2016-08-21 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 20:01:29 2024 UTC