On Aug 24, 2011, at 5:52 PM, Joseph Tam wrote: > > A mail user reported that he filled up his INBOX (despite reminders he > was approaching his filesystem quota), and furthermore, he could not > fix the situation because he couldn't expunge message he marked for > deletion. > > The dovecot logs revealed the cause > > dovecot: imap(user): Error: open(/var/mail/user.lock) failed: > Disc quota exceeded > > This created an impasse where a user cannot free space because he needs > to create a lock file that cannot be created because he needs free > space. Is there any way out of this without administrator intervention? > In your mail_location you can specify a different control and index directory as a place where the user has no quotas. I'm not quite sure which it is (control or index) that says where the dotlock file goes but it should be one of them. Check out the mail_location page in the wiki for more info. This introduces more filesystem complexity (you need one tree for message files and another for mail control/index files) but it does mean that people can log in when they hit their quota and the storage space consumed by their dovecot indexes won't count against them, which I personally think is more fair than letting those things consume quota.
Also, as someone who was using dotlocks for a long time until I could make fcntl locks work over NFS to our Netapp filers, I would strongly recommend trying to move away from dotlocks if you can. We were seeing poor performance and some cache corruption (mail, indexes, control all on NFS with multiple hosts possibly accessing the same user's files) with dotlocks that went away when we switched to native locks. > Joseph Tam <jtam.h...@gmail.com> David Warden
