hopefully someone can shed some light on my problem. I just reinstalled my OS (lubuntu 12.10) and have set up my local server. Everything seems to be working properly except for the one file I'm currently working on. When I try to run it in the browser, it downloads and/or gives a Server Error (HTTP Error 500).
I don't suppose it's an Apache or PHP problem since other files work just fine, but I don't think there's anything wrong with the code in the file in question.
What else could be causing this issue?
There is no need to "suppose" or devise "more than likely" cause or guess "what else".
HTTP Error 500 means there is something verbose in the server's error_log.
Just open it end get the exact explanation of the problem.
Please, do not take blind action, out of mere guess. You can make things worse.
This problem is more then likely caused by a permissions issue.
The Apache server runs as www-data:www-data. What this means is that it is possible to have some permission issues with files that were created by another user.
To solve this, you should either add your user to the www-data group and set the /var/www directory to inherit the group www-data, or you can use chown to change the ownership of all the files to be on the www-data group.
To keep security in your system, you should also make sure that all your files have a permission set of 660, meaning that the owner and anybody of the user group of the file can both read and write, but any other user will not be able to do anything with it.
If you have a php script that does run more than 30 seconds (default) you have to change value of max_execution_time by using ini_set function.
Related
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 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>
It seems i cannot create files. When i set permissions to 777 On the folder i am trying to create a folder in then the script works fine. If the folder is set to 755, it fails. I do not know much about linux, but i am suppose to figure this stuff out. I have spent a couple hours trying stuff. Does anyone know how to make it so that apache has high enough permissions.
I know it is a permissions and apache problem, i just do not know how to fix this. I have edited the httpd.conf file, but i really do not know what i am doing... Any help? (I saved backup.)
Please stop suggesting to use 777. You're making your file writeable by everyone, which pretty much means you lose all security that the permission system was designed for. If you suggest this, think about the consequences it may have on a poorly configured webserver: it would become incredibly easy to "hack" the website, by overwriting the files. So, don't.
Michael: there's a perfectly viable reason why your script can't create the directory, the user running PHP (that might be different from Apache) simply doesn't have sufficient permissions to do so. Instead of changing the permissions, I think you should solve the underlying problem, meaning your files have the wrong owner, or Apache or PHP is running under the wrong user.
Now, it seems like you have your own server installed. You can determine which user is running PHP by running a simple script that calls the 'whoami' program installed in most linuxes:
<?php
echo `whoami`;
If all is right, you should see the username PHP is running under. Depending on your OS, this might be 'www-data', 'nobody', 'http', or any variation. If your website is the only website running, this is easy to change by changing the user Apache runs under. If you have Debian, like I tend to, you can edit the file /etc/apache2/envvars (as root), and change the value for APACHE_RUN_USER. Depending on your OS, this variable might be set in a different configuration file, so if you can't find it in /etc/apache2/envvars, try to search for the variable declaration by using:
$ grep -R "APACHE_RUN_USER=" .
From the directory all apache-config files are in.
If you're not the only one on the server, you might want to consider creating user accounts for every website, and using something like Apache2-MPM-ITK to change the RUN_USER depending on which website is called. Also, make sure that the user the PHP process is running under is the owner of the files, and the directories. You can accomplish that by using chown:
% chown theuser:theuser -R /var/www/website/
If PHP is running with it's own user, and is the owner of the files and directories it needs to write in, the permission 700 would be enough. I tend to use 750 for most files myself though, as I generally have multiple users in that group, and they can have reading permissions. So, you can change the permissions:
% chmod 0750 -R /var/www/website/
That should be it. If you having issues, let us know, and please don't ever take up any advice that essentially tells you: if security is bothering you, remove the security.
I have a similar problem but in my case I have SELinux running and it failed even with 0777 permission. Turns out I need to explicitly allow httpd to have write access on the directory using:
chcon -R -t httpd_sys_rw_content_t <PARENT_OF_MKDIR_TARGET>
SELinux Troubleshooter may have more details.
On ubuntu you edit /etc/apache2/envvars as Berry suggested.
When you change the Apache user, beware of unintended consequences. One of them is the PHP sessions that may be stored in /var/lib/php5. You may need to change the ownership of that folder too.
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.
My code
mkdir("/some/absolute/path",0777);
and
mkdir("relative/path", 0777);
is not working, safe mode is turned off, and I've even tried setting all of the parent folders to 777.
Any ideas?
EDIT: I do have error reporting turned on, in my frustration I've 777'd the whole path just to make sure that, that isn't the issue. It's gotta be something stupidly simple going on.
EDIT EDIT: Upvotes for everyone who responded with suggestions... But I'm not going to select an answer since this still isn't resolved, but then again I think this is going to be one of those ones left open forever.
EDIT x 3: So I have the most unsatisfactory resolution to this question ever... I started with a clean VM image, retried it and it works now. No joke.
Do all of the parent directories exist?
If not, you'll need to enable recursion (assuming PHP5 here):
mkdir('/path/to/your/dir',0777,true);
EDIT: Didn't see the hidden comment saying that every directory from var downward was set to world-writable, so I'm betting the directory path exists and the above won't be helpful. Sorry!
Are you trying to create those directories recursively, like you would do with mkdir -p on the command line? If so, specify true as the third parameter to mkdir.
And just to echo the previous suggestions, PLEASE specify the error messages you are getting. If you are not getting any, use this before your call: error_reporting(-1); // ALL messages and ini_set('display_errors', 'On');.
If anyone gets stuck with this problem.. there's one answer I can give you that I spend 2 hours on finding.. I tried with using a full path, and "../mydirectoryname".
Try using:
mkdir("./mydirectoryname", 0777, true);
Instead of..
mkdir("../mydirectoryname", 0777, true);
Have you tried with the shortest test possible?
mkdir('directory',0777);
If this does not work I would try creating with a standard CHMOD like 0755 (this is a totally random guess, maybe the server won't allow creating 0777 via PHP)
if this don't work I would say the server probably need different setup / php doesn' thave the writting right on folder, maybe you could ask your host provider?
I have similar problem and I found out, that I have no free space left on my drive. Check with command df (on linux) how full is your drive. It is possible that root is allowed to create files and folders in this situation, because he has pre-reserved space. If you run you script from command-line as root user - there is no error, but if your script is run by apache, then error occure.
For future references, the problem might come from the possibility that the directory where you're trying to create your new directory doesn't have enough permission.
For instance, your index directory might look like this:
index.php new_dirs_here
if new_dirs_here doesn't have enough permission then you can't create direcories inside.
To solve this, I'd use the command:
chmod 777 new_dirs_here
I'm not worrying about security now, Just trying to solve the immediate problem. You could of course look up a better permission settings, but the idea is that your new_dirs_here should have enough permissions.
Then, your mkdir() dunction should work just fine.
Good luck
Make sure the parent directories have correct write permissions, that was my problem
mkdir only creates one single directory when called without -p.
A directory in the path /usr/local/myfolder/ is missing, this is why you get the error. If you call mkdir -p, the missing path is created as well.
Another effect of using the -p option is that mkdir -p does not complain when the directory already exists. This is why this variant is frequently used in scripts.
chown www-data:www-data (address directory)
You're missing quotes around the path name parameter.
You must take the attribute in quotes:
mkdir('path/to/your/dir','0777');