It exists but is practically dead. Use kopano-admin instead.

Check the server.log for SQL problems.

Hi @genesis74 ,

Absolutely perfect. Thank you so much for the response. Might have to work on my Google foo. Been searching for days and found nothing.

Much appreciated.

Yes, I figured that it is because /run/kopano can be, and in fact is, empty after a reboot (or equivalent). Other cases would include PrivateTmp=yes. Appropriate pull requests are already afloat.

Good afternoon,

I tried in all possible ways and this is still a problem.

If any emails get to the external bank (I can’t divulge the name on here but I can in private) the meeting invites in Outlook do not get received properly.

Surely this is a problem for Kopano? I.e. there may be other organisations with this setup…

Veeam Backup for Linux (Veeam Agent for Linux) is completely free by the way and can nicely do image based backups from a running system which should be consistent enough for the database to work. You can just install it and backup to a NAS or another server with a fileshare. I use that in addition to creating database snapshots and rsync’ing the files to another machine which then does btrfs snapshots of those backups.

This looks like
https://forum.kopano.io/topic/910/reminder-from-already-deleted-calendar-appointment-keeps-on-popping-up

Maybe you can find the answer in that topic

@fbartels

Hi Felix,

thank you for the quick turnaround on this and your recommendations in light of what I want to achieve. I’ll definitely check out the LDAP route! :)

Kind regards.

Hi Felix,

sorry for the delay, but I am covered with dust uhm… work ;-)

No I have not contacted support about that. Will do it.

@Manfred
Just commenting to let you know this error still exists in 8.7.84 on CentOS 8. The same behaviour as previously observed.

Ah… now i understand… so easy :) this is second command, after the backup. This works fine:

/usr/sbin/kopano-backup --purge=2 /root/kopano-backup

Solved, very thanks

Hi @sirio81,

it lists “unknown” as the Homeserver, since you have not given a name to your Kopano node in server.cfg. but specifying the name is only necessary in “distributed” setups (more than one kopano-server).

I always do it that way because if I stop kopano-server I always get errors in search.log like (I cut the long part)

MAPI.Struct.MAPIErrorNotFound: MAPI error 8004010F (MAPI_E_NOT_FOUND)

I did not find any recommendation in the docs but I think kopano-server should always be the last to be stopped and the first to be startet (even though kopano-server logs

[error ] Error while connecting to search on "file:///var/run/kopano/search.sock"

when kopano-search ist not running. Which is obvious ;-)

I found this https://jira.kopano.io/browse/KC-1444
I ran the dbadm, I’ll see after few days if problems still exists.

@jengelh Thank you, for your reponse.

After removing the nightlies and installing the release packages, I got the following message in the server.log:

WARNING: Database version (8,7,80,0,118) is newer than the server version (8,7,5,0,118)

Since the database version (118) was identical, after updating the versions table everythings was running fine again. (see https://forum.kopano.io/topic/1972/database-version-8-6-80-0-70-is-newer-than-the-server-version-8-6-9-0-70)

So everything is solved. Thanks.

Hi @Drmaw,

it is indeed recommendable to import pst files of a given language into a store of the same, else you would see a “duplication” of special folders such as the Inbox, drafts, calendar, etc. Duplication in the sense of that the mailbox will still use the english named version, but you will have another folder of your chosen language with your imported items.

Just two remarks:

@Drmaw said in kopano-migration-pst folder names:

KOPANO_LOCALE=“C″
KOPANO_USERSCRIPT_LOCALE=“C″`

These settings don’t have an affect for quite a while already, so setting these will not have an impact.

@Drmaw said in kopano-migration-pst folder names:

Please note: if you have aready created the user, you have to delete and recreate it.

You can actually rename the special folders in a mailbox after the mailbox has been created. So you do not need to delete and recreate the whole mailbox.

I see nothing wrong here. Yes, connections will run into timeouts (obviously), but that is a normal and anticipated practice. k-server will just reconnect.