Resolving "Site Not Shared" Error During Search In SharePoint

In this article, you will learn how to resolve "Site Not Shared" error during site search in SharePoint.

Alright! I’ve had a pretty tedious week with SharePoint search when all of a sudden, the “SharePoint Enterprise search “ site collection started throwing an error stating “ Sorry this site hasn’t been shared with you “, as shown in the image below .

Every time any user made an attempt to execute a search query on the search box in SharePoint site, they got this annoying error and it was the same for everyone. I tried accessing the Search Center using the farm account and it still threw the same error. So in this article, I will be talking about what this error is all about, what are the troubleshooting steps we did to fix, and how we finally managed to fix it.

Initial troubleshooting steps performed to fix this issue

Since this was on PROD and we had a lot of users impacted by this issue, we initially decided to create a new Search Center site collection under a different web application so that for the time being, users can live with that, meaning we initially had the “SharePoint Enterprise Search Center “ URL configured and running under web application A and after we encountered this issue, we removed that and created a new Enterprise Search Center Site Collection under web application B so that we can figure out what’s wrong with the previous search center without having any business impacted. The image below should help you understand what I’m talking about.

After making the change here, please go ahead and update the new Search Center URL in site settings, as shown in the image below.

So, after doing that, we did the below mentioned steps in a sequential manner as suggested in some forums to get rid of the issue.

  1. We thought of clearing IE cache.

    Open a new browser window >> Go to Internet options >> In the general tab, click the "Delete" button - Make sure that passwords and temporary internet files are selected. Try different browsers, such as Firefox! ( But doing this wouldn’t make sense in our scenario as the issue was only limited to one site collection in the entire farm. However, we tried this but it didn’t help).

  2. If you didn't run product and configuration wizard after installation/patch, you may get this error even if you are a site collection administrator. Run it once and get rid of this issue. ( Even this was not quite convincing as the issue was just with one site collection, i.e. SharePoint enterprise search, in the farm).

  3. Stop and start "Microsoft SharePoint Foundation Web Application" service from Central Admin >> Application Management >> Manage Services on server ( We did try this as well bearing the risk of losing all the sites for quite some time but even that didn’t help. For those who are not aware of what this step does, it stops and recreates the SharePoint web application sites in IIS ).

  4. If the SharePoint farm was migrated from SharePoint 2010, or backup-restore/import-exported.

    If your source site collection is in classic Windows Authentication mode and target is in claims authentication, you must change classic mode authentication to claims-based authentication. (This was not applicable in our case as the sites were working perfectly fine for years after the migration )

  5. Try cleaning the distribution cache. Perform the IIS reset (We did this and it didn’t help either).
  1. We also verified whether “NT Authority\Authenticated users” group has enough permissions on the search center and it was positive.

  2. Of course, we also checked the site collection administrators for the “SharePoint Enterprise Search site collection “and it was perfectly fine.

  3. We also took a look at all the Search Service applications in SharePoint 2013 to verify the settings and they were pretty good.

Also, let me tell you that the issue was reported to us the second time within a month. The first time, it was with a different site collection on the same web application and this time, it was on the SharePoint Search Center site collection that’s under the same web application. When it was reported the first time, we just did an app pool recycle and also checked out and checked in the master page; to our surprise, that fixed it. But this time, nothing was accessible in the Search Center site collection.

So finally, without many steps left to do, we decided to open a Sev A case with Microsoft and started working with them on this issue.

Listed below is what MS did to fix the issue

  1. I shared the ULS logs as well as fiddler logs with the MS engineer by reproducing the error, and after reviewing the logs, he was able to identity that the “super user “ and “super reader “ accounts that take care of object cache got corrupted in our environment and lead to this outage .

What’s the super user and super reader account?

The below mentioned link should give you a detailed explanation on the super user and super reader account. It’s very important that any SharePoint environment should have these accounts configured properly for optimal performance and it’s mostly utilized by sites which have the publishing feature enabled.

Ideally, the Portal Super User account must be an account that has Full Control access to the web application and the Portal Super Reader account must be an account that has Full Read access to the web application.

Also, you need to make sure that these accounts are discrete and they should never be used to login to the site, as mentioned in the TechNet article that I highlighted above.

But in our scenario, it’s exactly that part which was wrong. The “super user” and “super reader” accounts were the farm administrator service accounts and we often use these accounts for accessing the sites .This was configured mistakenly when the farm was initially configured and it eventually got corrupted which lead to this outage. However, we were not able to identify how it got corrupted all of a sudden and how it managed to run safely for all these years (might be one of those SharePoint mysteries). So, we went ahead and changed that account and updated that for all the web applications in the farm using the below mentioned PowerShell command

  1. $wa = Get-SPWebApplication -Identity "<WebApplication>"  
  2. $wa.Properties["portalsuperuseraccount"] = "<SuperUser>"  
  3. $wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"  
  4. $wa.Update()  

Lessons learned

Please ensure that your SharePoint farm has the “super user” and “super reader” configured correctly for optimal performance and do check and ensure that they are discrete and those accounts are not being used to access SharePoint sites. If by any chance you’re facing this issue for a different site collection and not for SharePoint search, the steps which I discussed above would still remain the same except for the “SharePoint search” part.

Also, once you’re done reading this post, please ensure that you take a closer look at your web application properties and ensure that these accounts are configured correctly so that you don’t end up seeing surprises like me.

Thanks for reading this post. I hope this solution will help you fix this issue if you happen to come across it, in your environment.