I wasn't implying there was a permission problem. I was only mentioning that as a possibility. It is definitely some type of trouble reading in the xml file, but unfortunately the stack trace doesn't mention exactly what is wrong. In fact the trace looks strange. The part at the bottom:
Caused by: com.zimbra.common.service.ServiceException: system failure: Unable to parse XML file /opt/zimbra/backup/sessions/full-20080308.060007.994/a
ccounts/e08/bc6/e08bc6bd-d835-4262-8a56-7365c3313789/meta.xml
Code:service.FAILURE
at com.zimbra.common.service.ServiceException.FAILURE (ServiceException.java:183)
at com.zimbra.cs.backup.XmlMeta.readAccountBackup(Xml Meta.java:381)
at com.zimbra.cs.backup.FileBackupTarget$RestoreAcctS ession.<init>(FileBackupTarget.java:1568)
... 35 more
Caused by: java.io.IOException: Input/output error
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.handler.RewriteHandler.handle(Re writeHandler.java:176)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(Htt pConnection.java:506)
This looks very strange. Somehow the code that reads the meta.xml file got an exception out of HTTP handler? That doesn't make any sense. Are you sure you cut/pasted the stack trace correctly?
Unfortunately, Java IOExceptions don't report the OS errno and there's much guess work involved. One other possibility is that you are running out of file descriptors on your box. Did you see anything unusual in /var/log/messages around this time? (I'm not sure fd problems are reported there though.) Check the fd limits in /etc/security/limits.conf and also ulimit -n output of zimbra user.
Do another backup to see if the stack trace still comes out with the strange final "Caused By" section out of HTTP code. That is the most puzzling part of this problem. |