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

Been using Zimbra for decades and the latest SMTP exploit left a bad taste in my mouth.  Granted I'm now on 10.1.20 FOSS which fixed the SMTP exploit, I'd love to move to Carbonio CE as it seems more modern, sleek, etc...  Would any one mind giving me some guidance on how to do this?

Summary: zmmailbox TGZ import reports FileNotFoundException when archive is readable but a parent directory is not traversable

Affected Components: Carbonio Mailbox / zmmailbox / REST TGZ import

Description:

During migration of mailboxes to Carbonio CE using TGZ archives, an import failed with a zclient.CLIENT_ERROR / java.io.FileNotFoundException ending with "Permission denied".

The archive itself existed and had the correct owner and permissions for the zextras user.

Example:

Archive:
/opt/zimbra-migration/ap/<archive>.tgz

Archive ownership:
zextras:zextras

Archive mode:
0600

However, the containing directory had:

ladmin:ladmin
mode 0700

Therefore the zextras user could not traverse the parent directory even though the archive itself was owned by zextras.

The resulting error from zmmailbox was misleading because it looked as if the TGZ file did not exist or could not be opened for another reason.

After changing the directory ownership and permissions to:

chown zextras:zextras /opt/zimbra-migration/ap
chmod 700 /opt/zimbra-migration/ap

the same archive became readable by zextras and the import proceeded.

Server OS:

Carbonio Version:

Current Behavior:

The import fails with a generic FileNotFoundException / Permission denied when any parent directory in the archive path is not traversable by the user executing zmmailbox.

The error does not clearly identify that the problem is the parent directory permissions.

Expected Behavior:

Before starting a potentially long TGZ import, zmmailbox should validate that:

1. the archive exists;

2. it is a regular readable file;

3. every directory in the path can be traversed by the effective user.

If validation fails, the command should return an explicit error such as:

"Archive exists but cannot be accessed by user zextras: permission denied while traversing /opt/zimbra-migration/ap"

This would make migration failures much easier to diagnose.

Steps to Reproduce:

1. Create a directory accessible only by another user:
   mkdir -p /opt/zimbra-migration/test
chown ladmin:ladmin /opt/zimbra-migration/test
chmod 700 /opt/zimbra-migration/test

2. Place a valid Carbonio/Zimbra TGZ export inside it.

3. Set the TGZ owner to:
   zextras:zextras

4. Set the archive mode to:
   0600

5. Attempt a TGZ REST import using zmmailbox as the zextras user.

6. Observe zclient.CLIENT_ERROR / FileNotFoundException / Permission denied.

7. Change the parent directory to:
   zextras:zextras and mode 0700.

8. Repeat the exact same import.

9. The archive can now be accessed and the import proceeds.

Workaround:

Ensure that the zextras user has execute/traverse permission on every parent directory and read permission on the TGZ archive before starting the import.

Additional note:

I understand that the underlying filesystem permission denial is expected Unix behavior. The issue I am reporting is primarily the lack of a clear pre-flight permission check and diagnostic message in the Carbonio migration/import workflow.

Summary: Carbonio Docs Editor opens a blank page because nginx proxy temp directory is created with incorrect permissions

Affected Components: Carbonio Proxy / nginx / Carbonio Docs Editor

Description:

On a Carbonio CE installation, document preview worked correctly, but opening a DOCX file in Edit mode resulted in a completely blank editor window.

All Carbonio Docs-related services were running and reported as active.

The problem was eventually traced to the nginx proxy temporary directory:

/opt/zextras/data/tmp/nginx/proxy

Its ownership and permissions were:

nobody:zextras
mode 0755

With these permissions, the nginx worker handling the request did not have write access to the proxy temporary directory.

As a consequence, nginx could not correctly create/use a proxy temporary file while serving resources required by the Docs Editor. In the browser this manifested itself as the editor JavaScript bundle not being delivered correctly, while document preview continued to work.

This is especially confusing because all Docs services remain active and no obvious error is displayed in the Carbonio web interface.

After correcting the permissions/ownership of the nginx proxy temporary directory so that the nginx worker could write to it, the same document opened normally in the editor.

Server OS:

Carbonio Version:

Current Behavior:

1. Carbonio services are running.

2. DOCX preview works.

3. Clicking Edit opens the Docs Editor.

