Recently had an issue with a SharePoint site where sometime over the weekend, the entire site broke and wouldn’t let anyone check files out of document libraries, upload new files, edit or create pages etc.

The Check Out option on files was completely missing. Options under Site Settings were completely missing. When users opened Word and Excel documents from document libraries and tried the Check Out option from there, they’d be repeatedly prompted for authentication. I spent a long time checking permissions within SharePoint, checking service accounts, using Wireshark etc but couldn’t find the cause.

Eventually I happened to noticed that the entire site was locked, in read-only mode. But how did it get like this? There’s only four administrators that can do this and no one logged in over the weekend and made any changes. I then happened to read that as of WSS 3.0/MOSS 2007 SP2, when using the backup option of stsadm, the site is automatically locked. Previous to SP2 it was only recommended that you did this. It’s now enforced.

The problem appears to be that if the backup fails for whatever reason, the site stays locked. To check if the site is locked:

stsadm -o getsitelock -url http://spsite

To unlock the site:

stsadm -o setsitelock -url http://spsite -lock none

If you read the Microsoft TechNet for the Setsitelock option for stsadm, you’ll notice that it does mention that the backup now locks the site. You can force the backup to not lock the site. I’ve modified our backup routine so that a setsitelock operation is always run after a backup, regardless if the backup was successful or not.