Open Bug 749529 Opened 12 years ago Updated 2 years ago

Thunderbird failing with "mailbox selected READ-ONLY" since Zimbra upgrade

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect

Tracking

(Not tracked)

People

(Reporter: dustin, Unassigned)

References

Details

Attachments

(2 files)

Debug log of Thunderbird
1.43 MB, text/plain
Details
zimbra imap trace log
1.39 MB, text/plain
Details 
This very well may be a Thunderbird bug, but it's been happening a few times a day since the Zimbra upgrade, so the timing is suspicious.  When I try to delete or move a message from my inbox, I get a dialog box saying:

"The current operation on 'Inbox' did not succeed. The mail server for account dustin@mozilla.com responded: mailbox selected READ-ONLY."

Other mailboxes work fine, though.  Restarting Thunderbird fixes the problem.  My mailbox can be modified via the Zimbra UI while this error is occurring in Thunderbird.

Unless anyone has ideas as to how this might be server-related, I'll bump this over to the Thunderbird queue.
What version of Thunderbird are you running?  I've been seeing this, too, but the correlation for me was when Earlybird got bumped to v14.
I was runnning 11 at the time, and was updated to 12 last night, so we'll see if it continues.
Just happened again on 12.0.1
Happened to me a few times intermittently today. Most recently just now. 

fwiw, I've been running TB12.0.1 since it came out 30apr.
Well, the message is obviously coming from the server. In a correctly functioning server, this would only happen if the client was using the IMAP Examine command (I'm assuming that's what Zimbra means by "selected READ-ONLY", as opposed to being a READ-ONLY folder). The problem is that Thunderbird doesn't ever use the EXAMINE command. So somehow Zimbra has gotten confused about the folder select state. Shutting down TB means that we have to reselect the folder, which clears up the confusion. Toggling the offline state back and forth should have the same effect. 

I probably shouldn't hazard a guess as to what's going on with Zimbra, but I wonder if you're connecting with some other app/device that *is* using the Examine command on the same folder and that's causing confusion. Either that or using the web interface is causing an issue.
In my case, the only device connected (as far as I know) is my laptop.

Perhaps notable is that this only seems to happen for the Inbox. Right now I'm experiencing it over and over for that, but other folders still function correctly.
I do have other devices connecting to my mail (two Android devices), and occasionally use the Zimbra UI as well (from my laptop).  This happens about once a day for me.
There's a Zeus proxy in front of this (which is new with the move from sjc1 to phx1).  I wonder of the Zeus is doing something funky...
1) This happened to me again just now. Restarting TB gets me back to working again.

2) I have TB to also handle mail for other non-mozilla mail accounts; these other accounts never hit this problem.
The zeus proxy had a 1 hour idle timeout on IMAP connections.  In theory this means the connection would be dropped if there's been no traffic in an hour.  Also in theory if that's actually what happened, Thunderbird should deal with it better than that (as in actually realize that the connection has been reset and restart it).

I removed that timeout just as a test, about 4 hours ago, and since I've done that, I've not had this error come up again so far.  I'll leave it overnight to see.
"The current operation on 'Inbox' did not succeed. The mail server for account joduinn@mozilla.com responded: mailbox selected READ-ONLY."

