Sharepoint BreakRoleInheritance

Question

 

Hi,

i get an exception when i call BreakRoleInheritance(false) on a SPWeb object.

it says: Cannot complete this action.  Please try again.

 

BreakRoleInheritance(true) does not work either, or setting Allowunsafeupdates=true.

 

does anybody have any ideas?

Answer 1

have a look on this KB article http://support.microsoft.com/kb/932056/

this might solve your problem.

Answer 2

I have sp1 installed, which should have taken care of that problem.

So is this not another problem?

Answer 3

Reason for the Problem is,

 

If we instantiate two separate SPWeb objects for single site, it will throw “Cannot complete this action.  Please try again” error. So ensure that single web object is currently in use.

 

Answer 4

Sorry, that is not a solution to my problem.

I tried to create security on the web on the web interface. When I pressed "Actions->Edit Permissions", the same exception came:

Cannot complete this action.

Please try again.   at Microsoft.SharePoint.Library.SPRequestInternalClass.ResetSecurityScope(String bstrUrl, UInt32 dwObjectType, String bstrObjUrl, Guid guidDoc, Boolean bUnique, Boolean bCopyRoleAssignments, Guid& pguidScopeId, Int32& piError)
   at Microsoft.SharePoint.Library.SPRequest.ResetSecurityScope(String bstrUrl, UInt32 dwObjectType, String bstrObjUrl, Guid guidDoc, Boolean bUnique, Boolean bCopyRoleAssignments, Guid& pguidScopeId, Int32& piError)

 

 

The web that i am working on was imported using the migration API. It is a subweb from the actual web that i imported.

I want to set the permissons on the subweb, but I always get this error...

 

Answer 5

Hi,

 

I'm facing the same issue for some of the sites I migrated using a 3rd party tool. Did you find any solutions / workarounds for this problem?

 

Thanks,

Prabin.

Answer 6

I was trying to do the same thing from Code/UI and got similar exception message. However I was able to break inheritance from UI by navigating to the permissions page directly by appending "_layouts/role.aspx" to the URL and break permissions there.

Answer 7

Thanks a lot. I had a same problem, I was able to break the inheritance from role.aspx page. Afterwards, I had no problem breaking / inheriting permissions. It seemed like permissions got corrupted during the custom development.

I also had a problem that site did not automatically redirect to default.aspx page and the problem was also resolved after I tried what you suggested.

 

Thank you so much again!!!

Answer 8

 

We began experiencing issues with users getting HTTP 500 errors on sub-site homepages for a particular site collection. Some research came up with a very similar condition under http://support.microsoft.com/kb/937038

The KB describes the following scenario:

1)       You create a site that is named Site A. Site A inherits permissions from the parent site. Then, you configure Site A to stop inheriting permissions.

2)      Under Site A, you create a sub-site that is named Site B. Site B inherits permissions from the parent site. Then, you configure Site B to stop inheriting permissions.

3)      You configure Site A to inherit permissions from the top-level site.

4)      You create a document library in Site B, and then you configure the document library to inherit permissions from Site B.

We could not apply the hotfix because we already had MOSS SP1 installed which should have included this roll-up. MS support indicated that there was a newer post SP1 fix in office-kb952294-fullfile-x86-glb but this did not work. Finally we were told this was a documented bug currently in development and there was not ETA for the hotfix.

Our situation was slightly different, but we finally came up with a work-around I hope this helps!

Our Scenario:

1) We created site A, does not inherit permissions from parent site
2) Under site A we create sub-site B which inherits permissions from parent site A
3) We configured site B to copy permissions from parent A and stop inheriting.
4) We configured site A to inherit permissions from the top level parent site.

This last step (4) forced inheritance down to all sub-sites of Site A, even though the sub-sites (i.e. Site B) were set to not inherit permissions.

Once this occurred, users could no longer access the default home pages of the sub-sites. Instead they got the HTTP 500 error but you could directly path to default.aspx successfully (no links or breadcrumbs would work though). You could also no longer directly remove inheritance via the sub site's advanced permissions. When trying to remove inheritance, we would get the RoleInheritance error:

Cannot complete this action.

