Bug #69136 [Com]: Session file empty when session-path on NFS mount

From: Date: Fri, 04 Mar 2016 19:45:08 +0000
Subject: Bug #69136 [Com]: Session file empty when session-path on NFS mount
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-199601@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69136&edit=1 ID: 69136 Comment by: sprunka at gmail dot com Reported by: maggus dot staab at googlemail dot com Summary: Session file empty when session-path on NFS mount Status: Assigned Type: Bug Package: Session related Operating System: Ubuntu 14 LTS PHP Version: 5.6.6 Assigned To: yohgaki Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2016-02-14 04:22:20] 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-01 14:33:53] 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-01-31 05:28:14] 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-01-31 05:03:20] 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 04:22:49] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69136 -- Edit this bug report at https://bugs.php.net/bug.php?id=69136&edit=1

« previous php.bugs (#199601) next »