Hit this problem twice today. Each time, restarting Thunderbird "fixed" it.
(In reply to John O'Duinn [:joduinn] from comment #12)
> "The current operation on 'Inbox' did not succeed. The mail server for
> account joduinn@mozilla.com responded: mailbox selected READ-ONLY."
> 
> Hit this problem twice today. Each time, restarting Thunderbird "fixed" it.

did you try toggling the offline state instead of restarting?
Assignee: server-ops → server-ops-infra
Component: Server Operations → Server Operations: Infrastructure
QA Contact: phong → jdow
This is still occurring for me - once yesterday, once today.  I hadn't been idle for long - maybe 10m.
I've just had this as well. I think I had it once a few weeks ago also.
I've now run into this twice on my *personal account* on Dreamhost which is not using mail.mozilla.com.  

With that in mind I'm going to have to assume this is a recent bug in Thunderbird rather than a bug in our Zimbra.

Switching to offline mode and back online fixes it every time.
Assignee: server-ops-infra → nobody
Component: Server Operations: Infrastructure → Networking: IMAP
Product: mozilla.org → MailNews Core
QA Contact: jdow → networking.imap
Version: other → 14
Version: 14 → 12
I use dreamhost all the time, and have never seen this. I also use mozilla.com all the time, and haven't seen it either. Thunderbird doesn't have any code to open folders read-only, so this would seem to be a decision made by the server, perhaps because there are already open connections on the folder in question.
I have an IMAP debug log accumulating.  Next time it happens I should have something to share.
(In reply to David :Bienvenu from comment #17)
> perhaps because there are already open connections on the folder in question.

This seems plausible, and I thought perhaps it was being caused by my continually connecting and disconnecting from various VPNs at Mozilla (two of which actually reroute mail.mozilla.com) and a vpn at home that reroutes everything.

Been connecting and disconnecting from those at random the last half hour or so and haven't been able to replicate yet though, so maybe that's a red herring.
(In reply to David :Bienvenu from comment #13)
> (In reply to John O'Duinn [:joduinn] from comment #12)
> > "The current operation on 'Inbox' did not succeed. The mail server for
> > account joduinn@mozilla.com responded: mailbox selected READ-ONLY."
> > 
> > Hit this problem twice today. Each time, restarting Thunderbird "fixed" it.
> 
> did you try toggling the offline state instead of restarting?

Just hit this READ-ONLY error again. As experiment, I tried toggling offline/online, but when I toggled back online, I hit a different "this mailbox already in use" error. I then had to restart TB to get back to workable state.

Reading some other comments here, I note that I had build-vpn enabled all day. Also, I note that I just came back from long period of idle, and hit this as soon as I started to use TB.
I've been running with the NSPR IMAP log active for 3 days now and have yet to hit this since enabling the debug logging. :| Before I was hitting it once a day or so.  Figures.  I'll keep the log running until I hit it again.
FYI, been hitting this more in the last week (against mail.mozilla.com).  No logs, sorry.
I've been seeing the same issues described since upgrading to Zimbra 7.2 OSE.  I'm running Thunderbird 12.0.1/Mac OS X. 

There are 4 accounts (same server) that are configured in Thunderbird.  Although I only tested 1 account during logging, all 4 accounts have shown the same symptoms at the same time, not being able to delete from the INBOX while all other operations work.  

The primary account is funkknight. This account is accessed by an android phone and an iPhone in addition to thunderbird.  While Thunderbird was showing the problems, both phones worked correctly.

I'm the only user on the server, so if you want to see the zimbra logs as well let me know.


In the attached log you will see a "lopsa" email going into the INBOX. That was my testing of the issue:

- I moved an existing email to the INBOX which worked
- I tried moving it back to it's original folder. The copy happened, but I was given the error when it tried removing it from the INBOX
- Repeated the above steps again
- Tried deleting from the INBOX. failed.
- Tried moving to Trash, failed.
(In reply to Dave Miller [:justdave] from comment #19)
> (In reply to David :Bienvenu from comment #17)
> > perhaps because there are already open connections on the folder in question.
> 
> This seems plausible, and I thought perhaps it was being caused by my
> continually connecting and disconnecting from various VPNs at Mozilla (two
> of which actually reroute mail.mozilla.com) and a vpn at home that reroutes
> everything.
> 
> Been connecting and disconnecting from those at random the last half hour or
> so and haven't been able to replicate yet though, so maybe that's a red
> herring.

I have a VPN client running as well, however thunderbird has been restarted a few times while it was active and still repeated the same problem.
Damion, the log shows that the selected state is read-write, and storing flags works for a while, until it stops working. Immediately before it failed, you copied a message from an other folder into the inbox, while the inbox was in the idle state. You might try that again and see if that triggers the bug.
Following is a web page found by Google search for "mailbox selected READ-ONLY".
In that web page, a workaround is shown.
> A possible workaround is to insert an UNSELECT command between the EXAMINE at Q3 and the SELECT at Q4.

UNSELECT : http://tools.ietf.org/html/rfc3691
EXAMINE  : http://tools.ietf.org/html/rfc3501#section-6.3.2
> 6.3.2. EXAMINE Command
>(snip) 
>       The EXAMINE command is identical to SELECT and returns the same
>       output; however, the selected mailbox is identified as read-only.
>       No changes to the permanent state of the mailbox, including
>       per-user state, are permitted; in particular, EXAMINE MUST NOT
>       cause messages to lose the \Recent flag.

If "NO ... READ-ONLY" response is due to EXAMINE by other IMAP client(it's never by Tb, as David says Tb never uses EXAMINE), as for behaviour after EXAMINE command, recent Zimbra looks to work well according to IMAP related RFCs.

Dustin J. Mitchell(bug opener), do you concurrently access same IMAP account's Mbox from other IMAP clients?
TB can't use a connection from an other client, so it shouldn't matter if some other client is using an EXAMINE command, unless the server is really confused. It seems more likely that the server downgraded our connection somehow.

I only use k-9 mail. I wonder if there is some other triggering mobile client causing this, e.g., the iPhone mail client?
Yes, I use two Android devices.
Oh, sorry, you said next already in comment #8.
> I do have other devices connecting to my mail (two Android devices),
> and occasionally use the Zimbra UI as well (from my laptop).

http://tools.ietf.org/html/rfc4466#section-2.1
> 2.1. Optional Parameters with the SELECT/EXAMINE Commands
>    This document adds the ability to include one or more parameters with
>    the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
>    of [IMAP4]) commands, to turn on or off certain standard behaviors,
>    or to add new optional behaviors required for a particular extension.
> 
>    There are two possible modes of operation:
>    o  A global state change where a single use of the optional parameter
>       will affect the session state from that time on, irrespective of
>       subsequent SELECT/EXAMINE commands.
>    o  A per-mailbox state change that will affect the session only for
>       the duration of the new selected state.  A subsequent
>       SELECT/EXAMINE without the optional parameter will cancel its
>       effect for the newly selected mailbox.

Android is made by Google, so EXAMINE and/or relatively new rfc4466 may be used by IMAP client on Android device.
Can you obtain IMAP server side log for access from Android device or other IMAP client than Tb?
I hope that language means that can issue a SELECT while in the selected state to turn off state, not that other SELECTS from other clients will inherit that state :-)
I'm not the best person to experiment with: I'm not using Tb at the moment, and I'll be travelling for a few weeks and the Android devices will likely not be accessing Zimbra.
I managed to trigger this again last night finally (after 4 days of running TB in NSPR IMAP debug mode).  The logfile containing the errors is 4.3 GB.  I'm sure you only need the tail end of it surrounding the errors.

It does appear to contain the text of emails downloaded during that time, not sure how much I need to sanitize...

I do run with IMAP on two Android devices (K-9 in both cases) on this same account concurrently with Thunderbird, fwiw.
David :Bienvenu, I also want to believe that EXAMINE is limited to a session only.
However, following is meaningless on \Recent flag, if an IMAP client issues EXAMINE and other IMAP clients request SELECT, unless "per session flag/keyword status" is fully implemented without any inconsistency.
> EXAMINE MUST NOT cause messages to lose the \Recent flag.
If other mail client selected/fetched, what \Recent status should be shown to IMAP client who requested EXAMINE?

I think "temporary READ-ONLY status at Mbox level by EXAMINE" can be an easy/simple/natural implementation as EXAMINE support. If concurrent access from multiple IMAP clients is not cared for, this is sufficient. I'm suspecting this kind of issue.
(In reply to Dave Miller [:justdave] from comment #32)
> I do run with IMAP on two Android devices (K-9 in both cases) on this same
> account concurrently with Thunderbird,

If K-9 on Android, it looks that K-9 side log can be obtained.
> http://code.google.com/p/k9mail/issues/detail?id=3677#c6
EXAMINE command looks used by K-9.
> Following web page is pointed by the problem report.
> https://github.com/k9mail/k-9/wiki/LoggingErrors
FYI.
Following is a web page for similar phenomenon with offlineimap, although it seems "EXAMINE by himself" case. (sorry for loss of URL in porevious reference) 
> http://comments.gmane.org/gmane.mail.imap.offlineimap.general/1825
> Imap synchronisation failure with READ-ONLY status
>  DEBUG[imap]:   25:20.25 > JMMH37 UID STORE 247650 +FLAGS (\Seen)
>  DEBUG[imap]:   25:20.27 < JMMH37 NO mailbox selected READ-ONLY
> OfflineIMAP Home : http://offlineimap.org/
Seeing this in thunderbird nearly constantly lately. Happened in 12, upgraded to 13 and there is no change. I also check my zimbra account with my galaxy nexus android device using k-9 but I've been doing that for months so I'm not sure why this last week thunderbird has been hitting this so often as to make the app unusable.
From what I can tell, there's no Thunderbird change responsible for this - it's strictly something happening on the server. My understanding is that even if you go offline and online again, the server still tells you that connections are read-only, so shortening TB's timeouts wouldn't help.

Any chance there are server backups going on that are making mailboxes read-only?
Attached file zimbra imap trace log — 
Attached is a log of the zimbra server while tracing my user account.  It is only tracing the one account and not the other active ones.

zmprov addAccountLogger $EMAIL_ADDR zimbra.imap trace

- The first occurrence of the issue happens around 10:51 AM.  Thunderbird grabbed an incoming message got it's attributes, then tried to save the NonJunk flag to the server.

- Thunderbird and iPhone mail both list their UA string on connection. KMail does not. So any connection you with no UA string is KMail.

- KMail is the only client issuing the EXAMINE command. 

- The only things stripped from the log are entries mentioning accounts I don't have posted online somewhere.

- I also have a Thunderbird debug log that was running at the same time. However it also lists contents of all the emails I received in the past 24 hours, so I'm gonna take the lazy route and provide sections of that log upon request. 

- zimbra log are in EST
And when I say Kmail I mean K-9 Mail
Following may be relevant.
> http://tools.ietf.org/html/rfc3501#section-6.3.10
> 6.3.10. STATUS Command
(i) STATUS is an alernative of SELECT+EXAMINE.
> The STATUS command provides an alternative to opening a second
> IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
> query that mailbox's status without deselecting the current
> mailbox in the first IMAP4rev1 connection.
(ii) STATUS may forece READ-ONLY in some implementations.
> In some implementations, the server is obliged to open the mailbox read-only
> internally to obtain certain status information.
(iii) According to log, iPhone issues "STATUS INBOX" almost always.
  In contrast to it, Tb doesn't issue "STATUS INBOX" for new mail check of INBOX
  if max cached connections>1, because Tb reserves one connection for Inbox
  and issues SELECT INBOX(followed by IDLE for the connection usually).
  Tb looks to use STATUS for non-selected folder only upon new mail check.

To all problem reportes:
Did your problem start to occur when you started to use iPhone or after you upgraded iOS or other iPhone app relevant to IMAP?
FYI.
Following document is found.
> https://github.com/wanderlust/wanderlust/issues/5
> IMAP STATUS command MUST NOT be used as a "check for new messages in
the selected mailbox" operation (RFC3501).

According to log, iPhone sends SELECT INBOX after login at a connection, and sends NOOP, UID SEARCH, UID FETCH and so on, then sends STATUS INBOX without UNSELECT at the connection and finally sends LOGOUT.
This may be relevant to problem in Zimbra.
I couldn't find 'SELECT "INBOX"' by Thunderbird in attached server side log.
i.e. Tb keeps a connection for Inbox, and continues to use the connection for Inbox with utilizing IDLE command.

When your problem happens, can "go Work Offline mode then go back to Work Online mode" of Tb be a workaround?
(From perspective of IMAP connection, "entering Work Offline/Online mode" is equivallent to "restart of Tb")

I couldn't find 'STORE Flag" like command by K-9 in attached server side log. K-9 also looks to use IDLE at connection for INBOX.

When your problem happens, is "flag change by K-9" possible?
(Read/Unread status change, move/delete mail at Inbox, ...)
(In reply to WADA from comment #42)
> When your problem happens, can "go Work Offline mode then go back to Work
> Online mode" of Tb be a workaround?
> (From perspective of IMAP connection, "entering Work Offline/Online mode" is
> equivallent to "restart of Tb")
>

Yes, offline/online worksaround the problem.
 
> I couldn't find 'STORE Flag" like command by K-9 in attached server side
> log. K-9 also looks to use IDLE at connection for INBOX.
> 
> When your problem happens, is "flag change by K-9" possible?
> (Read/Unread status change, move/delete mail at Inbox, ...)

I'll try as soon as the problem happens again.  I can't seem to force the problem. Only happens when I leave things completely idle for a while.


(In reply to WADA from comment #40)
> To all problem reportes:
> Did your problem start to occur when you started to use iPhone or after you
> upgraded iOS or other iPhone app relevant to IMAP?

Unfortunately, the zimbra server was upgraded around the same time as I got another iPhone. So either one could of been the cause.  



Re: K-9 on Android + EXAMINE

not sure if it's relevant but it appears that K-9 uses EXAMINE if the underlying network changes. For example, if I walk out of range of my WiFi and it goes to 3G, I see K-9 EXAMINE the inbox.
(In reply to John O'Duinn [:joduinn] from comment #20)
> (In reply to David :Bienvenu from comment #13)
> > (In reply to John O'Duinn [:joduinn] from comment #12)
> > > "The current operation on 'Inbox' did not succeed. The mail server for
> > > account joduinn@mozilla.com responded: mailbox selected READ-ONLY."
> > > 
> > > Hit this problem twice today. Each time, restarting Thunderbird "fixed" it.
> > 
> > did you try toggling the offline state instead of restarting?
> 
> Just hit this READ-ONLY error again. As experiment, I tried toggling
> offline/online, but when I toggled back online, I hit a different "this
> mailbox already in use" error. I then had to restart TB to get back to
> workable state.
> 
> Reading some other comments here, I note that I had build-vpn enabled all
> day. Also, I note that I just came back from long period of idle, and hit
> this as soon as I started to use TB.

Just happened again. Same symptoms as my previous post: build-vpn enabled overnight, I just came back from long period of idle, and hit this as soon as I started to use TB downloading the morning batch of emails.
FWIW, I have not hit this in a long time.  Given the lack of comments on this bug in several months I'm guessing the same may apply to others?  Was anything done to fix this?

The reason I looked up this bug is that I'm actually using Postbox at the moment, and I *am* running into this in Postbox with my Zimbra 8.0.3 server at home.  I am *not* having this problem with Thunderbird with that server and haven't in a while.  I know Postbox was forked from Thunderbird at one point in time, which was suggesting to me that they may have inherited this bug and hadn't fixed it when Thunderbird did.  But since this bug doesn't actually say it's fixed....
I don't think it's fixed, but the frequency of it in thunderbird decreased quite a bit.  It still happens about once every five days or so. However, when I kill & restart thunderbird, everything is working. The kill & restart work-around didn't used to work, so that in itself shows that there was some progress on this.

I'm currently using tbird 17.04, release channel.
Oh hey, this bug is still here...

And yes, Postbox most definitely still does it.  I'm running into it pretty frequently these days with my Zimbra 8.6.0 server on my personal domain.
I recently started experiencing this problem as well. I'm running Zimbra 8.0.7 but haven't changed anything there for quite a while. TBird is 31.5.0. 

I recently factory-reset my Android phone and it defaulted the mail client back to Samsung's email client. I can't be sure, but the timing of that reset may correlate with the READ-ONLY mailbox issue. As a test, I just switched to MyMail on my Android and so far it looks good, but I need more testing time.
I believe that since I switched to MyMail from Samsung's Mail app on the Android, I have no longer had the READ-ONLY problem on my workstation's TB. Until today. I got it once this morning and toggling offline fixed the problem.
See Also: → 1492007
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: