Hi all

We've been using Zimbra for years and it always worked reliably until I upgraded from 6.0.7 to 6.0.10 three months ago.

Users started reporting problems with the Zimbra web interface approximately once a week. The effects were strange as not all users were affected.

Problems reported from users and seen with my own eyes were (it is always just the web ui that is affected!):
- not possible to login (while IMAP, etc. works) or
- not possible to create a calendar entry or
- not possible to create a new email message or
- admin web ui does not load (not even the login screen)

Restarting Zimbra seems to fix the problems.

We hoped for a fix when we upgraded to 6.0.12, and again when we applied the 6.0.12 patch. But instead of an improvement we now have to restart Zimbra at least once a day as the problems keep reappearing more often.

I searched the logs and the only thing I found were errors in /opt/zimbra/log/mailbox.log. For example, this morning I was not able to login to the admin web interface, while logging into the normal web interface worked fine. I got the following error every time I tried to load the admin ui:

Code:
2011-06-01 07:19:03,261 INFO  [btpool0-699://localhost:7071/service/admin/soap/GetDomainInfoRequest] [ip=127.0.0.1;] soap - GetDomainInfoRequest
2011-06-01 07:19:03,267 WARN  [btpool0-701://zimbra.mydomain.com:7071/zimbraAdmin/] [] log - /zimbraAdmin/: java.io.IOException: Permission denied
2011-06-01 07:19:03,268 WARN  [btpool0-701] [] log - /zimbraAdmin/
java.io.IOException: Permission denied
        at sun.nio.ch.FileChannelImpl.map0(Native Method)
        at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:734)
        at org.mortbay.io.nio.DirectNIOBuffer.<init>(DirectNIOBuffer.java:70)
        at org.mortbay.jetty.servlet.DefaultServlet$NIOResourceCache.fill(DefaultServlet.java:1000)
        at org.mortbay.jetty.ResourceCache.load(ResourceCache.java:198)
        at org.mortbay.jetty.ResourceCache.lookup(ResourceCache.java:166)
        at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:411)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:705)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:218)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:422)
        at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:330)
        at org.mortbay.jetty.servlet.Dispatcher.error(Dispatcher.java:135)
        at org.mortbay.jetty.servlet.ErrorPageErrorHandler.handle(ErrorPageErrorHandler.java:129)
        at org.mortbay.jetty.Response.sendError(Response.java:274)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:475)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:218)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:422)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.handler.DebugHandler.handle(DebugHandler.java:77)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.Server.handle(Server.java:326)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:543)
        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:929)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
I restarted Zimbra and the admin interface worked again. Two hours later I got a phone call reporting that no calendar events could be created. I checked the same log:

Code:
2011-06-01 09:20:53,041 WARN  [btpool0-84://zimbra.mydomain.com/zimbra/js/CalendarAppt_all.js.zgz?v=110306011814] [] log - /zimbra/js/CalendarAppt_all.js.zgz: java.io.IOException: Permission denied
Permission denied again.

I stopped Zimbra, executed zmfixperms as root and started Zimbra again. The next phone call came not even an hour later: "I cannot create a new mail". The log shows:

Code:
2011-06-01 10:01:17,029 WARN  [btpool0-43://zimbra.mydomain.com/zimbra/js/Mail_all.js.zgz?v=110306011814] [] log - /zimbra/js/Mail_all.js.zgz: java.io.IOException: Permission denied
Again, restarting Zimbra fixed the problem.

No one has reported errors with IOException and Permission denied in this forum during the last couple of years.

Any ideas what could be responsible for this really annoying behavior?

Thanks in advance
CrypTom