2

As you can see in the screenshot below, images that are processed through image styles aren't showing up and when trying to display them through their urls, we get a 403 access denied.

It's a fresh drupal install on a Debian 7 with no additional modules

Any ideas are welcome to overcome this problem

Thanks

enter image description here

closed as too broad by kiamlaluno Apr 16 '15 at 5:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    check your files folder permissions and owners... – Nikit Dec 1 '14 at 23:06
  • I checked. Permissions are messed up. When i install drupal locally (os X) it works fine but on debian, drupal creates folders with incorrect permissions. I'm thinking it has to do with the way htaccess interacts with the environment but have no idea how to fix it.I tried editing root and sites/default/files .htaccess files but it didn't help. Here are the permissions of the files directory (and its subdirectories : files drwxrwxr-x, files/field drwx------, files/styles drwxrwxr-x, ../styles/large drwx------, ..large/public drwx------, field drwx------, image drwxrwxr-x, image.jpg -rw-rw-r-- – FlashSP Dec 2 '14 at 0:53
  • 1
    It's not caused by htaccess, it's caused by how apache and php are invoked as processes. The typical setup nowadays would be to create a new user, assign that to the www group, give it limited permissions (no shell etc) and then run php via fcgi using vanilla ini. The user & config gets sandboxed, and files in the web root inherit its permissions, making things safer. The problem is that if you're managing files as a different user (FTP / ssh / VCS) the file owner and the webroot owner / process owner get mixed up, resulting in conflicting permissions. – murraybiscuit Dec 2 '14 at 2:19
2

It's common to have incorrect permissions on that folder. You'll need to fix the permissions for /site/default/files directory. For a complete answer, see the recommended directory permissions or just run the following from the website root (per @David's comment below).

find sites/default/files -type d -exec chmod 755 {} +
find sites/default/files -type f -exec chmod 644 {} +
chown -R www-data:www-data sites/default/files

For additional issues, check Status Reports on yourWebsiteName.com/admin/reports/status.

Update:

I think I found the issue.

There was a similar question asked on Drupal.

It seems that the issue is that certain hosts, such as BlueHost, HostMonster and Virtualmin forbid +FollowSymLinks. You will need to change +FollowSymLinks into +SymLinksIfOwnerMatch in your .htaccess file. See an entire discussion on Drupal.

0

In my case, the problem was just that sites/default/files had the rights set as 544 but needed to be 744. I am not sure why the prohibition of write results in the unability to read. So as this is a bit unintuitive I thought it might be useful for anybody with the same problem.

-2

Go to Terminal by pressing Ctrl+T Type : cd /var/www/drupal ( assuming it to be the drupal root for your site )

sudo chmod 777 -R sites/default/files

Now clear cache and try to update the previously created image style

  • 1
    You are assuming they are on Ubuntu (as I believe you are) which is not always the case. Also using is not only a bad advice but at many cases wouldn't even work. – Alexar Dec 21 '15 at 1:10
  • indeed. @timofey is the correct answer – Kojo Oct 26 '16 at 9:34

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