copy() function returns "permission denied" - php

The code below used to work just fine, but since upgrading my system (from Mandriva 2010 & KDE 4 to Fedora 23 & KDE 5.14) a lot of things have broken, including this. I've managed to fix most of the other problems, but this specific issue is still eluding me.
I suspect the code itself isn't the problem, but I'll post it here so you have all the elements:
$infile = stripslashes($infile);
$filepath = "../site/images/thumbs/$dlettr/";
$outfile = $filepath . $id . '-ori.' . $fext;
copy($infile, $outfile);
$gis = getimagesize($outfile);
$width = $gis[0];
$height = $gis[1];
$outfile2 = str_replace("-ori.$fext", '-0.jpg', $outfile);
$im = new Imagick("$outfile");
$im->setImageFormat("jpg");
$im->writeImage("$outfile2");
unlink($outfile);
The original $infile is the URL of an image that is passed through a form.
$dlettr is a letter that is determined earlier in the code.
$fext is the file extension, also determined earlier.
$id is a numerical associated with the page the code is running on, and thus a unique identifier for the file.
What the code does is simply download an image from the given URL, save it in the appropriate path, and associate it with the current page it is being processed from.
Since upgrading, I now get the following when I try to run the code, regardless of the URL:
Warning: copy(../site/images/thumbs/G/27879-ori.jpg): failed to open stream: Permission denied in /var/www/html/site/index.php on line 1055
Warning: getimagesize(../site/images/thumbs/G/27879-ori.jpg): failed to open stream: No such file or directory in /var/www/html/site/index.php on line 1057
Fatal error: Uncaught exception 'ImagickException' with message 'unable to open image `../site/images/thumbs/G/27879-ori.jpg': No such file or directory # error/blob.c/OpenBlob/2701' in /var/www/html/site/index.php:1064 Stack trace: #0 /var/www/html/site/index.php(1064): Imagick->__construct('../site/images...') #1 {main} thrown in /var/www/html/site/index.php on line 1064
Yes, the ImageMagick plugin is installed ;-)
At first I thought it might be a SELinux issue, as many of my other problems have been linked to that, but I'm not seeing any errors in the audit log, so that's not it.
So I thought of a permissions issue, because of the "Permission denied", so I tweaked those to death but to no avail. They currently are set to 777 for both folders and files, and STILL it won't save the picture!
As for ownership, files and folders are owned by user:user, with apache being a member of my user's group (so it should be able to access the folders and save an image within).
One little detail I should specify, that I think might be the heart of the problem (though it worked fine in my previous system) is that I have limited space on the /var partition, and since I expect the image library to grow quite a bit, I am actually storing the pictures in a different, larger partition, and symlinked the folder into /var/www/html/site:
$ ls -l /var/www/html/site/
lrwxrwxrwx. 1 user user 17 Oct 9 04:51 images -> /mnt/site/images
I tried to google the errors I get, but I'm only seeing problems that were resolved by chmod, which obviously is not doing anything here... Likewise, there are a few similar questions on stackoverflow, but none that really match my exact situation.
Side note: My Apache user is named 'apache', and there apparently is no php user in Fedora 23 (the service is started along with apache, so I guess apache is also the php user...)

Related

Why is the path truncated / cut off in the PHP error log?

I have a WordPress web site running on Windows Server 2012 R2 via IIS and PHP 7.1.1. Everything works well, except once or twice a day, the site returns a white screen (HTTP 500) and the error log shows the following errors:
[17-Jan-2019 15:29:15 UTC] PHP Warning: require_once(D:\Webs\www.WebS): failed to open stream: No such file or directory in D:\Webs\www.WebSite.com\wp-content\plugins\captcha\bws_menu\bws_include.php on line 91
[17-Jan-2019 15:29:15 UTC] PHP Fatal error: require_once(): Failed opening required 'D:\Webs\www.WebSite.com/wp-content/plugins/captcha/bws_menu/bws_functions.php' (include_path='.;C:\php\pear') in D:\Webs\www.WebSite.com\wp-content\plugins\captcha\bws_menu\bws_include.php on line 91
FYI - I have changed the path off of D:\Webs to show a fictitious website name.
Notice that the path is cut off. Sometimes the path is cut off in different places. Sometimes it's to completely different files for completely different plugis. Sometimes it's even complaining about WordPress core. The only thing consistent is that once this happens, the exact same path is the failure until I recycle the App Pool. When it happens again, it's a different file, but complains about the same file until I recycle the App Pool.
What gives?
The only workaround I have is to recycle the app pool or set IIS to automatically recycle on a schedule. Neither of these are good long term solutions.
I should also note that this server has about 10 other WordPress sites running. They each have their own App Pool and run from their own folder. They never, ever have this problem.
Also, resources on the server are excellent. At the highest traffic times, the CPU's are less than 50% and there is less than 75% memory utilization. There are also many gigabytes of free disk space on the system volume as well as the data volume the site runs from.
Please don't reply with "don't run PHP or WordPress on Windows/IIS." That's not helpful - I cannot change the environment and I need to figure out the solution.
I have 100% control of the server environment and can debug/troubleshoot as needed. So if there's any way to get more information, please let me know!

