theme_image_style_preview() and image_requirements() should check whether style directories are writable.

I had this issue as well. For me, it was a permission issue. I think this is because I upgraded Drupal using the method recommended in UPGRADE.txt: 6. Remove all old files and directories from the Drupal installation directory. Then, 7. Unpack the new files and directories into the Drupal installation directory. Then, 8. Copy your backed up "files" and "sites" directories to the Drupal installation directory.

So, then Drupal prompted me to make the /sites/defaut/files/ folder writeable, but that left /sites/default/files/styles/ un-writeable.

I have three possible suggestions: 1. Add a note about permissions to step 8 of UPGRADE.txt. 2. Make sure the warning about making /sites/default/files/ writeable also says to set the same permissions on sub-directories. 3. Add code to catch the error and display a warning if the image_style_create_derivative() fails. (At line 774 of /modules/image/image.admin.inc.)

I also got the "Error generating image" error while visiting an image like this:

http://example.com/sites/default/files/styles/medium/public/image.jpg

In my case, the GD PHP extension was not installed. Installing it (sudo apt-get install php5-gd) solved my problem.

Just in case other people still encounter this problem...

I'm hitting this error on beta3, it's throwing two errors for each image it should be previewing @admin/config/media/image-styles/edit/thumbnail and the previews don't appear.

Warning: Division by zero in theme_image_style_preview() (line 772 of /var/aegir/platforms/d7-prod-20101115-03/modules/image/image.admin.inc).
Warning: array_intersect_key(): Argument #1 is not an array in theme_image_style_preview() (line 774 of /var/aegir/platforms/d7-prod-20101115-03/modules/image/image.admin.inc).
Warning: Division by zero in theme_image_style_preview() (line 789 of /var/aegir/platforms/d7-prod-20101115-03/modules/image/image.admin.inc).
Warning: array_intersect_key(): Argument #1 is not an array in theme_image_style_preview() (line 791 of /var/aegir/platforms/d7-prod-20101115-03/modules/image/image.admin.inc).

Php version is: 5.3.2-1ubuntu4.5 on Ubuntu 10.04 LTS.

Log shows other errors before these:
"The selected image handling toolkit imageapi_imagemagick can not correctly process image_imageapi_imagemagick_get_info."
After:
"Unable to generate the derived image located at public://styles/thumbnail/public/modules/image/sample.png."
Location: sites/pen-dev.perlucida.com/files/styles/thumbnail/public/modules/image/sample.png?cache_bypass=1290081406

Switching image toolkit from imagemagick to GD is a workaround for the issue. Works fine with GD.

Ah. On closer inspection looks like my issue is with imageapi contrib, not core. Sorry for the issue noise.

Setting the title and version back to the original.

I am having these two errors on my logs.

Unable to generate the derived image located at public://styles/medium/public/pictures/picture-2-1298088526.jpg.
Failed to create style directory: public://styles/medium/public/pictures

any solutions

I figure it out and its not a bug. Its definitely user error. I believe the problem was because of an error in this directory:
Home » Administration » Configuration » People >> "Anonymous"

To resolve this.
1. Go to Home » Administration » Configuration » Media
2. look for:
   Public file system path (copy the text in the box below this line, in this case it is: sites/default/uploads/)
   sites/default/uploads/
3. then go back to Home » Administration » Reports
4. find the image directory error message and click the hyper-link
5. click the link of the error (image directory error)
6. Now you should be back where the error is generating, hopefully the users page.

----If you aren't at the user page, then go to Home » Administration » Configuration » People "Anonymous" user----

7. scroll down to Picture directory
8. paste what ever you copied in step 2 in the box under 'Picture directory'

Hopefully that is a hint for anybody that stumbles on the same problem. One last thing, I had to move a few images around to fix my other issue that was caused by this issue.

Good luck.
M Piatkowski

I actually have the same problem, and still i can't solve it. This is the error that I get:

Warning: getimagesize(/www/example/htdocs/sites/default/files/styles/thumbnail/public/modules/image/sample.png) [function.getimagesize]: failed to open stream: No such file or directory en image_gd_get_info() (línea 350 de /www/example/htdocs/modules/system/image.gd.inc).
Warning: Division by zero en theme_image_style_preview() (línea 787 de /www/example/htdocs/modules/image/image.admin.inc).
Warning: array_intersect_key() [function.array-intersect-key]: Argument #1 is not an array en theme_image_style_preview() (línea 789 de /www/example/htdocs/modules/image/image.admin.inc).

