Hey Felix,

thank you very much. This was exactly what I was searching for.

With best regards and all the best for Christmas and a Happy New Year, if we don’t have any more contact in 2018.
Christian.

@Drethaldier Exactly if you’re running the gateway as a root user it is exactly what thctlo and I say… A matter of access rights. Please try the following:

sudo -u kopano /bin/bash
cat /etc/letsencrypt/live/domain.xx/privkey.pem

If you’re able to cat the file as user kopano and gateway is running as user kopano your issue should be solved. if you cannot cat the file as user kopano please check the access rights for each part of the folderlist and for the privkey.pem itself. If you want to have a quick solution for your christmas eve to happen without any thought about this certificate just copy the privkey.pem and cert.pem to /etc/kopano/gateway, do a “chown kopano.kopano /etc/kopano/gateway -r”, a “chmod 600 /etc/kopano/gateway/privkey.pem” and a “chmod 655 /etc/kopano/gateway/cert.pem”. Afterwards check that gateway will run as user kopano and group kopano and restart the gateway service.

Andreas

Hi @fbartels ,
It happens with WebApp (3.5.1.2040+1126.1) or Outlook using MAPI.

Nuno

The fedora builds are failing internally for a while already (this is also why the archive says 8.7.80.307, but you actually have 8.6.81.249 in the archive). I would recommend to use one of the officially supported kopano distributions for your installation. Debian is the most popular one according to our download statistics.

@tbone said in database size vs size in backup:

thanks for you answer. My main reason to keep files in DB : my db server has a replicating slave off site. I dont like the need for 2 different syncing mechanisms for 1 dataset, especially when one is almost synchronous and the other one isn’t.

Since storing databases outside of database is recommended… The off site slave is used for instant backup purposes and loosing less information possible, right? Maybe you should have a look for either unison with inotify or some replicating file system (like i.e. glusterfs, drbd) - but replicating / mirror file system could be a performance killer and should be setup with care.

Regarding your initial question - just my guess… Kopano is storing some information in database duplicated and in an performance oriented way (i.e. imap props for gateway). Additionally there are indexes. All things that usually will be dropped by a backup since being recreated by a later on restore…

Andreas

@fbartels
Thank you, the deactivation of the service kopano-spamd was successful. I filter out spam in advance.
I use the server for three users at home. Previously, I had used Zarafa for years and was very satisfied.
Perfect, thanks a lot! :-)

@fbartels
Bello,

I found a quick and dirty workaround ;-)
I extracted from an old kopano-dagent_8.6.80.1018-0+152.1_amd64.deb the /usr/lib/python2.7/dist-packages/kopano_utils directory in my server. Then I changed in /usr/sbin/kopano-autorespond the shebang to

#!/usr/bin/python2.7

Restart kopano-dagent Now it work’s

Thomas

Hi all

any news here ?
i got the same on ubuntu 18.04 and found no solution yet…

here are my outputs:

$ kopano-search start: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc try: yield File "/usr/lib/python3/dist-packages/kopano/service.py", line 180, in start _daemonize(self.main, options=self.options, log=self.log, config=self.config, service=self) File "/usr/lib/python3/dist-packages/kopano/service.py", line 111, in _daemonize stderr=sys.stderr, File "/usr/lib/python3/dist-packages/kopano/daemon/daemon.py", line 353, in __enter__ self.open() File "/usr/lib/python3/dist-packages/kopano/daemon/daemon.py", line 345, in open self.pidfile.__enter__() File "/usr/lib/python3/dist-packages/kopano/lockfile.py", line 227, in __enter__ self.acquire() File "/usr/lib/python3/dist-packages/kopano/daemon/pidlockfile.py", line 110, in acquire super(TimeoutPIDLockFile, self).acquire(timeout, *args, **kwargs) File "/usr/lib/python3/dist-packages/kopano/daemon/pidlockfile.py", line 60, in acquire super(PIDLockFile, self).acquire(*args, **kwargs) File "/usr/lib/python3/dist-packages/kopano/lockfile.py", line 265, in acquire raise LockTimeout kopano.lockfile.LockTimeout $ kopano-server --restart-searches Terminated $ service kopano-server restart 2018-12-10 00:36:56,977 - search - ERROR - Traceback (most recent call last): File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc try: yield File "/usr/lib/python3/dist-packages/kopano_search/__init__.py", line 393, in incremental_sync new_state = self.server.sync(importer, self.state, log=self.log) File "/usr/lib/python3/dist-packages/kopano/server.py", line 794, in sync return _ics.sync(self, self.mapistore, importer, state, max_changes, window=window, begin=begin, end=end, stats=stats) File "/usr/lib/python3/dist-packages/kopano/ics.py", line 253, in sync exporter.Config(stream, flags, importer, restriction, None, None, 0) File "/usr/lib/python3/dist-packages/MAPICore.py", line 1903, in Config return _MAPICore.IExchangeExportChanges_Config(self, lpStream, ulFlags, lpUnk, lpRestriction, lpIncludeProps, lpExcludeProps, ulBufferSize) MAPI.Struct.MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)

installed is 8.7.80

@fbartels: Thanks

Thank you for the feedback - the hint about MySQL max_allowed_packet already did the trick… i completly focused on Kopano settings and did not have in mind, to look into MySQL settings.

kind regards,

Christoph

Well, we use Mattermost internally, so the support guys are just a “@channel” away ;-)

@fbartels said in MAPIProvider->imtoinet(): got no stream or content from mapi_inetmapi_imtoinet():

i am currently not in the office, but the last I know is that nightly uploads were failing because of failing builds for Rhel/centos (because of missing python3). I have the feeling that we should disable Rhel builds until dependencies can be resolved again. Will make that a topic next week

Felix I’m sorry you have to be dragged into this during your holiday. I was in the forum to investigate upcoming 8.7 transitions for php and python and innocently noticed an un-answered post that I was sure I could answer with 100% confidence. That Outlook does not work with the archiver as I had spent weeks on this issue with Kopano support 2 years ago and they told me with great firmness in a live webmeeting, that they could not fix the issue. Outlook crashing on stubs caused a ton of grief here at my company, it was not a fun time. I ending up writing my own replacement using your python API with Mark’s help. So imagine my surprise when you and Jan contradict me and say no, it should/probably/might/could/maybe work just fine and we aren’t aware of any general problems.

I am completely and totally at a loss. I personally think Kopano is a fantastic product, best available hands down in your market. And I will says so when asked.
But this, I really don’t understand, if you are correct in your beliefs I feel abused by Kopano support. I have a call tomorrow with Bob and
I’m hoping to gain some insight into the twilight zone I find myself in.

Enjoy your holiday.
David

Anyone with the same problem? And or solution? Even if i change the file with rights 777 when downloaded 0kb

Thanks! Works like a charm.
Regards Stephan

Thanks for the hint. kopano-backup is a wonderful tool.
kopano-backup --restore user1
How can I specify the backup-file I want to use?

the “stores” created in (2) are not stored with the users, but at a different location in the ldap tree.

https://jira.kopano.io/browse/KC-1037

Just use kopano-oof (not kopano-set-oof); it’s there since 8.5.90+ and works on RHEL.