Settings lost after crash
Our customer uses Kopano 11.0.1, Webapp 184.108.40.206+167.1 on Debian 9, the clients are running all the latest Win10pro, and Kopano DeskApp 2.7.1 with 50 active and 50 non-active accounts.
Every single workstation works pretty fine, this release is really stable and they are all really happy with Kopano.
But since a few months some of them (3) are using the same primary account on their workstations. They log in with the same office account, and they use this setup like a ticket system. If there is a new mail in the inbox, the immediately move the mail to a specific subfolder, and then reply to the message or move it to another folder.
Now, the problem: Sometimes, if they search for a specific mail (order number) (they got a few hundred orders a day and a few hundred others mails) and immediately move one of this order mail to another folder, the whole WebApp (or DeskApp, that does not matter) hangs. Mostly, closing the window, log in again solves the problem and everything is fine again. But now (!!!) once or twice a week, after a new login, all settings of the account are gone. Language, signatures, favourites and opened shared folders.
Does anyone have an idea? If it is possible, I don’t want to upgrade the whole server to MAYBE solve the problem…
JungleMarc last edited by JungleMarc
Keep an eye in the logs in /var/lib/kopano, see if you are able to notice details when this is happening. This may be useful for the code ninjas part of this forum who could help.
Also, there are some utility scripts part of Kopano to check the integrity of the database. Make a full backup of your SQL before proceeding. These maintenance scripts should not run during production hours.
What if you create yourself a 2nd machine where you can dump your latest daily SQL backup over there, and have this as a spare system? Either way if you have to really rebuild the server, you’d be halfway done that way. And from there, test the maintenance db scripts without affecting your production hours, and heck, you’d be even able to test it all during work hours, without affecting anything of your production environment. It never hurts to be safe, and have forms of extra redundancy in case things go wrong.
In the current situation, it is not possible to make such a database repair procedure. I hope it will be possible soon.
Unfortunately the problem still occurs.
I thought I had it under control. Everyday I run a script to backup the web app settings, with
python3 webapp_admin.py --backup --all-users
But it does not contain any favorite folders… :-(
JungleMarc last edited by
Since you are only having this issue with the same 3 users all sharing the same account,
while all other users are doing ok,
I suggest trying instead a different approach to sharing the data.
Try making 3 new separate accounts for each of your users,
then login back in that initial shared inbox, and set permission on there for full access for the 3 users.
then login in each of these new inboxes, and select to add the shared-inbox account.
That way, they will each have access to both their own personal email and the shared inbox.
It is at least the documented way of sharing inboxes. I’m unsure how well that was supposed to be for users who all share the same login, if it was ever recommended by design.
@junglemarc Thank you, but this is no solution.
This post is deleted!
JungleMarc last edited by
@mpraunegger fair. I proposed a workaround, not a solution. I wonder what’s next for debugging this issue.
Could there be clues in logs when this happens?
Today, it happened again.
LOGLEVEL_WARN is not the best choice, I will change the value to LOGLEVEL_ERROR because, once a day, there is just one entry:
[12-May-2022 06:56:45] [ERROR] itemmodule::handleException():open: Could not find message, either it has been moved or deleted or you don't have access to open this message. :MAPIException::__set_state(array( 'baseFile' => NULL, 'isHandled' => false, 'displayMessage' => 'Could not find message, either it has been moved or deleted or you don\'t have access to open this message.', 'allowToShowDetailsMessage' => false, 'title' => NULL, 'notificationType' => '', 'message' => 'MAPI error ', 'string' => '', 'code' => -2147221233, 'file' => '/usr/share/kopano-webapp/server/includes/core/class.operations.php', 'line' => 1932, ...