SharePoint Site Not Accessible

Overview Story

Created brand new SharePoint Teams site.

Enabled Publishing Feature.

Created Access groups, Nest User in Group.

 

Troubleshooting

First Source Disable Access request feature. This feature was enabled, disable it, Result….

Second Source far more thing to try.

1. Cache, not the case same issue from any browser and client machine.
2. *PROCEED WITH CAUTION* Stop and Start “Microsoft SharePoint Foundation Web Application” service from Central Admin >>Application Management >>Manage services on server. In case, you face issues, use STSADM command line.cd “c:\program files\common files\microsoft shared\Web Server Extentions\16\BIN”Stop:
   stsadm -o provisionservice -action stop -servicetype spwebservice
   [Time taken ~30min not sure went for a break since it was taking so long]
   iisreset /noforce [!1min]
   Start:
   stsadm -o provisionservice -action start -servicetype spwebservice
   [Roughly 15 min]
   iisreset /noforce

Result, SharePoint completely broken, Central Admin is accessible, but all sites are in a non working state. I cannot recommend to try this fix, but if you have to ensure you are doing so either in a test environment or have a backup plan.

I managed to resolve the issue in my test environment, as it turned out the sites were all defined to be HTTPS, however the binding was done manually on IIS to certs created, and then the AAMs updated on CA. Sources one and two

Running these commands SharePoint is not aware to recreate the HTTPS bindings so this has to be done manually.

Result:

Ughhhhhhhhhhhh!

3.If are migrated from SharePoint 2010, or backup-restore/import-exported: If your source site collection is in classic windows authentication mode and the target is in claims authentication

Not the case, but tried it anayway, and results…

This is really starting to bug me…

4.If you have a custom master page verify it’s published! Checked-out master pages could cause this issue.

We did make changes to the master page to resolve some UI issues, but this had to be published to even have those changes show, so YES, no change in result.

5.If you have this feature enabled: “Limited-access user permission lockdown mode” at site collection level – Deactivate it. – Because, this prevents limited access users from getting Form pages!

Found this, deactivated it and….

Ughhhhh….

6.On publishing sites: Make sure you set the cache accounts: Super User & Reader to a domain account for the SharePoint 2013 Web Application with appropriate rights.

I’ve read this from a different source as well however none of my other sites that are teams sites with publishing enabled have these extra properties defined and they are working without issue, I decided to try anyway,

Result:

7. If you didn’t run the 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.

Let’s give it a whirl… Now I pushed this down from #2 as it’s pretty rough like the suggestion I put as #2, which I should probably shift down for the same risk reasons, but I did try this before the other ones and it like the stsadm commands it broke my ShaerPoint Sites, it stated errors about features defined in the content database of attached sites that the features were not installed on the front end server.

In this case I tried to run my scripts I had written to fix these types of issues (publishing of script pending), but it wouldn’t accept the site URL stating it was not a site collection, it was at this point running get-spsite returned an error…

and sure enough…

AHHHHHHHHHHHH!!!!!!!!!

I asked my colleague for help since he seems to be good at solving issue when I feel I’ve tried everything. He noted the master pages and layouts area had unique permissions, setting it to inherit from parent made the pages finally load. But is this normal? I found someone asking about the permissions here, apparently it shouldn’t be inherited and they list the default permission sets:

Yes, Master Page Gallery use unique permissions by default.
Here is the default permissions for your information:
Approvers SharePoint Group Approvers Read
Designers SharePoint Group Designers Design
Hierarchy Managers SharePoint Group Hierarchy Managers Read
Restricted Readers SharePoint Group Restricted Readers Restricted Read
Style Resource Readers SharePoint Group Style Resource Readers Read
System Account User SHAREPOINT\system Full Control

Setting there defaults I still got the page was not shared problem, for some reason it works when I set the library to inherit permissions from the parent site.

When checking other sites I was intrigued when there was only the Style Resource Readers defined. I found this blog on a similar issue when sub site inheritance is broken which interesting enough directly mentions this group.

“It occurs when the built-in SharePoint group “Style Resource Readers” has been messed with in some way.”

Will check this out.

So I went through his entire validation process for that group, it all checked out, however as soon as I broke inheritance on the master page library, made it the “known defaults” and verified all Style Resources users were correct and all permission for it on all listed libraries and lists all match,  I continued to receive Site not shared with you error.

I don’t feel the fix I found is correct, but I can’t find any other cause, or solution at this time. I hope this blog post helps someone, but I’m sad to say I wasn’t able to determine the root cause nor the proper solution.