You are right, and sorry you have hit this more than once. That page went away when the API documentation was restructured, and the old URL was never redirected.

The Files API reference now lives here:
Upload and download, REST: https://docs.zextras.com/apidoc/files_blob/index.html
Metadata and folders, GraphQL: https://docs.zextras.com/apidoc/files_meta/index.html

Both are listed on the CE API index: https://docs.zextras.com/carbonio-ce/html/develop/toc.html

Regards!

Also the repo at https://github.com/zextras/carbonio-webui-i18n/ does not contain any json files, not even a template so potential translators do not know what to translate. And the link: https://zextras.com/carbonio-ce-contribute/ redirects to https://zextras.com/

Is there anyone who cares about translations and willing to accept community contibuted translations?

Best regards

Vladki

Also the repo at https://github.com/zextras/carbonio-webui-i18n/ does not contain any json files, not even a template so potential translators do not know what to translate. And the link: https://zextras.com/carbonio-ce-contribute/ redirects to https://zextras.com/

Is there anyone who cares about translations and willing to accept community contibuted translations?

Best regards

Vladki

Ok so for now, the main goal was to get Zimbra re-installed and a working system. I did go the Rocky 810 route and managed to "fudge" the system into installing Zimbra. It was a case of modifying "os-release" and "rhel" files to show RHEL 8.10. Then reinstall the originals of course after Zimbra install went through....

As for the data.... this is a big problem and at the moment quite stressful.

The mysql server won't start at all!

2026-09-08 13:51:25 140597963827008 mysqld (mysqld 10.1.25-MariaDB) starting as process 8464 ...
2026-09-08 13:51:25 140597963827008 InnoDB: Using mutexes to ref count buffer pool pages
2026-09-08 13:51:25 140597963827008 InnoDB: The InnoDB memory heap is disabled
2026-09-08 13:51:25 140597963827008 InnoDB: Mutexes and rw_locks use GCC atomic builtins
2026-09-08 13:51:25 140597963827008 InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2026-09-08 13:51:25 140597963827008 InnoDB: Compressed tables use zlib 1.2.3
2026-09-08 13:51:25 140597963827008 InnoDB: Using Linux native AIO
2026-09-08 13:51:25 140597963827008 InnoDB: Using SSE crc32 instructions
2026-09-08 13:51:25 140597963827008 InnoDB: Initializing buffer pool, size = 6.2G
2026-09-08 13:51:25 140597963827008 InnoDB: Completed initialization of buffer pool
2026-09-08 13:51:25 140597963827008 InnoDB: Cannot create log files because data files are corrupt or the database was not shut down cleanly after creating the data files.
2026-09-08 13:51:25 140597963827008 Plugin 'InnoDB' init function returned error.
2026-09-08 13:51:25 140597963827008 Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2026-09-08 13:51:25 140597963827008 Plugin 'FEEDBACK' is disabled.
2026-09-08 13:51:25 140597963827008 Unknown/unsupported storage engine: InnoDB
2026-09-08 13:51:25 140597963827008 Aborting

I have just written on the Zimbra forums to see if anyone can help with this?

I did find this: https://wiki.zimbra.com/wiki/King0770-Notes-When_innodb_force_recovery_Fails

but I don't really understand it as the instructions seem incomplete? Also I have no redo logs either in my system.

I am not sure exactly what Zimbra stores in the DB but if it's stuff like calendar data and email folders then it really is imperative that somehow the data is recovered otherwise this will be a nightmare to recreate.

My personal "inbox" had thousands of folders in a set hierarchy which is what I'm really concerned with 

Hi,

You could try following approach:

1. Install Carbonio CE on any of the supported OS meeting preliminary and other requirements. 
2. Plan your migration from Zimbra 10.. (FOSS) to Carbonio CE
3. Take a look at this doc regarding migration to Carbonio CE.

To give you heads up on migration, it basically contains two basic parts (at least):

