views:

978

answers:

4

We have a really strange problem.

My userid is a farm administrator and it a site collection admin on the site in question.

If I add a new group (to manage permissions), once I click the OK button on the create group page I get thrown to the Error: Access Denied page.

Here's the strange part, the group gets created.

If I try to add a user to that group, I get the access denied page but the user is not put in the group.

If I try to delete the group I get an error page that says Cannot complete this action. Please try again.

It appears to be only happening on this one site (and it's sub-sites).

There is nothing in any of the sharepoint logs or the event logs.

It has got to be a permission problem but I don't know what.

EDIT ------------------------------------ EDIT

After some more research I found this BLOG post. It states that a .NET 2.0 hotfix is the culprit of the problem and states that removing it will fix the problem.

I can't removed the hotfix because it is not installed.

Are we doomed to be stuck with this problem?

END EDIT

A: 

Sounds like maybe one of the system pages in _layouts has wacky permissions on it. Look in the IIS logs (not SharePoint logs) for a 401, 403 or 407 (or really, any HTTP code above 400) error for your user around the time you try to add/delete a group. This might point to the page that is having the problem, which will give you something to go on.

A: 

The error occurs on this page _layouts/aclinv.aspx. I'm capturing stuff from the IIS log but I can't really determine anything by what I'm seeing.

hobbyman
A: 

Hobbyman. Have you found a solution? We are facing pretty much the same problem.

Situation : We have MOSS installed and running for quite a while now. I have an account with Site Collection admin rights.

Symptoms : When I try to create a group on that Site Collection, putting my admin account as the group owner - which is there by default - I get the normal SharePoint access denied message (you are currently signed in as ... Sign in as a different user / request access...), and the group get's created anyway!!!

Also, there are some other weirdnesses. On some of the site collections, we have groups which are generated automaticaly ; owners, members, and visitors. The Member group is "owned" by the Owner group. In that group, I have my Site Collection Admin. The group does not accept any changes - I always get the SharePoint Access denied message.

What we have been able to identify is that the site collections that give us troubles are all on the same content database. The Site Collections on a different content DB don't have this trouble. We verified access rights for the pool and CA accounts and all seems to be working fine.

Any help would be great - we are desperate!

Regarding the .NET 2.0 hotfix, doesn't wss3 and MOSS run off .NET 3.5? I don't believe that the .NET 2 hotfix would cause problems. In any case, you even say you don't have it on your system, so it must be something else.

Do you have the hotfix on *your* system? Perhaps, if your scenario differs significantly from hobbyman, a solution that did not work for him might work for you? As for why... .NET 3.5 is built on .NET 2.0, so an update that changed, say, some bizarre behavior that MOSS happened to rely on might indeed break it...Oh - and if you post a new question describing your situation, more people will see it. Not too many looking for questions among the answers to *old* questions...
Shog9
Nope - we never found an answer for this issue.
hobbyman
A: 

if you host your sharepoint web applications somewhere other than the default location that IIS/SP uses; check to ensure that the Users group has read to the Bin directory of the affected application. For some reason when this particular app was created it failed to add the Users group to the Bin directory with Read as it normally would under normal circumstances. This is easily testable and fails and succeeds with consistency. the only thing I've noted that it affected was the issue regarding adding New Users to a site through the Sharepoint site GUI.

This is the error received when digging through my SP logs:

Application error when access /_layouts/aclinv.aspx, Error=Access to the path 'D:\ProdSites\SP-ProdSites*****\bin' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption) at System.IO.DirectoryInfo.GetFiles(String searchPattern, SearchOption searchOption) at System.IO.DirectoryInfo.GetFiles(String searchPattern) at System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() at System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) at System.Web.Configuration.AssemblyInfo.get_AssemblyInternal() at...

This is the error I was showing in the IIS logs:

2009-09-09 13:48:19 W3SVC1237373898 IP GET /OOD/_layouts/aclinv.aspx GroupId=9&Source=http%INFO2Fpeople%2Easpx%3FMembershipGroupId%3D9 80 domain\user IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Trident/4.0;+.NET+CLR+2.0.50727;+.NET+CLR+1.1.4322;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+OfficeLiveConnector.1.4;+OfficeLivePatch.1.3;+86e) 403 0 0

maybe people have already checked this but it took me a bit. I looked for patch KB928365 and it wasn't present (lots of other posts are recommending the removal of this patch to fix this issue). Also, the behavior was different in QA and Production as the acct I was using to add New Users to the site in QA had elevated priviledge due to its inclusion in the WSS_admin_wpg group (possibly due to the fact that its a farm admin in QA?)

Anyways, hopefully this is helpful to someone..... Joe

joe sellner