10

When using a new installation of Drupal 7.10, I have set the directory for public uploads to sites/uploads.

When I then add an image to a content instance, I get the original uploaded to sites/example.org/files/imagename.png as expected. However, the other images (thumbnail, medium and large) do not get created at sites/example.org/styles/*.

The directory is readable and writeable by the PHP5-FPM user, and so there should be no issue permissions wise.

Why does this happen? How can I fix it?

Improve this question
1

7 Answers 7

Reset to default
13

Right, the answer is in fact a little more subtle than I realised. Turns out that D7's imagecache replacement needs some attention in your nginx vhost. Without the 404s being sent to Drupal for the missing files, the images are not created - something I didn't realise initially, as I'd assumed they were created on upload.

location @rewrite {
    rewrite ^/(.*)$ /index.php?q=$1;
}

location ~ ^/sites/.*/files/styles/ {
    try_files $uri @rewrite;
}

It needs to be added to your server definition, and you should be ready to roll. Clearly, the path may need altering for your setup, but for mine it was.

Improve this answer
5
  • 1
    Note that the @rewrite part needs to be defined appropriately elsewhere in the configuration file for this to work. That said, it already was in mine and this solved my problem as well, so thanks jvc26 :)
    – El Yobo
    Commented Feb 13, 2012 at 3:10
  • @ElYobo good point - have updated the answer to make sure that is clear. Thanks
    – jvc26
    Commented Feb 13, 2012 at 15:21
  • Would this affect an nginx reverse proxy config? I've got the same issue and this doesn't seem to fix that.
    – Grizly
    Commented Feb 28, 2014 at 1:45
  • If you want them to be created on upload drupal.org/project/imageinfo_cache does that
    – mikeytown2
    Commented Feb 25, 2015 at 16:39
  • Good catch. This eventually lead me to use the nginx's recommended server file instead of the one that DigitalOcean configures automatically with a one-click Drupal install.
    – Meglio
    Commented Jul 4, 2016 at 9:50
2

Be sure to check both the public file system path and the temporary path at admin/config/media/file-system

Once I had both of those folders set with the correct permissions, my subfolders are automatically created when I save a file, the image is saved, and the error message is gone :-)

Improve this answer
2

In my case the issue was causing because the images were fetched using https,

I added the following lines on the secure page settings to ignore https on file paths.

*/files/*

Hope this helps someone. :)

Improve this answer
1

While you do say that you have checked permissions, that's still where I would start, as I've had this issue myself, frequently, and it's nearly always been a permissions problem.

General advice: First of all, go to admin/config/media/file-system, and click "Save configuration". This will cause Drupal to re-evaluate the permissions of the set directories, and will give you error messages if it finds a problem.

Second: I assume that you have a apache, or www-data, or other users, that owns the webserver, as opposed to the php user? On a Linux or Mac system, sudo to that user. Trying to write a file as the right user, is the best way to truly ensure that you have the right permissions. Go to sites/domain.com/files/, and call "echo data > new_file; cat new_file;" in a terminal. This will verify that you actually can write to the write directory. Do the same with your tmp dir. Hopefully someone else can suggest how to perform the same actions on a system like windows.

Third: To rule out directory permissions, recursively apply 777 the the files directory. You can restore more sane permissions afterwards with

find . -type d -print0 | xargs -0 chmod 755
find . -type f -print0 | xargs -0 chmod 644

Fourth: Ensure that the tmp directory that has full permssions.

Fifth: You may need to start debugging the code if you have figured it out by now.

Improve this answer
2
  • Thanks for the suggestions: Have already tried the above, no errors from Drupal on the file-system change, so permissions must be fine. PHP processes all run as the user who can write to that directory, so the user the webserver runs as won't make a difference to write capability. Have checked manually permissions compatible with write. /tmp is as usual 777 so no write issues there. Path discrepancy has been sorted was a mistake on my part.
    – jvc26
    Commented Jan 8, 2012 at 22:14
  • As a heads up, the issue was one of nginx config, with issues for the passing of 404s to Drupal which in turn trigger thumbnail creation.
    – jvc26
    Commented Jan 9, 2012 at 17:42
1

To complete Letharion answer, here is the method I used to get thumbnail, medium... image styles created.

I precise that I first checked all the points listed above, without result.

Then (on a Linux OS), I edited /usr/local/etc/suphp.conf to change umask on php, so that it could create files AND directories with 755 permissions max (it was on 744 max).

And this definitively solved the problem. :)

Improve this answer
0

I'm on Drupal 8.0.3.
On my case this folder is not generated on the installation.

sites/default/files/field/image

So I put it by copying from the older version of Drupal installation.
All images including thumbnail, medium and large are now show up.

Improve this answer
-1

Check you .htaccess file in root and files directory. Replace with the new .htaccess file if required

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.