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:
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 http://127.0.0.1 but not using http://


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!
-PlateSpinner
To resolve: Right click on images folder, properties, Virtual Directory tab, configuration, and clear the wildcard application mapping.
!
Anyone care to dig deeper into the bowel of the beast?
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
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 ;)
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.