Hey,
thanks for your answers. However the host where it is actually installed does not contain an AppCenter, from where these updates could be started.
I’m posting my findings if I’ll come to a solution with the support.
Kind regards

Hi.
the send as user have to be exist in db in new version of kopano. Take a look in this post send as delegation…

A little bit late but maybe this will help someone in the future.

I worked with ressources some weeks ago and played a little bit with the userrights.
These are working for me:
Calendar userrights english
Calendar userrights german

creating, deleting, moving appointments is working as expected.
users can see the reservation under “Scheduling” and are able to open the Calendar and Calendar entries to see the creator and participants of appointments created by another, but cant edit them.

@Handyman you said you were using the group everyone but also said that “users are all member of the same AD groups”. If you are using AD groups to grant userrights within Kopano please never ever use groups in groups. Users have to be a direct member of the group which you are granting userrights to.
This made me a lot of trouble with LDAP and UNIX systems.
duno if this applies to you.

Most probley the rights are set to : drwx–x— 2 root ssl-cert

adduser kopano ssl-cert
And you should be done.

Postfix, same, adduser postfix ssl-cert
And others same, just check the default rights in /etc/letsencrypt
And use the groups thats set.

I like Manfred its example with setfacl, but thats only one problem.
Its applied on file, what is the files are rotated again?? ;-)

No, you want them to be root:kopano and mode rw-r----- (u=rw,g=r) so that they can be read, but not accidentally written if there is a program bug or exploit.

I have made a bit more progress. I can successfully authenticate against the IDP and pass my UID across. SAML Inspector shows that it has succeeded and I see the value.

Problem is that it just keeps looping over and over again authenticating against Konnect with little logs as to understand, what could be happening.

PS - NameID Transient got me to where I am.

Konnectd Debug on successful authorization thrugh IDP:

time="2020-09-18T19:44:46-07:00" level=debug msg="saml2 attributeStatement" FriendlyName=uid Name=uid NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Values="[username]" time="2020-09-18T19:44:46-07:00" level=debug msg="saml2 authnStatement" SessionIndex=e3c06f66c34b9f126f804dbeac31a26736077e8689fa3d8bd1f229fe2437215d SessionNotOnOrAfter="2020-09-19 10:09:32 +0000 UTC"

SAML Response decoded is sending to https://my.host/signin/v1/identifier/saml2/acs but continues to loop.

Edit - When I head back to Meet I am thrown to the login screen, but a refresh sends me into the video screen “<site>/r/call”

thanks for the quick reply, I’ll check this out

@ecylmz Were you able to get this functioning? I’m encountering a similar issue trying to let a 3rd party provider authenticate for Konnect (I was trying SAML), but wondered if you were successful with LLNG in one of its more recent releases (2.0.9 is out now).
Regards

I did run a --sync after updating and it didn’t seem to work. You are right, it is related to it being case sensitive. I haven’t seen much case sensitivity in LDAP so assumed I could get away with capitals. Thanks as per usual with prompt feedback.

Hi @Chris1984,

as long as the value for the unique user id stays the same (so when using the same ldap tree) your could also do a plain backup and restore of the mysql database and attachments on disk.

https://documentation.kopano.io/kopanocore_administrator_manual/backup_restore.html#full-database-dump

@ilmix while the documentation does not specifically say this, there are currently no configuration files installed by default. I heard this is planned to change for Kopano 9.x.

You can definitly tune your postfix to accept specific EHLO clients or IPs without authentication.

Create a /etc/postfix/helo_client_exceptions file with

mail.example.org PERMIT XX.XX.XX.XX PERMIT

Postmap that file with $ /etc/postfix/helo_client_exceptions

Add it to your /etc/postfix/main.cf file in the smtpd_relay_restrictions section.
Example, here’s mine, you probably won’t need all those arguments

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/helo_client_exceptions, check_sender_access hash:/etc/postfix/sender_checks, # This list restricts recipients when client has no authentication #check_recipient_access hash:/etc/postfix/recipient_checks, reject_unauth_destination, reject_invalid_hostname, ### Can cause issues with Auth SMTP, so be weary! reject_non_fqdn_hostname, ### Basic antispam reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client_hostname, permit_mynetworks, reject_unauth_destination, check_client_access hash:/etc/postfix/rbl_client_exceptions, # Aug 2018: sorbs is a bit too harsh, blocks legit IPs (gmail, orange, github...) #reject_rbl_client dnsbl.sorbs.net, reject_rbl_client cbl.abuseat.org, #reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rhsbl_sender dsn.rfc-ignorant.org, permit

Reload your postfix with systemctl reload postfix and voilà ;)

Hi @user123,

the automatic sorting of junk mail into its dedicated folder cannot be configured per user, but only for all users on a system (technically all users delivering through a specified dagent process).

When you do not want to have junk sorted away you could also disable this in dagent: https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/dagent.cfg#35-47

Here’s some gravedigging for that issue ;)

There’s also the default timeout where mysql / mariadb just closes the connection.
The default timeout is 8 hours.

In my case, it happend like once per day (don’t receive much mail by night):

2020-09-04T17:23:59.183721: [warning] SQL [00000090] info: MySQL server has gone away. Reconnecting. 2020-09-05T11:39:32.273025: [warning] SQL [00001879] info: MySQL server has gone away. Reconnecting. 2020-09-06T07:58:08.715451: [warning] SQL [00000045] info: MySQL server has gone away. Reconnecting. 2020-09-06T13:04:17.721408: [warning] SQL [00000141] info: MySQL server has gone away. Reconnecting. 2020-09-07T07:52:11.653321: [warning] SQL [00000223] info: MySQL server has gone away. Reconnecting. 2020-09-07T08:42:28.721501: [warning] SQL [00000333] info: MySQL server has gone away. Reconnecting.

Solution came from the MariaDB manual: increase the default timeout to something that is never reached.
In my case:

[mysqld] wait_timeout = 288000

Other scenarios include max_packet_size or innodb_log_file_size (search for them in the forum).

@stephen said in MAPI_E_DISK_ERROR after activating multi tenant mode:

without the need to call upon support so early on in the piece

I am not asking you to get in contact with our support. I was simply stating that my general recommendation would be to use our actual releases over the nightly downloads.

@fbartels It works this way, many thanks. Im interpert it from docu in wrong way :D

Thank you, Felix, for your hint, although we’re rather using fetchmail for fetching the mails from providers.
In this case it’the customer’s prescription to remove all those attachments and to return the mails to the sender with some remark.

Actually we’ve found some plugins for dagent to do something like this. It’s pretty near to the evaluation of rules.
Peter