none
Site Collection Unavailable after Inheriting Permissions in a slist in a subsite

    Question

  • The scenario is just as described in the following KB Article for MOSS2007 and WSS 3.0, http://support.microsoft.com/kb/935958, but I am having the issue in SP 2010. I can restore the content database for the site collection and duplicate the issue every time.

     

    Create a new list in a subsite of the site collection (http://sitecoll/subsite), as soon as the list is created open List Permissions.

     

    First problem: by default the list was created with unique permissions by the system

     

    Set the list to Inherit Permission from the Parent.

     

    Second problem: get an error that it "Cannot complete action..." and then the entire site collection is unavailable (HTTP 500).

     

    Cannot access /_layouts/..., cannot run PowerShell commands against the site collection, our SP Admin tool (third-party) shows the site collection in the navigation but has it greyed out as "locked".

    Curious if anyone else has seen this…

    Thanks

    Thursday, August 04, 2011 11:39 PM

All replies

  • Cannot access /_layouts/..., cannot run PowerShell commands against the site collection, our SP Admin tool (third-party) shows the site collection in the navigation but has it greyed out as "locked".

    You can unlock the site collection by logging onto CA as Farm admin, then Application Management > Site quotas and locks > select site collection and select status as "Not Locked"

    Or use Powershell to achieve the same

    Set-SPSite -Identity "<SiteCollection>" -LockState Unlock

    - Sid
    Friday, August 05, 2011 1:25 AM
  • Thanks. The site collection is not actually "locked" through the Site Quota and Lock feature. In fact, even when trying to browse there in CA, you cannot select the site site collection within the web application. It doesnt appear to exist, except that it is in the list under the web application when in "View all Site Collections", and when I select it on the left, there are no details on the right like you would normally see (primary admin, database, etc).

     

    Friday, August 05, 2011 2:35 AM
  • Hi Jim,

    Did you manage to fix the issue? I have got exactly the same issue in our production environment and was wondering if you could help.

     

    Kind Regards,

    Rakesh

    Thursday, August 11, 2011 1:38 AM
  • Not yet, we are still working with MS on the issue. Will post something once we have determined root cause.

     

    jim cason

    Thursday, August 11, 2011 3:07 AM
  • I'm having the same problem its realy strage. I believe Microsoft reproduced the same problem (as SharePoint 2007) again. Just a question: What is the version of your SharePoint. Have you installed the Service Pack 1 and the CU that is released after it? Do you have Project Server installed over it?
    Saturday, August 20, 2011 4:41 AM
  • Exactly the same thing here :-).

    Was the site collection you are having issues with created in SharePoint 2010 or was it migrated from 2007? I'm asking because recently we've migrated a WSS 3.0 portal to SharePoint 2010 Standard (content DB attach method). The migration went OK and everything was working until this morning when a list was created on one of the subsite and then it's permissions were changed.

    Now every page is showing HTTP 500, PowerShell console can access site collection, but gives error when accessing any of the sites and this site collection can not be selected in CA for any task.

    The error is System.Runtime.InteropServices.COMException (0x80004005) at Microsoft.SharePoint.Library.SPRequestInternalClass.OpenWebInternal...

    I'm thinking that maybe this error appeared because the content DB was migrated from the previous version of SharePoint.

     

    Thursday, August 25, 2011 3:08 PM
  • Ok, I've seem to understand the cause of the error in my case.

    As I said in the previous post, we were performing migration from WSS3 to SharePoint 2010 Standard for a customer. The customer asked us to merge sevceral site collections into one during migration - they had separate site collections for some of departments, but since the activity is low and there isn't a lot of data in this departments it was decided to make the subsites in the main site collection.

    We did as asked, but it seems that moving site collection to a subsite has some underwater stones we were not aware of.

    I've recreated the error by following these steps:

    1. Created a site collection http://contoso.com/siets/site1
    2. Created another site collection http://contoso.com/sites/site2
    3. Exported root site of Site 2 by executing the following in powershell:
      $web = Get-SPWeb http://contoso.com/sites/site2
      Export-SPWeb $web -Path C:\Import\site2.cmp -HaltOnError -IncludeUserSecurity -IncludeVersions All
    4. Imported root site Site 2 as a subsite of Site 1 by executing the following:
      $web = New-SPWeb http://contoso.com/sites/site1/site2 -Language 1049
      Import-SPWeb $web -Path C:\Import\site2.cmp -HaltOnError -IncludeUserSecurity -UpdateVersions Append
      
    5. Now when I created a new list in freshly imported subsite I wasn't inheriting permissions from Site 2 like it should've by deafult - on the page it was writtend that the list has unique permissions and the permissions it had matched those of Site 1 (root site in the site collection) not those of Site 2 - it'd direct parent.
    6. Clicked inherit permissions.
    7. Now when browsing to any place in the site collection I see an error - logs show that it is 0x80004005

    So, I looks like it has nothing to do with migration from WSS3/SP2007, but happened because the root site of one site collection was moved to a subsite of another site collection.

    For now I'm conducting research to understand where the error originated - is it because of the scripts we've used for migration (maybe some option was missed or has an invalid value?) or is because of some internal bug of SharePoint 2010.

    Is there someone who has successfully moved site collections to subsites? If someone could add some comments on this matter, I would be much appreciated.

    P.S.

    Oh, I've forgottent to mention - we migrated from WSS 3.0 SP2 (no additional hotfixes) to SharePoint 2010 without service pack. After installing service pack and repeating the abovementioned step the error happen again, so it it seems that service pack doesn't affect it.


    • Edited by millevi Sunday, August 28, 2011 1:44 PM Forgot the versions
    Sunday, August 28, 2011 1:41 PM
  • Hi millevi,

    were you able to find the root cause of this error... we would really appreciate any updates you may have on this...

     

    Thanks,

    Zubair

    Thursday, October 06, 2011 10:56 PM
  • Any update to this? I'm having this same issue...
    Monday, January 09, 2012 10:41 PM
  • I have a similiar problem. The unique difference is the site. In my case it happens only in a specific subsite. The rest of the site collection is working fine.

    Any new?

    Saturday, January 14, 2012 5:05 PM
  • Oh, so this problem still persists!

    I've managed to get around this problem although I haven't found out why this error has occurred.

    Back in August I've started a separate thread to describe this error and ways of getting around in detail, but it didn't have any replies beside my own :-)

    http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/330ee5ee-ddfe-4b44-9e4f-c566e6c04f7b


    • Edited by millevi Monday, January 16, 2012 2:33 PM
    Monday, January 16, 2012 2:28 PM
  • Did some more testing on this, and also spent a few hours with Microsoft support, helping them recreate the issue. Take a look-see here: http://ilyal-technology.posterous.com/naaasty-sharepoint-2010-bug.

    If you look at content db diffs, it looks like permissions and roles tables get fubarred when the set of steps leading to the problem is repeated. I found a way to restore access to the root site collection by editing the Perms table directly (i don't recommend this over a restore from a good backup, but everyone's situation is different), and while giving you access to the top-level site collection and web, this fix doesn't resolve problems getting to subsites (where you start getting 403 denied errors) . Resolving the latter, looks like, depends on getting RoleDefinitions table restored successfully, which is a hairier ball of wax since it starts dealing with ScopeIds and what-not (which change when you break inheritance). I still think that's possible, in a true emergency situation, with some elbow grease and SQL kung-fu.

    Monday, January 16, 2012 3:22 PM
  • Did some more testing on this, and also spent a few hours with Microsoft support, helping them recreate the issue. Take a look-see here:http://ilyal-technology.posterous.com/naaasty-sharepoint-2010-bug.

    If you look at content db diffs, it looks like permissions and roles tables get fubarred when the set of steps leading to the problem is repeated. I found a way to restore access to the root site collection by editing the Perms table directly (i don't recommend this over a restore from a good backup, but everyone's situation is different), and while giving you access to the top-level site collection and web, this fix doesn't resolve problems getting to subsites (where you start getting 403 denied errors) . Resolving the latter, looks like, depends on getting RoleDefinitions table restored successfully, which is a hairier ball of wax since it starts dealing with ScopeIds and what-not (which change when you break inheritance). I still think that's possible, in a true emergency situation, with some elbow grease and SQL kung-fu.

    Monday, January 16, 2012 3:23 PM
  • Incidentally, if you find yourself in a situation where you're encountering the environment described here but BEFORE you click on inherit permissions in the list and blow everything up, here's the fix to, uh, fix the problem on the afflicted webs:

    1. Go up to the web's Permissions area
    2. Click on Inherit Permissions to remove unique permissions from the web
    3. Click on Stop Inheriting Permissions to re-break role inheritance (if you do it via UI, the bug does not appear)
    4. Set groups/users as you need them

    you may choose to verify, between step 2 and 3, that your lists that used to have unique permissions (as part of the symptom of the problem) now have inherited permissions. After doing this, the problem goes away and you can safely create new lists.

    Monday, January 16, 2012 3:56 PM
  • I have the same problem with a lot of subsites and I only have a backup with five days. Is too risky doing this kind of SQL kung fu? :p

     

    Monday, January 16, 2012 4:13 PM
  • I suggest you do a full backup of all content databases before you dive in to SQL directly. If this is a critical site-down situation, and it sounds as though it is, and you have a Microsoft support agreement or $300, you can get priority support from them to try to get it resolved...
    Monday, January 16, 2012 4:33 PM
  • I found the diferences. On table Perms is missing a row refering my parent site. I'm assuming if I insert that row manually I am able to get the site back. Should I do a backup from all content databases or just of this site collection?

    Monday, January 16, 2012 4:50 PM
  • You should back up whatever database you plan to modify directly. I think that this should only be done to retrieve documents /items created after your last backup, since the act of modifying the database will make your installation unsupported by Microsoft, which means that future issues will not get support. My suggestion is to back up the database prior to changes, make the change, retrieve the documents, restore DB from last backup, get the documents back in, and work with Microsoft to get a fix (which probably doesn't exist yet).

    Also, after you restore the DB, see my manual resolution of the pre-conditions for this problem. Note that the only step that must be performed manually is the breaking of inheritance; everything else can be scripted, which may help, if you have tons of subsites in the affected site collection...

    Also, modifying Perms table will give you access to the root site, not the sub-webs, which will likely give you 403 Access Denied error. To get to those, you'll need the SQL+SharePoint kung-fu skills i mentioned earlier.

    Monday, January 16, 2012 5:00 PM
  • First of all, I want to thank you a lot. I just insert one row (about Parent Site) and everything gots fine. Without your help i couldn't do nothing. Now, I will recover all documents, calendar entries, etc and I will do as you suggested.

    My powershell  scripts will have some commented lines..

    Thank you Ilya. You saved my day.

     

     

    Monday, January 16, 2012 5:30 PM
  • Same issue, but we are use the powershell export import to "clone" a subsite in a site collection.  If I click on inherit, or break permissions on a list which is inheriting, on the new site it's bye bye site collection.

     

    Tuesday, January 31, 2012 9:15 PM
  • I need to warn everyone that editing any SharePoint database directly in SQL will render your environment into an unsupported state. This action should never be taken without express permission from Microsoft, and the SharePoint product group. Manually modifying any values in SQL can render your environment unstable, and cause more problems down the line.

    If you are having a problem that you believe editing the SQL databases will resolve, you should always contact Microsoft Support before taking that action.

    Thanks,

    ScottC - Microsoft SharePoint Support

    Wednesday, April 11, 2012 3:00 PM
  • Did Microsoft ever give you a final resolution for this issue?  This is occurring on my environments and I'd like to know if they fixed this in a CU...

    Thanks!

    Monday, June 18, 2012 5:36 PM
  • Is there any update or hotfix for this issue? I have same problem without any solution!

    Sunday, September 30, 2012 5:27 AM