Prestashop installation on server giving Internal server error 500

Having the same problem while installing the latest Prestashop on my server. So as #Agnes Tom has recommended, I changed the define.inc.php file and this is the error it´s showing up:
Warning: session_start(): open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2)
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/install/classes/session.php on line 47 Notice: Use of undefined constant _NEW_COOKIE_KEY_ - assumed '_NEW_COOKIE_KEY_'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/Cookie.php on line 79 Fatal error: Uncaught exception 'Defuse\Crypto\Exception\BadFormatException' with message 'Encoding::hexToBin() input is not a hex string.'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php:65 Stack trace:
#0 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php(164): Defuse\Crypto\Encoding::hexToBin('_NEW_COOKIE_KEY...')
#1 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Key.php(38): Defuse\Crypto\Encoding::loadBytesFromChecksummedAsciiSafeString('\xDE\xF0\x00\x00', '_NEW_COOKIE_KEY...')
#2 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(112): Defuse\Crypto\Key::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#3 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(46): PhpEncryptionEngineCore::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#4 /hermes/bosnaweb14a/b1 in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php on line 65
Warning: Unknown: open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2) 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 (/var/php_sessions) in Unknown on line 0
Might anyone helping me to know how to solve this error??
Thank you for your time
It's throwing an error saying it can't find or write to '/var/php_sessions/'
Do you have full access to the server?
If so, check if that folder exists and if the user or web server has permission to write to it, or change in php.ini
session.save_path = "/var/php_sessions"
To something like :
session.save_path = "/home/user/sessions"
Again, must be an existing folder with read/write permissions for the user or web server (this depends if you run the web server as own user or as account user).
If it's a shared envoirement, you better contact you hosting provider. Some allow you to have a php.ini in your hosting root and you could use it to change the session.save_path, others ignore it.
How to recognize the Error 500
First, we need to go over the different ways you might see this error message on your computer. There are different forms of this message because each host/server is allowed to customize the way it’s displayed. Here are some common ways you might see this error.
“500 Internal Server Error”
“HTTP 500 – Internal Server Error”
“Internal Server Error”
“HTTP 500 Internal Error”
“500 Error”
“HTTP Error 500″
Most times you will see this message accompanied by various forms of this classic ambiguous line
“The server encountered an unexpected condition that prevented it from fulfilling the request by the client”
It’s important to note that this error can be shown on any browser and any operating system (sorry, but switching to the new Mac Pro will not solve this problem) Here is a screenshot of one of the ways this error might be displayed on your browser.
Internal error server
What is the 500 Error?
Put simply, the 500 error is the Web servers way of saying “Something went wrong but I can’t tell you what, sorry.” This is what we call a “server-side” error. That means that there is something wrong with the server who is hosting the website. It is an extremely general error usually caused by configuration issues with the websites programming, PHP or system permissions.
How Can I Troubleshoot?
Don’t fret; although this error message is absurdly vague, you still have ways to find more information. Web servers are almost always configured to hide specific error messages. If your PrestaShop store is suffering from this debilitating error, you can turn on PrestaShop’s Error Reporting from FTP or your hosting’s CPanel to get more details.
There are two ways to turn on Error Reporting in PrestaShop depending on what version you have.
For PrestaShop v1.4 through v1.5.2
Open config/config.inc.php
On or around line 29 you will find this line
#ini_set('display_errors', 'off');
Change that line to read
#ini_set('display_errors', 'on');
For PrestaShop v1.5.3+
Open config/defines.inc.php
On or around line 28 you will find this line
define('_PS_MODE_DEV_', false);
Change that line to read
define('_PS_MODE_DEV_', true);
Once you enable error reporting through your FTP or CPanel, you can navigate back to your PrestaShop’s front or back office and reproduce the error or issue you are having. For example, if you are not able to access your website because of the 500 error, you will need to turn on error reporting and refresh the page(s) that had the error. There will be additional information that you can use to investigate the problem.
Investigating the Error
Once you have the additional information, there are some standard ways to further investigate the error. First, let’s go over some the most common ways this problem is caused. Once we find the cause of this error, it is much easier to solve.
Permissions: Many times you will find that the permission setting on one of your folders is set incorrectly. It could be a simple fix as switching a file/folder permission from 777 to 755 or vice versa. In most cases permission sets of 777 are extremely unsafe and can allow even an amateur hacker to access your files and put malicious code in it. Make sure to check with your hosting provider for specific information about permissions set as some servers have different regulations.
Incorrectly configured .htaccess: Oftentimes you will receive an internal server error when the htaccess file is configured incorrectly. For PrestaShop purposes, the main culprits of the htaccess errors are “URL Rewrite” settings or Friendly URL enabling. The htaccess syntax is very strict so even one wrong character or command will cause the server to return an Internal Error 500. Make a backup of your htaccess and regenerate the htaccess file either through the back office or by toggling the Enable Friendly URL option.
Server timeout: Every server has their own timeout setting, which sets the time that any given script can run. If the function or script crosses that limit, you will receive an error 500. The most common scripts in PrestaShop that can take too long to load are CSV Imports, backups, translation loading, import/exports and thumbnail regeneration. Many times the server limit is 30 seconds, which is not long enough to run these scripts. You should contact your hosting provider and inquire about changing the limit, at least temporarily.
Now, if the problem is not solved by investigating these common causes, you should also take a look at the Apache and PHP Error logs. These are provided by your hosting provider but sometimes you will need to contact them directly in order to have access to these log files.

