I have my site hosted on GoDaddy and on that site I have a part for uploads, it worked fine until days ago, now it started to return error 6 - Missing a temporary folder for any file I try to upload, I tried several ways to solve it, changing the php.ini and still nothing.
In my PHP file if I use the command file_exists(sys_get_temp_dir()); returns me true, so the folder is there.
If I use the is_writable(sys_get_temp_dir()); command returns me false, maybe there is the problem, but the folder /tmp on my server has permission drwxrwxrwt.
If anyone can help me with this problem, since I followed several tutorials and nothing about the solution.
Some providers do NOT grant access to the initialization file for PHP, but rather customers must use a local php.ini file with only the entries needed and allowed to set in a customer account.
In the server's Site Administration menu -> Server -> PHP Info what does the output show for upload_tmp_dir?
More than likely on a shared host, one cannot access edit the main php.ini, but one can set some things via their own local (in their account) php.ini file with the right 'snippets'.
Good luck, hope this helps.
Well, the problem has been solved and it is more strange than I imagined, I will leave the answer here to help you if someone has the same problem.
It was necessary to execute the command chmod 777 / tmp, but this command could not be executed since it gave an error that the folder was read-only (Ready-Only file system). To resolve this, it was necessary to mount and remount it, but I couldn't do it either, as it wouldn't let me remount the /tmp folder
For another reason I had to restart the server and magically the server let me change the permissions to 777 (from drwxrwxrwt. to drwxrwxrwx.). With that problem solved.
I thank everyone who tried to help.
I'm installing WordPress through Xampp. I used to work with MAMP and it basically works the same way.
Normally I do everything manually as in copying the files and installing the database.
When loaded the famous "can't establish database connection" kicks in.
Now I thought this might have something to do with the fact that MAMP and Xampp have some minor differences. So I decided to use the WordPress installer.
After placing the files in XAMPP->xamppfiles->htdocs->customFolder I ran the installer.
Database is created in phpMyAdmin and I expect the installer to finish after adding the credentials. But nooooo. For some reason this sob keeps denying the wp-config.php to be created.
I quadruple checked every credential of the database. Have no idea on why step2 fails to install WordPress.
So I might think this is an port issue. I have also installed MAMP and it is running on port:8080. After setting xampp to port:8080 it gives me an error saying it can't bind to that port. Changed it to port:8666 but the same problem occurs.
Any thoughts or extra info?
---- UPDATE ---
So I created the wp-config.php manually and got these extra error messages.
All files in the htaccess folder have now file permission 777. This is merely for testing and would never happen in a live environment.
Warning: mysqli_real_connect(): (HY000/1045): Access denied for user 'root'#'localhost' (using password: YES) in /Applications/XAMPP/xamppfiles/htdocs/testing/wp-includes/wp-db.php on line 1531
There must be file permission issue, You must grand 777 rites to create wp-config file. chmod 775 wp-content/upload
Also note
All files should be owned by the actual user's account, not the user account used for the httpd process.
Group owneraship is irrelevant, unless there's specific group requirements for the web-server process permissions checking. This is not usually the case.
All directories should be 755 or 750.
All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it.
No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory.
It sounds like a folder/file permissions issue rather than a port issue.
This question should help you solve the permissions on your xampp/xamppfiles/htdocs/customfolder
XAMPP permissions on Mac OS X?
When WordPress gives that error it's most often because it can't create the wp-config.php file due to insufficient write permissions.
I found the solution.
MAMP uses a user root and password root.
XAMPP in contrast to MAMP doesn't.
The user name is root but the password is empty.....
I faced this issue attempting to install within XAMPP and what solved it for me was to run XAMPP as administrator. This reflects other answers referring to permissions.
The other thing that can be an issue is XAMPP timing out on the install. One can modify their php.ini file within xampp to increase the max execution time. As they say "I hope this helps"
;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 90
I had same issue using XAMPP 8.1.12 on WINDOWS 10;
Try installing an older version, in my case XAMPP 8.0.25 fixed the problem.
I see that similar questions have been answered on Stack Overflow, but the solutions haven't fixed my particular problem, so I have to ask...
I have an app that needs to make directories and modify files outside the site directory. This works find on the production server.
After spinning up a test server with the exact same version of Ubuntu and PHP, I'm getting errors on the staging server when it tries to open files or create directories.
Here are the errors:
mkdir() [http://php.net/function.mkdir]: Permission denied
fopen(/root/Dropbox/Backend/Booth-01/settings.sh) [http://php.net/function.fopen]: failed to open stream: Permission denied
Things I have tried:
checking the username running the application (it's www-data)
changing the owner of the external directory recursively to www-data
changing permissions on the directory to 777 (I know, this is a bad idea, but I was just trying it to see if that would help until I figured out what the issue was and will change the permissions to something more restrictive once I get it working)
checking the umask value. It was set to 0002, which shouldn't give me problems. Just for kicks, I tried changing it to 0000 and it didn't help.
checking to make sure PHP's safe mode wasn't enabled.
checking to make sure that nothing was specified in open_basedir. In any case, if that was the issue, it would throw a different error message.
I can't think of what to try next and I'm hoping that someone else is seeing something that I'm not.
Ubuntu 12.04.5 x64
PHP 5.3.10
It's not only the folder itself you have to have permissions on. You should also check the parent folders. I think, if you check this, this will fix your problem.
If this is an external drive (see if it shows up in mount) then you may have to remount it. An auto-mounted external drive can thwart permissions
sudo umount <moint-point>
sudo mount /dev/<device> <new-moint-point>
When I try to login to PHPmyadmin I get the following error:
phpMyAdmin - Error Cannot start session without errors, please check errors given
in your PHP and/or webserver log file and configure your PHP installation properly.
Also ensure that cookies are enabled in your browser.
I tried to fix by changing permissions of the /tmp (listed as sessions path in php.ini) to 755 then tried 777 I also tried changing user and group ownership with chown to www-data. (www-data listed as user for php-fpm and Nginx) Tried multiple web browsers, deleting cookies, deleting all session files from server's /tmp folder. PHP info shows sessions loaded. Not sure what else it could be, all other areas of the site load perfect and there's nothing in error logs related.
Lastly I followed instructions here:
http://wiki.phpmyadmin.net/pma/session.save_path
and the results are:
"If a session could be started successfully you should not see any Warning(s), otherwise check the path/folder mentioned in the warning(s) for proper access rights.
The current "session.save_path" is "/etc/php/tmp".
Session file name: "sess_o47fu5ovh3o91m6h2b9pumu0g6".
Any PHP guru's which this is something you are familiar with?
Not sure if this applies to your case - but it's my understanding chmod 755 or 777 will not run the scripts. Try this:
chmod o-rw config.inc.php
I my case tmp folder was deleted. So i created again tmp folder its working
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.