@micro said in mapi.so not loaded (php7-mapi):

As you see in my posting this is not the issue as the module is integrated correctly and loaded by apache2/php7-fpm (see the provided screenshot, too)

Actually, the screenshot shows kopano.ini configuration was parsed.
This does not necessarily mean that corresponding code-modules were loaded sucessfully, too.
Such failures (e.g. outdated dependencies of mapi.soshould go the php-fpm-error log.
++umgfoin.

@Drees if the file exists, but still the error is logged then some more further investigation is needed. Since you are running 8.7.0 I assume you have a support subscription? I’d recommend to get in touch with our support in that case.

Hi,
this is a answer to myself or anyone who has the same problem.

I solved the big storage issue by stopping kopano-search, deleting /var/lib/kopano/search/ and restarting kopano-search.

Old size of search-cache was 77 GB, new size is 1,4 GB.

The reason: I don’t know. Maybe a bug while importing in 8.7.1?

Bye.

@marlemion no, we just have general information. for example https://stash.kopano.io/projects/KC/repos/kopanocore/browse/doc/install.txt

Felix, thank you very much. A chown on /var/run/kopano did the trick :) I will look out for a new version with this “bug” (?) killed.

@edwinkok said in Loggin into webapp not possible:

Anytime soon for a new build to fix this?

I have not been in the office for the past week so I don’t know the latest status. But we had a pr for this open last week.

same as the run_as_user/group , most probely, kopano:kopano.

ls -al /run/kopano/ total 28 drwxrwxr-x 2 kopano kopano 240 Jun 17 15:31 . drwxr-xr-x 26 root root 860 Jun 19 06:47 .. -rw------- 1 kopano kopano 5 Jun 17 15:31 dagent.pid -rw-r--r-- 1 kopano kopano 5 Jun 17 15:31 gateway.pid -rw-r--r-- 1 kopano kopano 6 Jun 18 08:39 ical.pid -rw-r--r-- 1 kopano kopano 5 Jun 17 15:31 monitor.pid srw-rw---- 1 kopano kopano 0 Jun 17 15:30 prio.sock -rw-r--r-- 1 kopano kopano 5 Jun 17 15:30 search.pid srwx------ 1 kopano kopano 0 Jun 17 15:30 search.sock -rw-r--r-- 1 kopano kopano 5 Jun 17 15:30 server.pid srw-rw-rw- 1 kopano kopano 0 Jun 17 15:30 server.sock -rw------- 1 kopano kopano 5 Jun 17 15:31 spooler.pid

The server.sock and prio.sock are set wrong after start/restart.
If you using my script for a local repo setup.

https://forum.kopano.io/topic/2512/socket-permissions-issues-with-kopano-server-build-8-7-81-162/10
then also read. it shows what i did to revert to .150

Hi,
Thanks for your response however, it turns out it’s NOT a rights issue. I’m also able to open and read the key file as user kopano.
Kopano service was running fine through June 10th and I just now noticed in my /var/log/apt/history.log that there was an OpenSSL and various related packages upgrade applied (i.e. Python amongst others) on June 10th late evening (Kopano is running on Ubuntu 18.04). The following day the problem occurred. That hardly can’t be a coincidence. As I don’t have these issues with other applications I start to wonder whether Gateway is using it’s own verification routine and that that has broken due to the aforementioned upgrades.
Just a thought…

Hi @hodor27,

we had some reports of this with 8.7.0, but thought we had this fixed with 8.7.1 (but this was also the caching issue we were never able to reproduce locally, reports afaik stopped after 8.7.1 as well). Please get in contact with our support so they can help you identify steps to reproduce.

That’s a clear statement. Very thanks!

@Chris2 said in K-1540: Unable to get server list: server list:

I just do not know, why it trys to use multi-server functions,

Because you have enable_distributed_kopano set to yes.

This is a separate case. Adding insult to injury, the package calls itself “python3-Pillow” rather than “python3-pillow”. (fixed now in the .spec)

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

I downgraded the Require: to Recommends, since pyplug is not mandatory for basic spooler/dagent functionality.

I have found Packaged python3-Pillow when Install with
wget https://rpmfind.net/linux/epel/7/x86_64/Packages/p/python36-pillow-6.0.0-2.el7.x86_64.rpm
yum localinstall python36-pillow-6.0.0-2.el7.x86_64.rpm
Can Install Kopano

@gduran yes, that message will indeed be logged every time the user list is synced.

Hello,
Thanks for your quick reply!
Correct, only kopano-service stopped before dropping the database. Good news is the error message disappeared after an hour or so. The only thing I did was to test to insert data using the old zarafa migration tool. Just don’t understand how this relates (???). Now the only errors remain are K-1515: Object not found unknown user as well as the missing kopano-cli as explained in the “K-1537: Unable to move object user” thread.