I recently upgraded my Macbook's OS to El Capitan. I set up XAMPP just like i did on my old OS. I am trying to create a Database using phpMyAdmin But all i am getting is this error:
Warning in ./libraries/session.inc.php#101
session_start():
open(/var/folders/w3/w7pdy78x5r57wmgcytwvh16r0000gn/T/sess_t4t8i795i8d67a52b785rr0j86isrn8c,
O_RDWR) failed: Permission denied (13)
Backtrace
./libraries/session.inc.php#101: session_start()
./libraries/common.inc.php#350: require(./libraries/session.inc.php)
./server_databases.php#12: require_once(./libraries/common.inc.php)
I thought it was a permissions issue so i changed all the XAMPP folders to read and write for all but still getting the same error. I have never been faced with this error before and my phpMyAdmin worked fine on my old OS. I have seen similar questions posted on here but none of the answers for them are working for me. Dose anyone know what it could be? Is this a problem within XAMPP/Apache or is this coming from the browser maybe? Im so lost with it and all out of ideas!
UPDATE
I don't know if this helps but i just checked my PHP info settings for session.save_path and it says "NO VALUE" is that suppose to be like that?
I had this problem even with correct folder permissions.
I solved it deleting the session files that were in the folder
After spending all night trying to figure out the problem i finally found the solution. I copied the location of the TMPDIR.
Then used this in the Terminal:
sudo chmod 777 /paste/TMPDIR/location/here/...
And then restart XAMPP and should be all good from there. I hope this helps :)
go to your phpinfo() then find your "session.save_path" value
use your terminal locate to that path then try type "ls" to list file
delete all file named start with sess_* (in my case I deleted "rm sess_c4ac83103bb5d8a77352a7cc4c9036eb") and then try refresh phpmyadmin again.
it's works for me., hope it helps.
I had same issue in my MAC OX and XAMPP.
To solve issue try to remove session files from location reported in error message. MAC users: /Application/XAMPP/xampfiles/temp/(whatever the session id is - it will be in error message and you will find file with the same name)
Additionally open terminal in the location of /temp folder and change access:
chmod -R o+w
In case you added vhost it might be in conflict with settings (user daemon, group daemon in htdocs.conf in case you changed user as an vhost change in your XAMPP recommended for MAC users to avoid 403 access denied issue for MAC OX users using XAMPP).
in case you have relocated folders in XAMPP/htdocs/ your session will contain same id but will have wrong location and needs to be removed manually as location of your project was while session was active. Go in folder reported in error message and delete session files.
This worked for me, hopefully will save you some time.
This one is quit puzzling to me. Please help
I baked a cake using root via ssh and everything went well except for the fact that i could not edit the view CTP files in dreamweaver. kept getting "access denied. Permission problem".
Via ssh and the cpanel i was able to change the permission to 755, 777. Got an error when attempted to change permission via dreamweaver
After changing file permission, I still got the error "access denied. permission problem.."
I then change the USER who owns the file using chown via ssh
I was then able to edit the file without error. I viewed the edited file via cpanel and realized that the changes took place. Bravo!
However, when i viewed the page in the browser, no changes were apparent.
I cleared the cache several times. My tmp folder is chmod 777
What am i missing?
Are you using Scaffolding perhaps? If so, disable it to see what happens.
Double check if these file names are correct too: Controller, View files and View folder.
I am building a Fedora server (on VirtualBox right now). It is running Fedora 15.
I want my PHP script to be able to edit the contents of a file in the same folder it is in.
The PHP script and the file are in /home/user/public_html/
But, when I call "file_put_contents("./theFile.txt")" I get an error saying that it cannot open the stream, permission denied.
So, I have:
- Made the file permissions 0777.
- Made the folder permissions 0777.
- Added the "apache" user to the group "wheel".
- Changed the user folder permissions to 0771.
- Changed the owner of the public_html folder and the text file to "apache:apache".
I am at my wits end and I have idea what to do next. Suggestions?
SELinux is preventing you from writing out the file. See the httpd_selinux(8) man page for ways to work with/around it.
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.
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
you will need to change your session.save_path php.ini directive
You can do that using session_save_path
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;
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.
I had this problem in the following situation:
I filled some session vars with PHP
While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
Reloading the page gave the error, described above.
Reset the PHP version to 5.4 again.
Used session_unset(); and session_destroy(); to clean the current session.
Changed the PHP version back to 5.3.
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.
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!
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.
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.
Add following line
ini_set('session.save_path', getcwd() . '/tmp');
before
session_start();
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.
I had the same problem of permission, but on /var/lib/php/session/.
To fix it, I deleted the file and restarted php-fpm.
rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart
Now all works well.
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();
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.
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 :
Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
Have each different user save their session files in separate place(s) (session_save_path() etc).
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.
In my case the problem was SELINUX not allowing this.
A helpful command to get suggestions on how to fix this:
sealert -a /var/log/audit/audit.log
If you want to rule out SELINUX, try disabling it for a moment. If that fixes the issue then that is the problem.
I recently moved my website to a new host and now am experiencing some broken code..
I have an uploading script that is now returning this:
move_uploaded_file() failed to open
stream: Permission denied in *..
I've set the upload directory to 777 which worked fine, but my script is needed to have top level permissions..
(As the script itself sets permission to directories, does lots of copying etc)
Is there a way in apache I can set the PHP script to the owner of all the folders on my server?
Thanks
Also
When looking in phpInfo()
Under
apache2handler
User/Group nobody(99)/99
Is this related?
I wouldn't go that route, just give it permissions to the defined upload_tmp_dir, or define upload_tmp_dir to be a directory you have access to. If it is that directory you have problems with. If the target is the problem, and you've 777'ed it, something fishy is going on.
Do you have ssh access to your new host? The reason I ask is that it's probably not best to use the username/group as nobody, as most other services would use this too. I would change it to something like apache
You can then update httpd.conf, adding in these two lines (reloading the config after):
User apache
Group apache
Then, run chown apache:apache -R dir_name to make apache own it.
well,
When you are trying to set the permission like "0777", you must be running on same authority.
What I mean is.
For example, your script tells to change a folder/file permission to 0777, but the folder or file already has a permission and that is '0755' so you are not authorised to make that change. as the user have only 5 authority.
Either, you need to login to FTP and change the folder permission to 0777 and then you have full control over it or you have to stick with using 0755 or similar.