4. The editor remains blank.

5. Required web resources are not delivered correctly.

6. nginx reports a permission problem related to its proxy temporary directory.

7. /opt/zextras/data/tmp/nginx/proxy has ownership nobody:zextras and mode 0755.

Expected Behavior:

The Carbonio package installation, upgrade scripts, systemd/tmpfiles configuration, or Carbonio permission repair mechanism should always create the nginx temporary directories with ownership and permissions compatible with the actual nginx worker user.

A fresh installation or service restart should never leave:

/opt/zextras/data/tmp/nginx/proxy

in a state where nginx cannot write to it.

Steps to Reproduce:

1. Install/update Carbonio CE normally.

2. Verify that Carbonio Docs services are active.

3. Upload or select a DOCX document.

4. Open the document preview — preview works.

5. Click Edit.

6. Observe a blank editor window.

7. Inspect nginx logs and browser network requests.

8. Check:
   stat -c '%A %a %U:%G %n' /opt/zextras/data/tmp/nginx/proxy

9. Observe:
   nobody:zextras with mode 0755.

10. Correct the directory permissions/ownership so that the nginx worker can write to it.

11. Retry Edit.

12. The document editor now loads successfully.

Workaround:

Manually correct the ownership/permissions of:

/opt/zextras/data/tmp/nginx/proxy

so that the nginx worker process can create proxy temporary files.

Suggested Fix:

Please check the package post-installation scripts, systemd tmpfiles configuration and any Carbonio permission-fixing logic responsible for /opt/zextras/data/tmp/nginx/.

The directory should be automatically created with ownership and mode matching the nginx runtime user, and the correct permissions should survive:

• fresh installation;

• package upgrade;

• Carbonio restart;

• host reboot;

• permission repair procedures.

Impact:

This effectively disables document editing while giving the administrator the impression that the Docs infrastructure is healthy, because all related services remain active and document preview still works.

We are currently evaluating Carbonio CE as a possible replacement for our existing Zimbra servers, and security is one of the main reasons behind this evaluation.

Recently, several critical vulnerabilities affecting Zimbra have been actively exploited in the wild, including attacks resulting in server compromise and webshell deployment.

Since Carbonio shares or historically originated from some Zimbra components, I would like to better understand the security exposure of Carbonio CE regarding these vulnerabilities.

Specifically:

1. Which Zimbra components are still shared or derived from Zimbra in current Carbonio CE releases?
2. When a new Zimbra CVE is published, does Zextras evaluate whether the same vulnerable code exists in Carbonio?
3. Is there a public security advisory or CVE compatibility/mapping page where administrators can check whether a Zimbra CVE also affects Carbonio CE?
4. Are the recent Zimbra vulnerabilities that have been actively exploited against Internet-facing mail servers applicable to Carbonio CE?
5. In particular, are vulnerabilities involving Zimbra Web Client / Jetty, SOAP endpoints, file upload/path traversal, SSRF, or remote code execution potentially relevant to Carbonio because of shared components?
6. Does Zextras maintain the Zimbra-derived components independently and backport security fixes when necessary?

We currently operate Internet-facing mail infrastructure and have recently investigated malicious activity against Zimbra servers, including attempted exploitation and webshell deployment. Because of this, we want to make sure that migrating to Carbonio CE actually reduces our exposure rather than moving the same vulnerable components to a different platform.

It would be very useful if someone from the Zextras team could clarify the relationship between Zimbra CVEs and Carbonio CE security, particularly for current Carbonio CE releases.

Thank you.

I've been using the Zimbra OSE for a while now but with the lack of support anymore I am starting to get a little worried about continuing using it. 

I'm not sure if Carbonio features 2 factor authentication but that would be a good start.

Right now I am just trying to recover the Zimbra system as a kernel panic meant that some MySQL tables got damaged. Sadly trying to recover that, led me to loose the base OS too as I had performed a migration from CentOS which became a rolling distro to Rocky Linux which seems to track RHEL still.

I guess what I am asking here is advice on which way to turn with this?

Hopefully I will be able to recover the system and gain access to /opt where Zimbra is stored, even if it means a full rebuild 

However, I am checking the Zimbra to Carbonio migration documentation:

https://community.zextras.com/how-to-use-script-to-migrate-zimbra-to-carbonio-carbonio-ce/

