Recently we upgraded from SharePoint 2010 Foundation to SharePoint 2013 Standard/Enterprise. As with any upgrade there were some problems, but most were very minimal. This particular problem didn’t impact very many users, but was very frustrating.
We had a list that we wanted users to submit a request to, this list we provided the user “Edit” permissions to, but no permissions to the rest of the site. When the user would attempt to complete the form they would get two errors. One during the form entry and one upon submission.
Error 1: Sorry, we’re having trouble reaching the server
This error is received in the “People Picker” fields of the list form. When attempting to enter a username or display name the user continually receives this message.
Error 2: The server was unable to save the form at this time, Please try again
This error is received after completing the form and clicking the Save button
I started out as anyone does looking to Google (I even tried Bing) but all the articles I found that had a similar error message and scenario just didn’t solve the issue. Here some of the things I tried without success.
- Reload the .NET HTTP Activation
- Checked and re-checked Alternate Access Mappings.
- I even tried adding permissions so the users could at least get the People Picker field to successfully run a user query, but I stil couldn’t save.
- Backup/Restore of Site Collection to same location and different location
After all of that, I found the simplest of answers that just annoyed the crap out of me. I found that new site collections weren’t displaying the same issues so I decided I needed to start comparing the two. I started in the Site Collection Features menu and sure enough, there was my answer.
On the problem site collection I had the SharePoint Server Publishing Infrastructure feature Activated, which isn’t the cause of the problem directly, but it does by default enable the Limited-access user permission lockdown mode feature. Below is the description of the feature.
There isn’t a lot of documentation on this feature, but when you Deactivate the feature, the issue goes away. It makes sense though that the issue would occur based on the description. It seems this is a security feature for public facing publishing sites so you aren’t accidentally sharing more data with anonymous users than expected, the problem is other users who not using anonymous access but do not have permissions to the top level site will also not be able to edit. Viewing is not affected.
This took me way too much time to solve, and I wish Microsoft didn’t make the default behavior to enable this feature, but such is the case. I hope this helps someone else out there. Good luck.