I get this (sometimes, but even when it doesn't show up the images doesn't get generated) when i try to modify the thumbnail image style, and the images that are supossed to be in this style doesn't get generated. I created more styles and have the same problem. I resinstalled drupal, and even with a fresh install happens the same. I did something that for a while worked, until i changed the style, not sure what. For a moment i thought that it was that i changed permissions in all folders and files of /sites/all/files to 777, altough some of them where, but i keep trying that with no good results. In the status report of drupal, says that everything related to images is working fine.

This puzzles me as in my own server, apache 2.2.17-2 in debian testing, with gd 2.0 installed i don't have any problem, and in the server that i hired, with gd 2.0.34 compatible (as says in drupal status report), i'm facing this problem...

I now know what whas happening...this error happens for me when drupal is in maintenance mode. But there is no problem when maintenance mode is turned off.

Same error message for me.

1. installed fresh copy of 7.0 (2011-Jan-05)
2. created content type "image", added image field called "picture", set field display to default "medium" format
3. added content of type "image" (uploaded one image file)
4. content displays blank, but creates a folder structure: /sites/default/files/styles/medium/public/ yet there is no image in the folder.
5. no error message generated (weirdest part, as it generates on another installation of drupal)
any new ideas? totally fresh installation. (running MAMP on localhost on a mac)