but it doesn't say anything about MySQL.

My understanding is that Zimbra keeps it's information in a database rather then folder hierarchy like Mailbox format used to....

With a damaged mysql is it possible to migrate to Carbonio or do I need to fix that first?

I need to read up more on Carbonio in terms of what distro's it works on as I'm an Arch Linux guy personally but if Rocky is good then that's what I'll stick with though it means I would need an upgrade plan between versions

• Carbonio Release: 26.6.2
• OS: Ubuntu 24.04.4 LTS (Noble)
• Package: carbonio-admin-console-ui 0.15.2-1ubuntu
• Package: carbonio-appserver 4.5.1-1noble
• Affected page: https://<host>:6071/carbonioAdmin/manage/domains/<domain-id>/mailbox_quota

Summary

The domain "Mailbox Quota" page in the Admin Console never displays per-account quota usage. Two distinct frontend bugs were identified, both in carbonio-admin-console-ui (shell.mjs). The backend SOAP API (GetQuotaUsageRequest) works correctly in all tested scenarios.

Bug 1 — Routing fails on hard reload / direct navigation

Steps to reproduce:

1. Open the Admin Console and navigate normally (via UI clicks) to Domains → <domain> → Mailbox Quota. The page loads correctly.
2. Copy the resulting URL (e.g. /manage/domains/<domain-id>/mailbox_quota), or simply press F5 while on that page.
3. The page fails to render. No visible error banner, but the browser console shows:

shell.mjs:1016  No account name available for GetAccount request
shell.mjs:1012  No routes matched location
  "/manage/domains/<domain-id>/mailbox_quota"

Analysis: "No routes matched location" is a React Router warning, thrown when matchRoutes() is evaluated before the application has finished its client-side bootstrap (a well-known class of SPA bug: routes for some sections appear to be registered conditionally, likely gated behind an async data/feature-flag load that hasn't completed yet at the time of the initial route match on a hard reload or deep link).

Confirmed: navigating to the same page via in-app clicks (no reload) works without any routing error. Only direct navigation/reload of the deep link triggers the failure.

Impact: the page cannot be bookmarked, shared as a direct link, or reloaded — it must always be reached by clicking through the UI from the Admin Console home.

Bug 2 — Quota values not displayed (field name mismatch)

Steps to reproduce:

1. Navigate correctly (via UI clicks, avoiding Bug 1) to Domains → <domain> → Mailbox Quota.
2. The table renders 10 accounts per page (with working pagination), but the quota "used" / "limit" columns are always empty / zero. The account name column populates correctly.

Root cause (confirmed via static analysis of shell.mjs):

The real SOAP response from GetQuotaUsageRequest (captured from the browser's Network tab) looks like this:

{
  "Body": {
    "GetQuotaUsageResponse": {
      "account": ,
      "more": true,
      "searchTotal": 94
    }
  }
}

(more/searchTotal reflect normal, working pagination — 10 accounts per page — not a bug.)

The table row-mapping function in shell.mjs reads different, non-existent property names:

A6=(e,t,n=!1)=>{let r=[];return e.forEach(e=>{
  let=k6(e?.mailsQuotaUsed??0, e.mailsQuotaLimit??0, t),
  o={name:n?e?.accountName:e?.name, id:n?e?.accountId:e?.id, ...}

It reads e.mailsQuotaUsed / e.mailsQuotaLimit, which do not exist on the account objects returned by GetQuotaUsageRequest (the actual fields are used and limit). The ??0 fallback silently converts this to zero/empty instead of surfacing an error, while e.name (which does exist on the response object) renders correctly — matching the exact symptom observed: account names populate, quota values never do.

Suggested fix: update the mapping function to read used and limit (matching the actual GetQuotaUsageResponse schema) instead of mailsQuotaUsed / mailsQuotaLimit.

Evidence attached

• 2026-08-08_GetQuotaUsageRequest_evidence.xml — full SOAP/XML response for the domain's GetQuotaUsageRequest, obtained directly via zmsoap (bypassing the frontend, no pagination limit) — confirms the backend returns complete and correct data.
• 2026-08-08_GetQuotaUsageRequest_browser_paginated.json — actual JSON response captured from the browser's Network tab during a normal page load, showing the used/limit/more/searchTotal fields referenced above.

Trelawny