Please try again.   at Microsoft.SharePoint.Library.SPRequestInternalClass.ResetSecurityScope(String bstrUrl, UInt32 dwObjectType, String bstrObjUrl, Guid guidDoc, Boolean bUnique, Boolean bCopyRoleAssignments, Guid& pguidScopeId, Int32& piError)

   at Microsoft.SharePoint.Library.SPRequest.ResetSecurityScope(String bstrUrl, UInt32 dwObjectType, String bstrObjUrl, Guid guidDoc, Boolean bUnique, Boolean bCopyRoleAssignments, Guid& pguidScopeId, Int32& piError)"

After many hours we came up with the following workaround which was sparked by Raja Ayyapusetty’s post at http://forums.msdn.microsoft.com/en-US/sharepointdevelopment/thread/44533e5a-18d7-434f-b153-88a643b8d1e2/ as well as inspecting the content database dbo.Roles table. One single sub-site (Site C) was actually working properly and we determined it was configured to inherit permissions from day one and was thus not affected by the propagation. By looking at the difference between this working site and sites like "Site B" above, we found that Site C has no entries and came up with the following procedure to fix the issue. I know that some steps seem redundant, but for some reason, this is the only flow that would work for us. (we decided we would try to come up with a work-around and could not restore from SQL back-up as too much content had been involved over a 48 hour period.)

1)      For each Child site getting HTTP 500 internal server error

a.       Access the Fully path to the default.aspx homepage of the child site

<parent URL>/<sub-site>/default.aspx

 

2)      Once successfully loaded, Go to Site Actions > Site Settings

a.       Under Users and Permissions select Advanced Permissions

b.      Change URL from _layouts/user.aspx  to _layouts/role.aspx to break inheritance. You will end up on permissions levels page.

3)      Click on Edit Permission Levels link, you will see that the permission inheritance is broken (checkboxes show up next to permission levels).

4)      Again, Go to Site Actions > Site Settings

a.       Under Users and Permissions select Advanced Permissions

b.      Just ensure inheritance is broken, i.e. checkboxes show next to the user objects

5)      Back to Site Actions > Site Settings

c.       Under Users and Permissions select Advanced Permissions

d.      Under Settings Menu, select permission levels

e.      Click Inherit permission levels from Parent Website, (I know the looks like we’re undoing what we just did (we are), but we found that this has to happen in this order to inherit the permission levels first, then we go on to un-inherit permissions themselves)

f.        Ensure permission level are again inherited  (checkboxes should be gone.)

 

6)      Go back to Site Actions > Site Settings

g.       Under Users and Permissions select Advanced Permissions

h.      Under Actions Menu, select Edit Permissions, you will no longer get the BreakRoleInheritance error and it actually works.

i.         Ensure permission inheritance is broken (checkboxes appear next to user objects again)

Yuo will probably have a lot of sub-site permission clean-up to do, but at least users are now able to go back to their sites.

Windows Server 2003 SP2
MOSS 2007 SP1
Single Server Farm with separate SQL Server 2005 DB

No 3rd party back-up implemented, we rely on our SQL backup.

The End

---

Jeremy Marut

Answer 9

I just wanted to say thank you so much, this really made my day!  I was having the same problems, basically.  I could not backup the problematic sub-sites in Sharepoint Designer without getting the "Error occurred while exporting the web https://<yoursite>. There is no row at position 0." message. Another problem I was having was getting an error page that said "Cannot open "": no such file or folder." We were gettins some other odd behaviors with the site, too, Breaking inheritance from the permission levels page, re-enabling permissions level inheritance and THEN breaking permissions (not permission-level) inheritance worked like a charm!  I'm just mad at myself for not figuring it out first :-P  No more HTTP 500 errors, and I can see my previously problematic sub-sites in Sharepoint Designer from their parent sites again!

---------------
Sean Frye

Answer 10

Thanks Jeremy for that.  Our problem was that we had a portal site with 4 sub-sites and just one of the subsites was giving us the HTTP500 error when we used the non-full URL (e.g. http://intranet/gc/gd rather than http://intranet/gc/gd/pages/default.aspx). Of course the breadcrumbs automatically use the shorter URL, so this was causing some annoyance amongst the users.

Answer 11

Thanks so much. You made my day too. I am able to browse the link without adding default.aspx and can manage permissions

---

MCP, MCTS

Answer 12

Thanks, that's sorted it for me!

Answer 13

Hi  JohnyG,

this problem comes due to in sufficent privileges in that web, 

Try this link this may help u

http://aaclage.blogspot.in/2008/04/access-denied-run-with-elevated.html