1

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...)

Community
  • 1
  • 1
asg
  • 33
  • 6
  • As seen by your `ls -l` output, this directory contains a symlink named "images" - the permissions you are seeing are therefore actually the permissons for your symlink, not for the directory itself. Have you checked if the actual directory (`/mnt/site/images`) also has the proper permissons? It sounds like, it does not :) – ArSeN Jan 16 '16 at 20:18
  • Permissions in /mnt/site/images are the same (777 for foldes & files). BTW, I also tried chown'ing everything (files, folders, symlink) to apache:apache, but that didn't help either. – asg Jan 16 '16 at 21:27
  • when you say **IN** that directory, did you also check the directory itself? like: `ls -l /mnt/site` ? – ArSeN Jan 16 '16 at 22:07
  • Yep. `ls -l /mnt/site` returns `drwxrwxrwx. 4 user user 4096 Oct 16 16:53 images` – asg Jan 16 '16 at 23:48
  • Hmm, okay, and does the directory inside there, namely `thumbs/G` also exist and does have the proper permissions? Remember, `copy()` does not create any directories. – ArSeN Jan 17 '16 at 08:26
  • Yeah, I created all the alphabetical folders I'd need in advance (A-Z) and they've all been chmod'ed 777. – asg Jan 17 '16 at 16:58
  • So... it looks like it WAS a selinux issue after all. I had ruled that out because there was absolutely nothing about this in the audit log. But I was so puzzled, I thought hey, maybe I should try 'setenforce 0' anyway, just in case... well, my copy() function worked after that!!! Very puzzling. So I should be able to resolve this now that I know what's causing it. – asg Jan 17 '16 at 17:00
  • There is now a troubleshooting checklist for this frequent error here, including how to diagnose for SELinux : http://stackoverflow.com/a/36577021/2873507 – Vic Seedoubleyew Apr 15 '16 at 14:40

0 Answers0