UCS server rebuild problems

I have a UCS server that Kopano Meets stopped working on. It looked like it was due to a certificate problem so I went down the path of updating the certs using the files from my reverse proxy host.

The end result was nothing will work. No users can authenticate. AdminUI cannot load. Mail delivery fails with the logs showing an inability to connect to LDAP.

Of course I don’t have a backup …

So I’ve started over with a new UCS ESXI image and I’ve started loading packages.

The issue is this – I need to get the user mailboxes and attachments from the old server and I’m not having any success with using kopano-backup -u user

Please advise. I really don’t want to be at this all weekend!

I don’t use Kopano personally, main reason being that it stores mail in a database. I like having everything in files like dovecot does so in a worst case scenario you can just copy files.

Having said that, it sounds like you might be able to look into the docker files and figure out how Kopano stores that database and then after getting everything rebuilt, shut down kopano and then move that database over to the new server and start it back up again.

This is all guesswork for me, so my second piece of advice if you haven’t done this already, would be to ask on the Kopano forums how to transfer things over. I’m sure there is probably quite a few options available, but I don’t know enough to give more than that basic advice. Hope it helps. I have been in this type of situation many times and it’s never fun.

Actually, just found this. Looks like you should be able to dump the database as a last resort.

mapi is broken because LDAP is unreachable. Slapd errors out…

what I need help with at this point is

A) regenerating the SLAPD certs


B) setting everything to point directly to LDAP and ignore the secure side long enough to get the data off this messed up host

root@blade:/# kopano-backup -f Calendar -O /root/backup/calendars
2020-10-30 21:33:08,690 - backup - 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/service.py”, line 182, in start
_daemon_helper(self.main, self, self.log)
File “/usr/lib/python3/dist-packages/kopano/service.py”, line 59, in _daemon_helper
File “/usr/lib/python3/dist-packages/kopano_backup/init.py”, line 420, in main
File “/usr/lib/python3/dist-packages/kopano_backup/init.py”, line 431, in backup
jobs = self.create_jobs()
File “/usr/lib/python3/dist-packages/kopano_backup/init.py”, line 666, in create_jobs
File “/usr/lib/python3/dist-packages/kopano/store.py”, line 419, in folders
yield self.folder(path)
File “/usr/lib/python3/dist-packages/kopano/store.py”, line 389, in folder
return self.subtree.folder(path, recurse=recurse, create=create)
File “/usr/lib/python3/dist-packages/kopano/folder.py”, line 627, in folder
path = getattr(self.store, ENGLISH_FOLDER_MAP[path]).name
AttributeError: ‘NoneType’ object has no attribute ‘name’

/etc/kopano/server.cfg contains the SQL username and password used by UCS

I learned what databases were present using
mysql -u kopanoDbUser -p
Your MariaDB connection id is 168
Server version: 10.1.47-MariaDB-0+deb9u1 Debian 9.13
Copyright © 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
MariaDB [(none)]> SHOW DATABASES;
| Database |
| information_schema |
| kopano |
2 rows in set (0.00 sec)

MariaDB [(none)]> exit

Per the Kopano documentation here https://documentation.kopano.io/kopanocore_administrator_manual/backup_restore.html

I built a Kopano DB backup

mysqldump -u kopanoDbUser -p --single-transaction --routines kopano -r /root/backup/kopano.sql

mysqldump -u kopanoDbUser -p --single-transaction --routines information_schema -r /root/backup/information_schema.sql
Enter password:
mysqldump: Couldn’t execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM XTRADB_RSEG': Access denied; you need (at least one of) the PROCESS privilege(s) for this operation (1227)

I’m sorta assuming the information_schema database is the same across two UCS Kopano servers. I may do a compare to see.

Right now I am at the point where I have backed up the attachments and transferred them. I’ve restored the attachments to /var/lib/kopano/

I have transferred the DB dump and I’m currently restoring it using
mysql -u [user] -p [database_name] < [filename].sql

I have used info on the dead server to enumerate users and stores

List all orphaned mailboxes:
“kopano-cli --list-orphans”

this one is far more helpful … it says who the user was
kopano-admin --list-orphans

root@blade:~/backup# kopano-admin --list-orphans
The selected option is deprecated in this utility.
Forwarding call to: kopano-storeadm -O.
Stores without users:
Store GUID Guessed username Last login Store size Store type

2fe41f83e18a456a91250671235a74be user1 18h ago 968.00 MB private
34607bfd20544c87bdf5852f74abc47e user2 21h ago 548.75 MB private
be8b6f6d906a4d64bb524fdcf183c306 user3 18h ago 4673.97 MB private
e57c77a3944642c6812f507df4b8c8c4 user4 19h ago 1421.49 MB private
f7c4302605e3449f9bb6f687ebe94ffd user5 366d ago 0.04 MB private

Users without stores:


That ended the guessing game to figure out which user is which

I found I could hook the store with a new local user on the new server with:
“kopano-cli --hook-store= -u ”

I found that even after a reboot and letting the box sit for a few hours that
permissions are a problem. My guess is this is because the userIDs are likely very different than they were.

I got a mailbox to show up after binding it to the user with
kopano-cli --user someone --add-permission ‘someone:folder_owner’

well … I FINALLY have a user with a complete message store showing up in the webapp and a complete public folder import

I can send emails out

Now the problem is if I try to send an email to myself from the webapp it ends up in /var/spool/mail/user instead of invoking delivery agent.


Hi @kopanogobigred,

you indeed can only use tools like kopano-backup only when the kopano-server process us running (which is hard when it cannot connect to ldap to check users). But to backup and restore users the way through a database backup is anyways preferred for a full disaster recovery (or if you want to perform a full migration).

As for why the mails are delivered locally and not to the Kopano mailboxes I would strongly recommend to reach out directly to either the Kopano support or the Univention support and this sounds like an indicator for an incomplete installation and should be something to be resolved much quicker with direct access to the system.