MediaWiki 1.27 warning requiring SpecialUserLogin.php

I've updated my mediawiki from 1.26.2 to 1.27, the installation process finished ok, but when I try to access I received this error:
Warning:
require(/var/app/current/includes/specials/SpecialUserLogin.php):
failed to open stream: No such file or directory in
/var/app/current/includes/AutoLoader.php on line 81 Fatal error:
require(): Failed opening required
'/var/app/current/includes/specials/SpecialUserLogin.php'
(include_path='/var/app/current/vendor/pear/pear_exception:/var/app/current/vendor/pear/console_getopt:/var/app/current/vendor/pear/pear-core-minimal/src:/var/app/current/vendor/pear/mail_mime:/var/app/current/vendor/pear/mail_mime-decode:/var/app/current/vendor/pear/net_socket:/var/app/current/vendor/pear/net_smtp:/var/app/current/vendor/pear/mail:.:/usr/share/pear:/usr/share/php')
in /var/app/current/includes/AutoLoader.php on line 81
I have no idea why is this happening. If I check the files in my server they're there. I'm also having template issues if I choose vector I only get a messed up template, without styling.
I'm using PHP 5.6.
I hope someone can help me.
I just stumbled across this same exact error after upgrading to MW 1.27.
In my case, the SpecialUserlogin.php existed and all of the permissions were right BUT the word login was written in lowercase so the system thought this file didn't exist. So I just renamed the SpecialUserlogin.php to SpecialUserLogin.php and b00m, it worked!
As for your templating issues, check the common.css file. Copy paste everything out of there, so it's empty, if you don't use it. And check that you're calling your style files correctly in your template.

What can cause a web server to not find an XML file?

I have a PHP script which reads from an xml file to generate a table. The first thing it does is check to make sure the file exists.
$path = getcwd();
if(file_exists($path.'\inc\php\kbs.xml')){
$kbs = simplexml_load_file($path.'\inc\php\kbs.xml');
} else {
echo "Error: No KB file found";
}
For some reason, intermittently, it doesn't find the file. I've tried removing the file_exists check all together (since I know the file does exist) but it still doesn't load the file at times. I can refresh the page and 7 times out of 10 it doesn't load, but sometimes it does.
I never ran into this problem during development, but once it went production (being used by maybe 200 users now) it started happening.
How do I go about troubleshooting this? (PHP 5.2.14 running on IIS)
EDIT: Error logs give me the following messages when it fails:
Notice: Undefined variable: kbs in <the path> on line 16
Notice: Trying to get property of non-object in <the path> on line 16
Warning: Invalid argument supplied for foreach() in <the path> on line 16
line 16 is the first time the variable $kbs is accessed. Obviously $kbs isn't set if the file isn't found.
Please use the absolute path, relative path make things a mess.
Is the location relative to PHP? Do permissions allow the web server to see it?

Zend_Search_Lucene crashes during indexing

I wanted to create search engine for my webpage, but during indexing on server it crashes with errors :
Warning: opendir(/admin/lucene/) [function.opendir]: failed to open dir: Too many open files in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 159
Warning: readdir(): supplied argument is not a valid Directory resource in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 160
Warning: closedir(): supplied argument is not a valid Directory resource in /admin/includes/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 167
Fatal error: Ignoring exception from Zend_Search_Lucene_Proxy::__destruct() while an exception is already active (Uncaught Zend_Search_Lucene_Exception in /admin/includes/Zend/Search/Lucene/Storage/File/Filesystem.php on line 66) in /admin/test.php on line 549
I am using newest version of ZF. Is there code solution for such error - I run script on localhost and it works great.
Thanks for any help.
It seems the problem is in the large number of segments in the index.
Could you check how much files does index folder contain?
There are two ways to solve this problem:
a) Optimize index more often.
b) Use another MaxBufferedDocs/MergeFactor parameters. See Zend_Search_Lucene documentation for details.
If it doesn't help, please register JIRA issue for the problem.
PHP has hit the limit on the number of files it can have open at once it seems might be an option to change in php.ini, could be an OS (quota) limit or you might be able to tell the indexer to slow down and not have so many files open simultaneously.
This is most definitely a Linux/kernel imposed limitation. Use the following command as root on your machine:
cat /proc/sys/fs/file-nr
Return values are defined as:
Total allocated file descriptors
Total free allocated file descriptors
Maximum open file descriptors
I'm also going to take a guess and say you are on a shared hosting machine. If this is the case, I imagine that this sort of issue may come up frequently.
Finally, the following article provides a good amount of information on Linux and open file descriptors even if it is a little dated.
http://www.netadmintools.com/art295.html

Categories