Fix “Sorry, this site hasn’t been shared with you.” Error in SharePoint 2013
Typically, if you don’t have access to a SharePoint 2013 site and access requests are not enabled, You get : “Sorry, this site hasn’t been shared with you” message when you try to access any SharePoint 2013 sites. Its a common issue and simply means that you have not been granted access to the site!
OK, How to solve this error?
Login to the site collection with either site collection administrator or Farm Admin (granted with “Full control” Web Application user policy!), grant appropriate access to the user in question by going to Site Settings >> People and Groups. Once you do this, users prompted for credentials instead of the Sorry, this site hasn’t been shared with you error.
To confirm this issue is specific to a particular user’s access rights, Try Login as a different user who has permission to the site already: https:/sharepoint-site-url/_layouts/closeConnection.aspx?loginasanotheruser=true
Still getting the same “Sorry, this site hasn’t been shared with you.”?
- Might be because of cached credentials from a prior browser session. Try 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 a different browser such as Firefox!
- 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.
- 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.
Stop:
stsadm -o provisionservice -action stop -servicetype spwebservice
iisreset /noforce
Start:
stsadm -o provisionservice -action start -servicetype spwebservice
iisreset /noforce - 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, You must change classic mode authentication to claims-based authentication (Convert-SPWebApplication or $WebApp.MigrateUsers($true))
- If you have a custom master page verify it’s published! Checked-out master pages could cause this issue. Try Check-in and make sure all resources such as CSS, Images, JS files are having at least read access to all authenticated users.
- 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!Â
- Try clearing the Distribution Cache, Do the IIS reset.
- 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 – Configure SharePoint 2013 Object Cache Super User, Super Reader Accounts , https://technet.microsoft.com/en-us/library/ff758656.aspx
Hi Team,
I could able to resolve this issue by adding correct user to the site collection administrator. For me, i have a user called spaadmin. when we login to adfs authentication window i used to type spaadmin@wwwww.com.
But when you adding the user , Please check on mouse hover in sitesettings adding site collection admnistrator , for this single user, i have 16 different names in site collection administration text area. like spa for email, spa for UPN, spa for ADFSGroup, spa admin, spaadmin. And finally i had added spaadmin@wwwww.com (UPN mouse hover) had resolved my issue.
Yes, [Stop and Start “Microsoft SharePoint Foundation Web Application” service from Central Admin >>Application Management >>Manage services on server], works for me. However, I took lots of time and I had to stop and start from Powershell commands but the issue resolved. Thanks a lot.
This work for me, many thanks for your help :).
Hi,
Most likely this is due to a corrupted user profile. It can also be in cases of account name changes, duplicate accounts for the same user etc.
If you review the ULS logs you will see access denied on the user profile picture library which is at the root of the mysite.
To resolve the issue
1. Make sure the service accounts have permissions on the user profile service application. This can be granted by highlighting the user profile service application in central admin and clicking administrators in the ribbon. Once there add the service account or the user account performing the operation under administrators groups.
2. Go to the user profile service application in central admin > Manage user profiles and search for the affected user profile.
3. In the user profile delete the entry “SPSITEERROR” under personal sites column and also remove the user profile picture.

save changes and try deleting the user profile again. Should work 🙂
AnonymousDecember 17, 2014 at 1:54 AM
Starting and stopping the web application service was the trick for me but that was a bit scary for a long while there. It deleted all of the IIS sites and took over an hour to stop before I used the STSADM command in PowerShell stsadm -o provisionservice -action stop -servicetype spwebservice. That stopped it and next an IISRESET/NOFORCE. Next another STSDAM command stsadm -o provisionservice -action start -servicetype spwebservice and another IISRESET/NOFORCE and everything is back to normal. My tip is be patient with the stopping and starting of that service it takes a very long time. Using the STSADM was much more effective than using Central Admin to do it. If you have a lot of IIS sites it will certainly take a very long time. I was in a Dev environment and so it wasn’t too big a deal. If this had been a production issue I would be crying right now. I still don’t know what actually caused this though. Does anyone know the root of the problem? I would love to ensure it doesn’t happen again.
Well, It works perfectly but when you add .Net user again the same error arises…had to follow the same steps again….:-)
Starting and stopping the web application service was the trick for me but that was a bit scary for a long while there. It deleted all of the IIS sites and took over an hour to stop before I used the STSADM command in PowerShell stsadm -o provisionservice -action stop -servicetype spwebservice. That stopped it and next an IISRESET/NOFORCE. Next another STSDAM command stsadm -o provisionservice -action start -servicetype spwebservice and another IISRESET/NOFORCE and everything is back to normal. My tip is be patient with the stopping and starting of that service it takes a very long time. Using the STSADM was much more effective than using Central Admin to do it. If you have a lot of IIS sites it will certainly take a very long time. I was in a Dev environment and so it wasn’t too big a deal. If this had been a production issue I would be crying right now. I still don’t know what actually caused this though. Does anyone know the root of the problem? I would love to ensure it doesn’t happen again.
For me it was the application pool “SecurityTokenServiceApplicationPool” that was running with a user account that had changed password in the AD. Once that was sorted it went smoothly. // Kristoffer