ImageMagick reported an error: convert: unable to open image `files/images/snacks n drinks_0.thumbnail.jpg': Permission denied.

Is your files/images directory read/writable to all? you should run this command: chmod -R 777 images when you are in the files directory.

Topologic, you have to do no such thing, and setting your permissions that way could be a big fat security hole under certain configurations. What you should do is ensure that the user that the web server runs under (on my Debian machine Apache runs under 'www-data', other systems use 'httpd', 'apache', etc) has read/write permissions on all files in the 'files' directory and read/write/execute permissions on the 'files' directory and all its subdirectories.

I'm pretty sure this is a bug in the module. I ran into this tonight, and wrote a little patch which fixes it on my server by using absolute paths when invoking the 'convert' binary.

I'm using ImageMagick 6.3.7 on Debian Lenny.

I don't use image magick so not in a position to test this patch.

Setting to needs review so others can test.

@davideads

Yeah, I violated one of the cardinal rules of permissioning. I run under a jailed shell in my shared web space, so I don't worry about it, but it is something that one shouldn't do.

In any event, your patch was applied correctly and I'm currently playing around with it to see if it fully works.

System specs:
Centos 5.4
ImageMagick 6.2.8 04/17/08

Since I am a moderate point release behind, I'm not sure if this poses any problems.

Thanks,
Chris

Thank you. Your patch did solv this error "ImageMagick reported an error: convert: unable to open image"

I'm happy to commit this, though, is there a cleaner way of getting Drupal's absolute path thatn:

  global $_SERVER;
  $dir = str_replace('index.php', '', $_SERVER['SCRIPT_FILENAME']);

Looking at http://api.drupal.org/api/function/conf_path, seems not.
However, it also seems there's no need to say 'global $_SERVER;' first, so we can lose that line.

Ah.

One small problem: what is 'imageapi_imagemagick.module'? I don't have it in Image module. Are you sure this issue is filed in the right place?

In the meantime, would any of you users of ImageMagick feel able to update this documentation page? -- http://drupal.org/node/131994

thanks ... bug fix worked for me.

Where?

Ah right. ImageAPI. Refiling.

This patch is similar to the one in #2 except it uses a static variable to maintain the path of the working directory for the call to convert. In situations where a page full of thumbnails are being generated, we don't want to compute the working directory with a call to str_replace or substring or whatever for every call made to theme('imagecache', ...)

This patch, in general, is important for situations where the drupal installation is not the same as the document root of the virtual host. In other words, your drupal install is in a subdirectory of the web server document root (e.g, http://example.com/subdirectory instead of http://example.com).

i had this issue. turns out it was only because my drupal directory wasn't the document root directory. silly me.

Excellent! This fixes the problem for us, but why define the working directory as substr($_SERVER['SCRIPT_FILENAME'], 0, strpos($_SERVER['SCRIPT_FILENAME'], 'index.php')); as opposed to just using getcwd().

Either way, we are really looking forward to a patch for this issue in the next release.

I wasn't aware of PHP's getcwd() function. If someone wants to re-roll that patch where the working directory is defined using getcwd(), please feel free to do so. Otherwise, I'll can try this myself when time and memory simultaneously permit.

-Ankur

here's another patch with getcwd().

this has been a problem for me with imagecache, where my website is installed in a subdirectory.

So I take it I need to replace something with the patch?

Which lines, please.

Thanks.

I must be doing the wrong line as I get

Parse error: syntax error, unexpected $end in /home/content/ccc/modules/imageapi/imageapi_imagemagick.module on line 224

*Nevermind figured it out.

thanks for the patch! I believe this should be merged in a stable release since anybody not installing in the web root has this problem?

I tried the getcwd patch and it works (although I did not manage to simply "patch -p0 < patchfile" it since it does not seem standard format?

I just filed a bug about this yesterday http://drupal.org/node/742226 , just didn't happen to come by this before.

It would be very nice to merge this in to the stable release. I don't trust my patching skills enough to use this on a production site.

to #18: my apologies on the patch-- i use git, and tried to create the patch through "git diff" using the module directory as the root. i don't know if that helps.

@20: yes, no problem, since the patch was quite small, I did it manually :)

The path #2 work for me

i think this is a duplicate of #360193: ImageAPI Broken - base_path() problem.

The getcwd() solution at #16 did the trick for me. Here's a patch file that works with "patch -p0 -i imageapi_615966_24.patch'