A: 

This might be of help. Also use fiddler to see exactly what the request is when it fails.

Otávio Décio
A: 

Try to narrow down it further:

  • What happens when this user types the URL http://yoursite/_layouts/AssetPortalBrowser.aspx in the location bar of his browser?

  • Is it the browser which can't access AssetPortalBrowser.aspx (= misconfig in IIS) or is AssetPortalBrowser.aspx trying to access something else (so AssetPortalBrowser.aspx is reporting the error)

Aaron Digulla
A: 

What is the substatus code of the 403? This typically appears as the number following the 403 in the IIS log.

The following table should help pin down the root cause of this 403:

None  Access is denied. 
1 Execute access is denied.
2 Read access is denied.
3 Write access is denied.
4 SSL is required to view this resource.
5 SSL 128 is required to view this resource.
6 IP address of the client has been rejected.
7 SSL client certificate is required.
8 DNS name of the client is rejected.
9 Too many clients are trying to connect to the Web server.
10 Web server is configured to deny Execute access.
11 Password has been changed.
12 Client certificate is denied access by the server certificate mapper.
13 Client certificate has been revoked on the Web server.
14 Directory listing is denied on the Web server.
15 Client access licenses have exceeded limits on the Web server.
16 Client certificate is ill-formed or is not trusted by the Web server.
17 Client certificate has expired or is not yet valid.
18 Cannot execute requested URL in the current application pool.
19 Cannot execute CGIs for the client in this application pool.
20 Passport logon failed.

(Source: HTTP 403.x-Forbidden (IIS 6.0))

shufler
+1  A: 

To answer a couple of the replies. If you put the full URL in his browser it gives the 403 error.

AssetPortalBrowser.aspx is trying to access something else.

The 403 is not showing the detailed dot error number.

hobbyman
take a look at this - http://autoexe.blogspot.com/2009/03/assetportalbrowser-403-access-denied.html
MNM
+1  A: 

I am thinking that the AssetPortalBrowser.aspx is making anobject model call to try and get the data to fill out the list of files. If that is the case and the page is not getting the correct value for the file library to get the images, the page is going to try and use a default value for the list of items. If that user does not have permissions on the default location, then a 403 would possibly result.

This is all speculation, but Fiddler does not show AssetPortalBrowser.aspx requesting any other page assets.

My short experiment typing /_layouts/AssetPortalBrowser.aspx directly into my browser window was consistently defaulting to a document library. That library did not have any relation to the site browsed immediately before opening the page, so it may be storing the default URL somewhere and it may quite a different location.

Best bet is to try and track down any recent changes (i.e. reduction) to that users permissions.

Nat
A: 

Thanks for that answer. Tracking down any recent changes to permission might be the place the start. The user having Full Control permission is what is throwing me off.

Could I write a console C# application that would show me all the users permissions on the list?

hobbyman
A: 

I had exactly this problem. After digging around and moving people between groups to see what groups were affected and what weren't, I discovered that you need to have at least "Read" access to the "Site Collection Documents" library at the root of the collection. Why this library was special and did not have inherited permissions eludes me...

As a SIte Admin, from the main Portal page: Site Settings -> Site Libraries and Lists -> Customize "Site Collection Documents". Have this library inherit permissions from its parent and all suddenly worked. Also check the "Site Collection Documents" while you're in there.

A: 

Bryan - Thanks for the answer. I'm looking at the permissions on the Site Collection Documents. It is already inheriting from the parent site.

I look down in the list and the user in question has Full Control permission.

Do you think if I un-inherit and re-inherit it might snap something back into place?

hobbyman
A: 

Couldn't hurt. Also check the the "Site Collection Images" library, since your original error mentiones the "PublishingImages" library.

A: 

A further thought: I managed to diagnose this problem by adding my test user into the Portal Owners group and then checking if the Browse works in a summary link webpart (which it did). If this same test works for you, it means that Portal Owners have access to something that the regular user does not. If this is the case, I'd check every libarary at the root level (same technique as above), looking for one that regular uses can't access.

Also, when in a summary link webpart and adding a new link, there's two Browse buttons: one goes to the page wer're dscussing here, and one goes to PortalImagePicker.aspx. Does this second button work for your user? Or are both giving 403 Forbidden?

A: 

I went through every list. There were a couple that un-inherited from the parent.

Should the permissions always inherit from the parent?

The user is out today so I'll have to wait until tomorrow to see if this was the fix.

hobbyman
A: 

If it's a system library, then yes, it probably should inherit. System libraries usually have something like "this library was created by the Publishing feature" in their description.

At the least, you could write down the existing permissions and then inherit. If that doesn't fix it, you can put the old ones back - no harm, no foul.

A: 

And specifically, it's not the inheritance that makes it work - it's having read access on the library. If it does not inerit but your user still has access to it, then that library isn't the problem.

+1  A: 

I recently blogged about just this subject

You need a specific set of rights to be able to browse using the AssetPortalBrowser. The tricky thing is that these rights have to be given on the site level, just giving these rights to a library is not enough. A second gotcha is that AssetPortalBrowser remembers your last browsed url. So the site you are currently adding rights to might not be the site generating the 403 error.

http://autoexe.blogspot.com/2009/03/assetportalbrowser-403-access-denied.html