403 Forbidden Error on SharePoint Images (Images Broken, Won't Load)

Some terms for indexing purposes: SharePoint broken images, SharePoint images broken, SharePoint won't load images, SharePoint images won't load, SharePoint not loading images, SharePoint images not loading, SharePoint red X images, SharePoint images red X.

Well, when I ran into this issue I searched like crazy for a solution and came up empty. I don't want that to happen to the next person who runs into the issue so hence this blog post.

Here's the scenario: I did a new installation of SharePoint Server 2007 on Windows Server 2008 R2. Incidentally, this process itself was a major pain in the butt, but I finally got it done--only to find that none of the standard images (those located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\IMAGES and mapped in IIS so they load from http://[server]/_layouts/images) would load due to 403 Forbidden errors.

Now, these 403 errors are not immediately obvious--all you see at first is that the images are broken (that is, they won't load: instead you see a "red X" in place of the images). When you dig, you figure out the actual URLs being requested are in http://[server]/_layouts/images and that these requests are resulting in 403 errors.

For purposes of search engine indexing (that is, so others affected can find this post), here's the exact text displayed in the browser when you make a direct request for one of these images:

The website declined to show this webpage
HTTP 403

Most likely causes:
• This website requires you to log in.

What you can try:
Go back to the previous page.

More information
This error (HTTP 403 Forbidden) means that Internet Explorer was able to connect to the website, but it does not have permission to view the webpage.

For more information about HTTP errors, see Help.

As you may know, 403 errors are those that indicate that the requested file is present, you just can't get to it (the displayed message makes that pretty clear). So I knew I was dealing with a permissions issue--I just didn't know precisely what caused that issue. And to be honest, I never really figured it out. But what's important is that I did figure out--okay, stumble upon--a way to solve it: in IIS, for each SharePoint Web Site, there's a Virtual Directory for _layouts and inside of that is an Application for images; I simply deleted and recreated that Application for images and all was well. I had to do this for each SharePoint Web Site and in each case it fixed the problem so I am certain that this is reliably solves the issue.

UPDATE 2010-06-02: I just ran into a similar problem. I came back here to this blog post and followed my own instructions--only to find that it didn't work. The problem this time was that I could get to resources using but not using http://. Well, technically I could get to resources using http://, I just couldn't authenticate successfully. So how exactly did this cause broken images? Well, even when referencing a page itself as, SharePoint has a penchant for using http:// for image URLs included in the page--and so the page itself would load fine but the images wouldn't because of the authentication issue. The problem turned out to be that I had misspelled "Administrator" as "Adminstrator" so watch out for stupid spelling mistakes causing you to waste lots of time! I don't have any reason to believe this had anything to do with the issue this blog post is about, but since it manifested similar symptoms, I thought it was worth including here.

PlateSpinner's Gravatar THANK YOU for getting me started dealing with this problem. I had the exact same issue but I figured out what was causing it.

I used a clean install to compare my broken one to. I turned out to be a Handler Mapping configured into the images application that mapped to Cold Fusion. The server I was installing on has Cold Fusion installed and the system.web has handlers built in that use it. As soon as I removed that handler from the images application, the red x's went away and it was fixed.

It may not be Cold Fusion for you, but check out your handler mappings and look for stuff that shouldn't be there for a SharePoint site.

Good luck!
# Posted By PlateSpinner | 2/24/10 3:31 PM
JB's Gravatar My problem was that I was getting an application error. I had tried to fix an earlier issue by adding a wildcard application mapping to isapi.dll to all folders. So I believe aspnet_isapi.dll was now trying to deliver the images.

To resolve: Right click on images folder, properties, Virtual Directory tab, configuration, and clear the wildcard application mapping.
# Posted By JB | 6/11/10 8:41 AM
Saravanan Thandavan's Gravatar Thanks a lot JB, your solution aspnet_isapi.dll wildcard clearing helped me to fix 500 Internal server error during loading of images under /_layouts/images/ virtula directory. Thanks again!!
# Posted By Saravanan Thandavan | 11/16/10 8:00 PM
Jay's Gravatar Thanks Josh . It resolved my problem. It took me two days to resolve my isse.
# Posted By Jay | 3/8/11 4:41 PM
Bill's Gravatar Hey, thanks for the post - worked wonders for my dev install of sharepoint services 3.0 on windows 7.
# Posted By Bill | 6/2/11 1:51 AM
Andrew's Gravatar It worked as it has to. Super. I spent a week trying to resolve this problem. After installing Sharepoint Foundation 2010 on Windows Server 2008R2 my Central Admin css and images were not loaded. As a result I couldn't create any web application or site collection.
# Posted By Andrew | 6/17/11 2:08 PM
Roy Joyson's Gravatar Thanks for the blog, I tried the same, it didnt resolve the issue. In my scenario it gets automatically fixed while running a powershell script to create a web application in the server
# Posted By Roy Joyson | 9/16/11 7:54 AM
Edwin Bush's Gravatar I had to go to the virtual directories under _layouts in IIS, and for each one, on their Handler Mappings page, I had to use the Revert To Parent Action. After that, I had no issues loading the images and css.
# Posted By Edwin Bush | 9/28/11 3:48 PM
Edwin Bush's Gravatar On a side note, I had run into the issue because the server also had dotDefender on it. I did not have this issue until dotDefender was installed.
# Posted By Edwin Bush | 9/29/11 4:57 PM
Tinminator's Gravatar In my case, The App Pool of the parent web application and the _layout\images application are different; this must have made SharePoint unhappy, since the parent application must have done some routing and when handing over to the child application, the client identity could not had flown through (different app pools).
Anyone care to dig deeper into the bowel of the beast?
# Posted By Tinminator | 10/3/11 9:16 PM
Russell Healey's Gravatar A very helpful article. We changed timeout settings for asp scripts on a sharepoint site. This had the knock-on effect of spuriously adding in a wildcard application mapping to isapi.dll on
the images virtual directory and the inc virtual directory. We thought that the problem was permissions related (either IIS permissions or NTFS permission0, but that was not the case.
We fixed the problem by doing Properites->Virtual Directory->Configuration and removing the wild card application mapping from these two virtual directories.
Thanks again
# Posted By Russell Healey | 10/5/11 8:55 AM
Shaun's Gravatar Thank you for this post, it was a great guide in helping me solve this problem, though I didn't do exactly as you did.

I was actually able to just backup the existing "images" virtual directory to a file, then re-create it from that file, choosing to replace the existing directory. This makes me think maybe there was something in the IIS metabase that was the root cause of this? Not sure, but just as you experienced, the solution works and I'm not going to complain about how I got there ;)
# Posted By Shaun | 2/7/12 11:14 AM
Makesh's Gravatar I had to follow the instructions from Edwin,
Go to the virtual directories under _layouts in IIS, and for each one, on their Handler Mappings page, I had to use the Revert To Parent Action. After that, I had no issues loading the images and css.
Thanks Again.
# Posted By Makesh | 4/26/12 3:34 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.002. Contact Blog Owner