I’ve recently come across an interesting issue regarding anonymous permission setting problem on custom lists.

Symptoms:

1. Enable anonymous access on the web application’s authentication provider.
2. Enable anonymous settings on the site collection.
3. Create a custom list, set unique permissions, enable “add items” and “edit items” for anonymous users.
4. Press Ok.
5. Open the page again, and the setting is not saved (only view items is selected)

Troubleshooting:

The list’s anonymous permission mask property shows correct permission mask:

[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$site = new-object Microsoft.SharePoint.SPSite("http://bobmoss32:9000")
$web=$site.OpenWeb();
$list=$web.Lists["anonlist"]
$list.AnonymousPermMask64
ViewListItems, AddListItems, EditListItems, OpenItems, ViewVersions, ViewFormPages, Open, UseClientIntegration, UseRemoteAPIs

This confirms that the settings were saved to the content database.

So what can override this mask? Well, it is called Web Application polices in Central Administration.

Solution:

If you have any users defined for Deny Write, Deny Full (or any custom policy removing add or edit items permissions) that will also apply for the anonymous user as well. If you scope the policy for a single zone only, the other zones will not be affected. This behavior is by design according to the product group and cannot be changed.

If you think about it, this makes sense, you declared that a user or group of users cannot write to web application. If that user is opening the site as anonymous, how can you guarantee that he/she does not write to it?
Yes, you cannot allow anonymous writes, since you have to be sure that the anonymous user is not the one you forbid.

So if you need to allow for anonymous users to edit list items you need to remove all Deny policies for that zone and for any assigned to “all zones”.