--On August 24, 2010 1:22:53 PM -0400 Dave McMurtrie <dave64@xxxxxxxxxxxxxx> wrote: > On 08/24/2010 01:17 PM, Michael Bacon wrote: > >> >> Definitely something I hadn't thought of, but in this case, the faulty >> mbtype appears to be in the mailboxes.db on the backend server, not the >> mupdate server. I don't think an MUPDATE command would change that, >> would it? > > If your mupdate master still doesn't have a mailbox entry for the broken > user(s), but the backend server has it locally in mailboxes.db, you can > force a mupdate push from the backend first, then clear the reserved > state. > > To force the backend to do a mupdate push, use imtest: > > $ imtest -m GSSAPI your.cyrus.backend.com. > S: A01 OK Success (privacy protection) > Authenticated. > 1 MUPDATEPUSH user.testuser > 1 OK Completed > 2 logout > * BYE LOGOUT received > 2 OK Completed > Connection closed. The mupdate server is fine -- it has the mailbox on the right server, on the right partition, with the right mbtype (1, i.e. remote mailbox). The backend server is the one with the messed-up mailboxes database. It has the mailbox, but it has it with mbtype=2, which is "reserved." Any attempt to delete, change, or select the mailbox results in the error message, "Mailbox is currently reserved." My understanding of the matter is that when any backend cyrus process goes to do something on a mailbox such as add, delete, rename, or xfer, it puts the mailbox into reserved state (mbtype=2) in the local mailboxes database. When it finishes, it either sets the mailbox back to normal, or it removes the entry. The problem is, we had a state where some but not all writes to the *local* mailboxes database failed (not the mupdate server). As such, some mailboxes got put into the reserved state but never removed from it, and now I can't either take them out of that state or delete them (deleting them would be fine at this point). We got into this state by having three backend servers with bad file system permissions, so it's not as if cyrus got this way through normal operations. I just can't seem to undo it. From what I can tell, reconstruct and the various ctl_mboxlist commands will fix many errors, but they won't change the mbtype. -Michael ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html