Hi @divb,

kopano-fsck does not really do a full database consistency check, rather it looks for certain known cases of nonsensical data and repairs that.

If you really suspect a damaged database then unfortunately the best course of action is to identify a sane database dump and restore it.

Further inspection of your database could be done, but this would be a task for our support and something that we cannot provide free of charge through a community forum.

@mlued
Yes… that is/was the idea anyway… but it’s a “week of syncing”…

And then there is the “issue” of removing all the IMAP data once the import is done… so I’ll need at least 3TB (I’m sure it will be less but…) to migrate the whole “double” pile…

Regards

@longsleep
I can’t tell you, i have a workaround now that I do not user TLS between gateway and server anymore (see below server.cfg and gateway.cfg.

The issue, I was not able to select my folder to be able to subscribe. If the RCA was too much folders under the public folder I can’t tell.

server.cfg

############################################################## # SERVER SETTINGS # Space-separated list of address:port specifiers for where the server should # listen for unencrypted connections. # # "*:236" — port 236, all protocols # "[::]:236" — port 236 on IPv6 only # "[2a01:db1::1]:236" — port 236 on specific address only # To disable unencrypted connections, set to an empty value. # #server_listen = *:236 server_listen = *:236 # Space-separated list of paths for where to listen for AF_LOCAL # connections. # To disable, set to an empty value.

gateway.cfg

############################################################## # GATEWAY SETTINGS # Space-separated list of address:port specifiers for where the server should # listen for connections. # # "*:143" — port 143, all protocols # "[::]:143" — port 143 on IPv6 only # "[2001:db8::1]:143" — port 143 on specific address only # # imaps is normally on 993, pop3s on 995. # #pop3_listen = *:110 pop3_listen = pop3s_listen = imap_listen = #imap_listen = imaps_listen = *:993 # Connection to the storage server. # Please refer to the administrator manual or manpage why HTTP is used rather than the UNIX socket. #server_socket = http://[:1]:237/ #server_socket = http://localhost:237/

Currently it’s running. As soon as I do have time, I’ll do a thorough testing and check (hopefully already on the new release, which should come within the next weeks/months?).

cheers
scheini72

Hi @fbartels ,

no, I never used kopano-archiver on this server.
I am trying to find out, which object may cause the message. Only hint I got up to now, for this user, search is also not working well.

Best regards,

Ihon

Just a dump guess out of the wilds but,

maybe a missing database schema update?
I think I got a similar issue years ago.

Found this post.
https://forum.kopano.io/topic/2377/specific-user-cannot-share-folders-or-change-permissions/4

You could give these commands a try, but please do a backup before.

kopano-dbadm k-1216 kopano-dbadm usmp

http://manpages.ubuntu.com/manpages/eoan/man8/kopano-dbadm.8.html

@scheini72 said in Traceback while backup-restore:

kopano 8.7.20 (supported)

In that case I would recommend contacting the Kopano support directly and submit the backup set to reproduce the error.

@fbartels
Hi Felix,
Thanks a lot!!!
One directive was indeed missing:
virtual_mailbox_domains = [example.com]
Once defined it worked like charm.
Although, not understanding as to why this directive is necessary and how that is related to the ldap search and lmpt failure but it’s running now.
Thanks again and have a nice holiday!!!

Hi @fbartels,

Thanks for Your reply,. I already tried to set log_level 0x00020006 with no success.

But I now got it running to get answers from AD.

Do not know why, but apparmor was my favorite candidate.

So I reinstalled (whoo like working on Windows) the lates community builds on a fresh debian 10 without apparmor installed and got success to query AD.

On this I also get log entries in syslog as well as in any desired logfile I define.

I saw apparmor messages before on the first system regarding DENIED für /usr/lib/kopano/ files, but sorry, I did not document this before deleting the vm.

Regards Lukas

@anth-frnog

I auto answer from me.

So in Kopano-core 11.0.1 the /usr/sbin/kopano-autorespond does not exist.

I take this file from Kopano-core 10.0.6 and now it works fine.

Maybe I’m wrong but it resolv my issue.

I’m open to make a test if needed.

Antho

@fbartels
Hi Felix,
That’s a pity that there’s no release notes but now I can monitor change dates…
Cheers,
gduran

@fbartels
Hi Felix,
OK, that’s clear. Meanwhile I did succeed in migrating to a new server using rsync to copy the attachments and a mysqldump to transfer the data and setting the attachment_storage to ‘files’.
So far so good.
Question: What will happen if I change the attachment_storage to files_v2? Will the storage than be automatically converted?

Hi @fbartels,

Aha, that explains. I removed it and everything seems OK.
Thank you!!!

Hi @fbartels,

thank you for pointing me to the current doc’s.
I still used the obviously outdated version here: https://kb.kopano.io/display/WIKI/Install+and+optimize+OpenLDAP+for+use+with+Kopano+Groupware+Core

ldap_uri did the job!

thx
Robert

kopano-stats --top

look at Threads(idle), server need some idle threads to work.

@fbartels

‘libvmime-kopano3’ 0.9.2.96+3.1

Hi @s-stuercke,

this does not seem to be possible at the moment. The related development ticket is https://jira.kopano.io/browse/KC-1525.