Please reference this support request (http://drupal.org/node/1121774) posted in the Post Installation Support forum. Same errors and the same problem, and all the steps taken to diagnose.

OOTB Drupal 7.0, default "thumbnail" style isn't even showing up.

I have done extensive testing and realized that I can upload any image file (png, gif, jpg) UNDER 1MB. Anything else simply doesn't display and doesn't get written to the server. Any ideas?

My issue is fixed. Set this in php.ini and restart web server. That simple. Can't believe it. (I increased first two to the 280 and 400 a little higher than what is recommended from drupal.org)

the memory limit is key i think.

max_execution_time = 280 ; Maximum execution time of each script, in seconds
max_input_time = 400 ; Maximum amount of time each script may spend parsing request data
memory_limit = 64M ; Maximum amount of memory a script may consume (24MB)

progone, the directories within public://styles were, for me, not writable by Group and World. I changed that and my problem (identical to yours) went away.

Same as #566226: Error on image preview in image styles ...

I had an incorrect sites/default/files/style directory ... as I use drush to generate content the styles directory was not accessible by apache.

Steps to reproduce:

1. Visit admin/config/media/image-styles/edit/thumbnail
2. See if everything is working
3. Remove the styles directory sudo rm -r sites/default/styles/
4. create the directory yourself mkdir sites/default/styles
5. Visit admin/config/media/image-styles/edit/thumbnail

The root cause is that styles is not checking for the result of image_style_create_derivative()

Patch adds a warning to the user.

+++ b/modules/image/image.admin.inc
@@ -774,7 +774,10 @@ function theme_image_style_preview($variables) {
+      $preview_file = "misc/message-24-error.png";

This image should be a better one. I have no clue what to use for that.

+++ b/modules/image/image.admin.inc
@@ -774,7 +774,10 @@ function theme_image_style_preview($variables) {
+      drupal_set_message('Unable to generate preview', 'error');

The message could suggest something about the path causing the problem.

Powered by Dreditor.

It still needs a review :)

See this issue #1020870: theme_image_style_preview() and image_requirements() should check whether style directories are writable that deals with the same problem.

Combining patch in #16 with patch from #1020870-20: theme_image_style_preview() and image_requirements() should check whether style directories are writable

Marking CNR for bot but also tagging "Needs tests" as it should be possible to test for this by changing the style directory to read-only, attempting to create an image, and checking for the proper error message.

I was getting the same error in 7.2, with the same issue as #16. I chowned the /sites/default/files/styles directory to give my apache user (www-data:www-data in my case) ownership of the directory. This fixed it for me.

Hello, is this implementet in the d7.7 ? see needs backport to D7 and the status needs tests. Maybe this can cause problems like this http://drupal.org/node/1170440 / http://drupal.org/node/1232452 ...but i get no error msg in d7.4 and d7.7 - the styles are not generated. so any option to check /sites/default/files/styles/andmore would be nice

I added a link to the status report when the generation failed.

subscribe

Thanks, working for me

working on prototype for client's site. images are uploading, but not displaying within page. do not have shell access to account / cannot change permissions.

I was finally able to get images to display. I added the styles (http://drupal.org/project/styles) and the insert (http://drupal.org/project/insert) modules and a field.tpl.php to my theme. then going over to structure/content types and under the display options for the field -- now there are options to chose: file style: thumbnail_square ... to original.

@karxpava : the problem is about the accessibility of the styles directory. If this directory is not accessible by the webserver the image derivatives cannot be calculated. Deleting the styles directory should solve the problem. My guess is that originals are always showed as these are not uploaded into the styles directory. Installing the style project has afaik nothing to do with this problem :-)

To people having tested the patches please set this issue to reviewed and tested by the community. That will speed up the backport to D7.

Still needs tests.

I've applied the patch in #23 and my styles directory is writeable, but I'm still getting these errors.

Watchdog Entry
http://awesomescreenshot.com/09eiqr65b

Unable to generate this image "picture-891-1311552000.jpg" which is derived from the user picture "picture-891.jpg" on http://ivaw.org/jeff-skjelver

On that page every image is correctly generated from "picture-891.jpg" as "picture-891-1311552429.jpg", yet the generation error is still thrown.

Here are ~20 watchdog entries for this error

Spreadsheet
http://minus.com/mb5tcIE

Pain text
http://pastebin.com/raw.php?i=90NEg1tF

Okay, the last hour i spent on finding the source of this most uninformative message "Error generating image". The problem in my case: GD was compiled in php, but the jpeg support was not. Mystery solved.

Is there no way to make the log entry more informative?

changing styles/large/public (I mean "public" dirrectories only) directories permition to 775 worked for me.

@pillarsdotnet please specify what tests you have in mind

@clemens.tolboom:

please specify what tests you have in mind

From #20:

it should be possible to test for this by changing the style directory to read-only, attempting to create an image, and checking for the proper error message.

Confirmed bug. This fix should be in D7 and D8 ASAP. Directory permissions are a common bug and throwing up warnings is bad all around.

I got this problem when I updated a site from D6 to D7. For all my sites that is a clean install of D7 I have no problems.

I have the same problem.

"* Warning: Division by zero in theme_image_style_preview() (line 783 of /path/to/drupal/modules/image/image.admin.inc).
* Warning: array_intersect_key(): Argument #1 is not an array in theme_image_style_preview() (line 785 of /path/to/drupal/modules/image/image.admin.inc)."

PHP gd library is installed, Drupal shows no errors on this.
File permissions: I've set it to 775, deleted it, recreated it (755), reset perms to 775...no change.
I've disabled and re-enabled image: no change.
I've uninstalled and re-enabled image: no change.

Using drush to clear all caches between attempts.

D6 projects on the same VPS (Linode, running latest Ubuntu) are fine, so I'm guessing this isn't a problem with the gd library or other environmental variables, but something screwy with the image implementation in D7. At an *extremely* late stage in this project, it looks like a rebuild or possibly a rebuild on D6 is going to be necessary. Disappointing that core image-handling is this badly broken so many months after the D7 release. Any troubleshooting tips not mentioned so far would be greatly appreciated. Thanks!

Updated issue summary.

This is not critical as there are workaround (see the issue summary). Feel free to update the issue summary to make the workaround even better.

I put it back to normal.

Updated issue summary.

Try this in terminal
sudo chmod 777 -R followed by your directory path ie; sites/default/files and so on.
This worked for me.

Fixed original reporter
Added another drush example.

@Sabareesh Prasad don't change the version just because it works for you.

The issue summary contains your workaround. You may edit that if the phrasing is not ok.

See #20 which states 'needs backport'

(So this was a non-informative issue change)

(but) this is your first comment so welcome to drupal :-)

I had the same error as #1 using imagemagick tool kit on a fresh install of d7. I hadn't set the path to convert (usr/bin/convert) in the tool kit config -- doing that made the issue go away

-z

Hey Ascii122, can you clarified how you fixed this? What do you mean you had not set the path, where do you set the path. I never had to do this before after installing Drupal 7 everything usually worked. I am getting the same error as #1.

hi cabplan

I mean when you enable imagemagick in image toolkits (admin/config/media/image-toolkit) you then must set the path to convert

Path to the "convert" binary *

mine is /usr/bin/convert which is standard for many systems. If you ssh into your account you can try locate convert and see where the binary is.

The standard install hadn't set this path and I had those errors.. also I noticed if you select image magick tool kit you have to then go *back* to image tool kits in order to see the config section for paths. I had just selected and moved on and didn't realize I needed that path.

Hope that helps

-z (aka ascii 122)

I had same problem (same error messages with image styles), proposed solution with chmod worked fine.

This fixed the issue for me as well. In my particular hosting scenario I could log into a Parallels "Power Panel" (*urk*) and edit the permissions there (Container Management > File Manager)

Sabareesh Prasad, setting permissions to 777 on a webserver is dangerous . Hackers can take over your computer and do malicious or criminal activity against yourself or other domains.

progone: all the directories under sites/default/files need to be writable for them to work. Setting those dirs to 777 is fine. Setting some of the files in those dirs to writable might not be such a good idea..

Simply going through the steps in #16 fixed the problem on my local machine for one of the locally-hosted development sites. I thought I had also tried simply changing the styles directory (and all inside) to 777 permissions, but maybe I didn't... anyways, just voicing my support and subscribing :)

Why not 775? It is a little safer.

On my local dev machine, I'm not as worried, since the web server's not accessible to the public. On a production server, I'd never recommend 777 :)

#23: check_writable_styles_directory-873838-23.patch queued for re-testing.

My issues was the same as 31 and I agree that a more informative error message would be a big help.

I'm seeing the same issue, but I think it is related to the Adaptive Images module. I upgraded to 7.14 and now I'm no longer able to upload images, however if I comment out the code I put in the .htaccess file for Adaptive Images I'm able to upload images again.

Just a note: These same errors will show up if you are using selinux to secure your servers and you have not explicitly allowed httpd to create directories and files.

I tried to see what is the problem. My hosting provider sad, that they not allowed the chmod command in php, because it has to be enough to inhert from parent.
So with these restriction my site is not work properly , i can't use image styles. If i create a new style, the directory created, but the file not in the folder. i think this is the problem. Every other function will give the errors, no way the change permission, and the last is the division by zero.
Why not created the test.png? Not enough to change everything to 777, because not solved my problem.

Please do not change the version. This will have to be fixed in D8 first.

The styles folder has to be writable (777) otherwise you will get this error.

Sorry, but having any folder 777 is a security error. Even /tmp should be mounted 1777 with "nodev" and preferably "noexec" options.

After moving to a different server I ran into these errors.

Thanks to reading up here http://drupal.org/node/1121774, I was able to resolve the issue by:

- installing php5-gd on my new server (apt-get install php5-gd)
- giving apache ownership of directory (chown -R www-data.sshusername path/to/site)

Hope that helps (I know some of you have moved on to the root of this issue, however, this is the first topic that comes up when searching for this error).

I'm seeing an issue when a site is first deployed where image styles aren't being generated immediately for some images. They return a 500 error and if you try to visit them directly, I just get "Error generating image". If I log in to the site, the broken image(s) are then generated correctly. Since a number of other image are generated without a problem into sites/default/files/styles, I don't think this is an issue with being able to write to this directory. I don't see any of the PHP errors mentioned in this thread, either. Any ideas?

I had the same problem, but after I fixed /default/files/styles folder owner to _www (the same as it was for ctools folder downloaded by drush) and the problem was solved
so from /default run:
>sudo chown _www /files/styles

Fixed code block

Updated issue summary.

Updated issue summary.

i had this messages too after updating vom drupal 7.23 to 7.27. i had mirrored the site to my local server and updated it locally. then i reuploaded the whole site - including the directories/subdirectories and files of /sites/all/default/files via ftp. since ftp seems not to be the same sort of user as apache i ran into heavy problems with write-permissions. an ftp-command i ran through the files-directory and all subfolders -change permissions to 775- finally ruined it all. by chance i discovered an imagecache-preset that was created after i had run that command - and i noticed it's different ownership. the tec-guy at my provider reset the permissions through apache and now everything works fine again.

regards
karl

This came up during a Bug Smash triage session.

Creating a derivative image now seems to have code that covers this problem:

    // Build the destination folder tree if it doesn't already exist.
    if (!\Drupal::service('file_system')->prepareDirectory($directory, FileSystemInterface::CREATE_DIRECTORY | FileSystemInterface::MODIFY_PERMISSIONS)) {
      \Drupal::logger('image')->error('Failed to create style directory: %directory', ['%directory' => $directory]);
      return FALSE;
    }

The FileSystemInterface::MODIFY_PERMISSIONS will make sure the directory exists and is writable.

If you feel this is still an issue, please feel free to reopen this.