you create these groups where you manage your users.

If you are using the db plugin and creating your users with kopano-cli (or kopano-admin), then you also use this to create groups.
If you are using an ldap backend (e.g. when using ActiveDirectory or on Univention) then you are also managing your groups in there.
In the case of UCS your simply create group from their web ui and then in the group details mark it as a “Kopano group”.

Relevant chapter from our documentation: https://documentation.kopano.io/kopanocore_administrator_manual/user_management.html

No, this problem still exists.

@pixel yes, you cannot do a single item restore from a MySQL dump. But you could restore your MySQL database to a temporary system and then use kopano-backup to get the items that you want to have restored.

Ok sorry, forgot the informations.

The Base System is CentOS 7

The current kopano version is 8.6.9.0-24.1 , with webapp 3.5.4.2236-92.1 and libvmime 0.9.2.50-12.2 , i added the rpm versions.

Aargh, I had two errors:

copy&paste error : file:///var/run/kopano/server.sock. instead of file:///var/run/kopano/server.sock (note the trailing dot…). Interestingly, the gateway does not complain that the socket does not exist… typo in username for passwordless server - then it cannot find a user and acts as if it had a bad password.

I also found this interesting post:
https://www.invenios.de/blog/121-zarafa-gateway-imap-ohne-passwort/
It must be adapted slightly to work with a systemd-based distro, in fact you copy the kopano-gateway service in /lib/systemd/system with another name, add a parameter for a seconf configuration fil and in this config you put the passwordless auth, e.g. limited to 127.0.0.1 for the client. Then you can even run the normal gateway unchanged and an additional service without passwords.

To elaborate in what @thctlo said, the packages in the downstream Debian repositories are not made by the Kopano team but by external contributors (with some assistance by Kopano).

I don’t think the maintainers are frequent to our forums, therefore to report problems in these packages it’s best to report them to the Debian maintainers. You find relevant information at https://wiki.debian.org/Groupware/Kopano

Hi @rpatw ,

a quick survey on the web makes it seem that it’s quite normal for clients to require at least one entry in “to” when using bcc.

@isol said in AD extension: no kopano tabs??:

Hmmm, I now compared the current .ldf files (in the source tarball of the ads extension) with the ones downloaded from

https://stash.kopano.io/projects/KC/repos/kopano-ads-source/browse/samba/kopano-samba-ads

and they seem to be different.
Is that a problem? Can/should I just reapply the schema extension on the samba system?

Then i suggest, use this version.
https://download.kopano.io/community/adextension:/sourcecode/
that one should be most up2date.

Hi all,

after a clean new setup ist work’s perfect at Debian 9 and kopano-server 8.7.80 and it seems to be working also at Debian 10 (not 100% sure yet).
Problem was - may be - a mix up with kopano-packages from Debian 10 updated with packes from nightly build.

Yes, it looks like the bug. I’ll have to ask the distro for an upgrade.

Thanks for your help.

Ok.
I installed kopano-backup v. 8.6.7.0 (on a different server) and I’m trying to back up.

Backup done.

@rpatw ,

This is a bug https://jira.kopano.io/browse/KC-1422, will be fixed in the 8.7.1 release

As we are still busy fixing the caching issue’s(https://jira.kopano.io/browse/KC-1417) there isn’t a release scheduled yet for 8.7.1.

did work like a charm, thank you. For those who are interested in: the command ran only a few seconds and no interruption of running services occured.

Cheers!

Hi robing,

this I found out a few minutes before your post (because I found new created users with usernames like heinz.horst@test.tld@test.tld) .

First: All is working fine now!

For all others - my settings are now:

/etc/kopano/server.cfg
loginname_format =%u
sync_gab_realtime = yes
user_safe_mode = no

/etc/kopano/ldap.cfg
ldap_loginname_attribute = mail

After all, RESTART the service kopano-server - a reload seems to be not enough!

Thank you robing for your hints!

regards
Robert

No migration and as far as I know no script.
The user uses Microsoft Outlook. I guess that might be the problem.

Thank You!!!

running

python3 ./cleanup.py --user xxx

runs perfectly !

Just one more question: is it possible to get delivery confirmations (not read confirmations) by some setting somewhere? Delivery confirmation works when sending from Outlook 2016, but i’d rather use the Kopano Webapp.

Hi @ekpack,

The issue you described is twofold:

Senddate is altered: https://jira.kopano.io/browse/KC-1371 If you open the mail the send date is wrong: https://jira.kopano.io/browse/KW-1756

I’ve commited a fix for KW-1756

I’m moving this ticket to core sub forum again, since KW-1756 won’t solve your actual issue. KC-1371 does :)

@fbartels said in Kopano-spamd is not automatically restarted after a Kopano-server restart:

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

Thank you!