a. Transferring and provisioning all accounts, DLs, basic settings etc., from your source server to Carbonio CE server.
b. Migrating Emails from source to Carbonio CE server using IMAPSYNC.

You would find all these in the official documentation.

Thanks!

Hi,

You won't find any repository for Ubuntu 20.04LTS. The OS reached it's standard life cycle on May 2025. Therefore, we decided to focus on OS which are still active and receiving updates, like Ubuntu 24.04LTS, Ubuntu 22.04LTS.

Why don't you you try these or am I missing anything ?

Thanks!

Hi,

Sorry to hear about your trouble.

Carbonio Community Edition (CE) does not have 2FA. Regarding using Rocky Linux as your base OS, I would advise against it. At this moment Carbonio CE supports Ubuntu 24,04LTS, Ubuntu 22.04LTS, RHEL8 & RHEL9. 

I am mostly concerned about your data and without damaging your existing system what I would suggest you (tedious but feasible IMO):

• Zimbra doesn't keep everything in the database. Message bodies are files on disk under /opt/zimbra/store/..., and accounts, domains and passwords live in LDAP. MySQL holds mailbox metadata, folder placement, read/unread, flags, tags, threading.
• Even if the database can't be repaired you can still recover the mail, in some cases 🤞

1.a Get the mailbox number from mysql (if possible)
mysql -e "SELECT id, comment FROM zimbra.mailbox WHERE comment='user@example.com'"

1.b If mysql does not work, try the logs:
zgrep -ohE "name=user@example.com;mid=+" /opt/zimbra/log/mailbox.log* | sort -u

1.c From the files themselves
grep -rl "user@example.com" /opt/zimbra/store --include='*.msg' | head -5


# Once you undferstand which folder to upload on which account follow rest of the process


2. Find the files for that mailbox
find /opt/zimbra/store/*/<ID>/msg -name '*.msg' | head; find ... | wc -l

3. Copy them to Carbonio
mkdir -p /var/tmp/recovered && find /opt/zimbra/store/*/<ID>/msg -name '*.msg' \
 -exec cp {} /var/tmp/recovered/ \; && rsync -av /var/tmp/recovered/ root@carbonio:/var/tmp/recovered/
chmod -R a+rX /var/tmp/recovered          # on the Carbonio server

4. Create the folder in Carbonio
for a in zimbraMailContentMaxSize zimbraFileUploadMaxSize zimbraMtaMaxMessageSize; \
     do carbonio prov mcf $a 209715200; done
     carbonio prov selectMailbox user@example.com createFolder -V message /Recovered

5. Import one message and check it
carbonio prov selectMailbox user@example.com addMessage /Recovered \
       /var/tmp/recovered/$(ls /var/tmp/recovered | head -1)

6. If it looks right, import the rest
carbonio prov selectMailbox user@example.com addMessage /Recovered /var/tmp/recovered/
carbonio prov selectMailbox user@example.com getAllFolders

Let us know how it goes!

Since I did not receive a solution for this issue, I developed an open-source workaround with some assistance: Carbonio Bayes Trainer.

It monitors the server-side /Inbox and /Junk folder states and trains Carbonio’s SpamAssassin Bayes database when messages are moved by Outlook, Thunderbird, Apple Mail, or other IMAP clients.

Version 0.4.1 has completed a four-week production test on Carbonio CE with 30 mail accounts and more than 16,000 tracked messages. The final health status was clean, with no failed messages in the recent scan history.

The project includes installation and upgrade instructions, dry-run mode, diagnostics, scan history, stable message identification, and protection against overlapping scans.

Project and documentation:
https://github.com/Sixtus81/carbonio-bayes-trainer

Release v0.4.1:
https://github.com/Sixtus81/carbonio-bayes-trainer/releases/tag/v0.4.1

I hope this helps other Carbonio administrators facing the same IMAP/Bayes-training issue. Feedback and test results are welcome.