Advanced Administration Tasks#
In this section we describe and outline a few advanced tasks, providing quick directions to carry them out.
Component-based Access Control#
Carbonio uses a delegation mechanism to allow the principal administrator to assign roles and permission to other users with the purpose of sharing with them the administration tasks and duties, electing them as either Global or Delegated Administrator, who have different privileges to configure and manage these features.
In the context of the management of Anti-Virus and Anti-Spam functionalities, each Administrator, either Global or Delegated, can access with the personal account and be able to control and manage them, according to permissions granted.
Server-side Management of E-mails#
Carbonio's MTA (Postfix) receives e-mail by means of the SMTP protocol and forwards it to the correct e-mail queue according to the user’s username (this coincides with the user’s e-mail address). In case of an e-mail whose recipient is a distribution list (i.e., a mailing list), the e-mail is forwarded to each of the members of the list.
Additional rules can be created directly on Postfix from the CLI. Examples of restriction rules can be found directly in Postfix documentation, for example in Postfix Standard Configuration Examples. More examples, depending on the use case, can be found in the official Postfix documentation.
Server-side Attachment Management#
Global e-mail attachment settings allow you to specify global rules for handling attachments of an e-mail message.
You can set rules at COS-level and also for individual accounts. When attachment settings are configured in Global Settings, the global rule takes precedence over COS and Account settings.
A list of formats (extensions) can be created via CLI to restrict the attachments allowed.
Warning
All files whose extension is in the list will never reach the recipient.
For example, to block .exe
filex, use command
# carbonio prov mcf +zimbraMtaBlockedExtension "exe"
Hint
Only one format/extension at a time can be specified.
It is possible to limit both the size of a message and its attachment and their individual sizes.
The total size of the message can be set for each MTA server directly on the Carbonio Admin Panel, in the Tuning section under documentation).
(seeThe maximum size of each attachment can be set by the CLI for each
user, CoS, or domain issuing as the zextras
user
zextras$ carbonio prov ma alice@example.com zimbraFileUploadMaxSizePerFile 1048574
This command prevents Alice to sent an attachment larger that 10Mb.
Management of a COS#
Each account on Carbonio is assigned a COS, a global object that is not restricted to a particular domain or set of domains.
The COS assigned to an account determines the default attributes for that account and the features to be enabled or not for it. The COS controls mailbox quotas, message lifetime, password restrictions, attachment blocking, and server pool usage.
You can create and edit the classes of services via CLI and soon also via the new Carbonio Admin Panel, in which the tasks of COS management will feature an helpful wizard that guides the Administrator through the creation process.
# carbonio prov createCos {name} [attribute value ...]
All the attributes that need to be customised can be either added at
the end of the base command above as [ attribute value ]
pairs, or
at a later point with the following command:
# carbonio prov modifyCos {name} [attribute value ...]
S/MIME support#
S/MIME support for all users can be enabled using command
zextras$ carbonio config set global enableSmimeEncryption TRUE
Users will then be able to upload certificates to be used for S/MIME
signing; setting it to false
will prevent users from using the
feature.
Additionally, the command below enables the ability of the user to verify the S/MIME signature.
zextras$ carbonio prov mcf carbonioSMIMESignatureVerificationEnabled TRUE
The access the S/MIME Certificate Store from within their Settings
page, users need to supply a password, which is different from the
S/MIME certificate’s password. You can set various parameters of this
password from the CLI, by using the following command as the zextras
user
user.
zextras$ carbonio config set global \
encryptionPasswordPolicyAttribute <attribute> <value>
The list of all available attributes that can be customised can be retrieved using command
zextras$ carbonio config get global \
encryptionPasswordPolicyAttribute
The output of the above command is:
global
values
attribute encryptionPasswordPolicyAttribute
inheritedValue
minLength 8
maxLength 100
minUpperCase 1
minLowerCase 1
minDigits 1
minPunctuation 0
minAlphaChars 0
minPunctuationOrDigitChars 0
requireAlphanumeric true
allowedChars
allowedPunctuation
denyList
inheritedFrom default
isInherited true
modules
ZxCore
The attribute is available only at global level, meaning this password policy is the same for all configured domains, CoS, and user on the system.
Pending-setups#
This section describes the functionalities provided by pending-setups in Carbonio and explains when it is necessary to run or re-run it for its proper functioning.
Overview#
In a nutshell, pending-setups in Carbonio manages post-installation and configuration tasks that are required to finalise Carbonio's setup and to ensure that the services run correctly.
pending-setups is a wrapper around a collection of scripts,
provided by other packages and placed in the
/etc/zextras/pending-setups.d/
directory.
When invoked, pending-setups carries out these task:
Set up of authentication and security policies using service-discover
Securely store and manage credentials
Configure services to ensures all Carbonio components (e.g., Mail, Authentication, Video Server) are properly configured
Reload services to apply changes
When a script is successfully executed, it is moved to the
/etc/zextras/pending-setups.d/done
directory.
Running pending-setups#
Hint
All commands shown in this section must be executed as the
root
user.
Before executing the command, make sure that you retrieve the cluster
credential password, which is stored in file
/var/lib/service-discover/password
.
pending-setups can be invoked with the -a
option: in
this case, it simply reads all the scripts in the
/etc/zextras/pending-setups.d/
directory and executes them,
with the output showing the tasks it carries out.
Invoked with no options, it enters an interactive mode, showing a menu similar to:
You have 6 pending setups to run
0) carbonio-catalog.sh
1) carbonio-tasks.sh
2) carbonio-user-management.sh
3) carbonio-tasks-db-setup.sh
4) carbonio-files.sh
5) carbonio-files-db-setup.sh
a) execute all
q) quit
Please input your selection:
>
The initial list shows all the scripts that must be executed: enter the number corresponding to the script to launch it or chose either a to execute them all, or q to exit. In the latter case, however, it will not be possible to use Carbonio successfully, as it would miss a number of configurations.
If all scripts have been executed, the command will output:
There are no pending-setups to run. Exiting!
Why Running pending-setups Again#
There are a number of situations when you need to run
pending-setups again. In some of the following cases, the
script might have not been executed successfully, but nonetheless they
are moved under the /etc/zextras/pending-setups.d/done
, so
simply invoking pending-setups again will not suffice.
- After a failed setup or partial installation
-
If the initial pending-setups process fails or gets interrupted (e.g., due to a system crash, missing dependencies, or misconfigured services)
- After manually fixing a configuration issue
-
If you manually adjust configuration files, services, or permissions
- After upgrading Carbonio
-
If an update doesn’t fully apply
- After restoring from a backup or migrating to a new server
-
If you restore a Carbonio system from a backup or migrate it to a new server, some configurations might need to be re-applied to match the new environment
- When adding a new Carbonio Component
-
If you install a new Carbonio Component (e.g., Files, Chats), running pending-setups ensures that the new component is properly integrated into the system
- Debugging and troubleshooting
-
If a service is misbehaving or showing unexpected errors, re-running pending-setups can sometimes reapply missing configurations and fix the issue
How to Run pending-setups Again#
There are two options to execute a failed script.
The first one proves useful if you realise that multiple script have failed, or believe they have failed. In this case, the procedure is:
-
Copy the script from
/etc/zextras/pending-setups.d/done
back to the main directory# cp /etc/zextras/pending-setups.d/done/<script-name>.sh \ /etc/zextras/pending-setups.d/
Replace
<script-name>.sh
with the actual script name. -
Run the command
# pending-setups -a
The script will be executed again as part of the pending setups process, like described in Section Running pending-setups above
If you have only one script to execute, youcan run the script manually.
Navigate to the
/etc/zextras/pending-setups.d/done
directory
# cd /etc/zextras/pending-setups.d/done
Execute the script directly. For example, to execute carbonio-videoserver.sh
# bash carbonio-videoserver.sh
The script will immediately be executed
Carbonio and HTTP Proxy#
Many organisations operate within secured network environments where direct Internet access is restricted and blocked by firewall rules or corporate policies.
Using an HTTP proxy allows administrators to control and monitor outbound connections from the Carbonio server, ensuring that only approved services and destinations are accessible.
In a scenario like this, configuring an HTTP proxy is mandatory for
Carbonio to function properly: this can be achieved using the
zimbraHttpProxyURL
attribute as follows.
Note
All commands in this section must be executed as the zextras
user
user.
First, login to the any Node installing the Proxy and check the current configuration of the attribute.
zextras$ carbonio prov getConfig zimbraHttpProxyURL
If there is no output, Carbonio tries to use a direct connection to the Internet, which in the scenario depicted above does not work, so we need to configure the attribute as follows.
zextras$ carbonio prov modifyConfig zimbraHttpProxyURL http://proxy.example.com:8080
Replace http://proxy.example.com:8080
with the actual proxy that
needs to be used.
zextras$ carbonio prov modifyConfig zimbraHttpProxyURL http://username:password@proxy.example.com:8080
Replace http://username:password@proxy.example.com:8080
with
the correct values
Finally, restart the service.
Execute, as the zextras
user
zextras$ zmcontrol restart
Execute, as the root
user
# systemctl start/stop/restart carbonio-proxy.target
Execute, as the zextras
user
zextras$ zmcontrol restart
Execute, as the root
user
# systemctl start/stop/restart carbonio-proxy.target
Freshclam and HTTP Proxy#
Similarly to the scenario described in Section Carbonio and HTTP Proxy,
freshclam can not download the antivirus signatures if
Carbonio is placed behind a proxy. The solution is to put the proxy
information in the freshclam configuration template,
which is /opt/zextras/conf/freshclam.conf.in
.
Log in to the Node where the MTA AV/AS Component is installed and edit the file, by adding at the bottom the lines:
HTTPProxyServer proxy.example.com
HTTPProxyPort 8080
As the zextras
user, execute
zextras$ zmclamdctl restart
To verify that the new configuration is correct and the HTTP proxy is being used, check the log file
zextras$ tail -f /opt/zextras/log/freshclam.log
In the output you should find some lines similar to the following:
ClamAV update process started at Thu Mar 13 14:01:58 2025
Trying to retrieve CVD header from https://database.clamav.net/daily.cvd
OK
main database available for download (remote version: xx)
Testing database: '/opt/zextras/data/clamav/db/tmp.03d9f579e4/clamav-f220b006e75bbf945b40dd0f5b8a2f29.tmp-main.cvd' ...
Database test passed.
main.cvd updated (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
Trying to retrieve CVD header from https://database.clamav.net/bytecode.cvd
OK
If you have modified freshclam's configuration template
/opt/zextras/conf/freshclam.conf.in
, you will likely need
to edit it again after an upgrade, because upgrades often overwrite
configuration templates. Since Carbonio regenerates
freshclam.conf
from the template file, when Carbonio or
ClamAV updates, the template may be reset to default or overwritten
with a new version, losing any changes you made to it. In this
case, any custom modifications would be lost.
To make sure changes are preserved after an upgrade, create a backup of the template file
zextras$ cp /opt/zextras/conf/freshclam.conf.in /opt/zextras/conf/freshclam.conf.in.backup
After the upgrade, compare and restore changes
zextras$ diff /opt/zextras/conf/freshclam.conf.in.backup /opt/zextras/conf/freshclam.conf.in
If the output is empty, there is no difference between the new template and the backup, so freshclam will keep on working without issues. If you see any difference, you might want to restore the proxy settings, by following this procedure from the beginning or copying your backup file on the new template.
zextras$ cp /opt/zextras/conf/freshclam.conf.in.backup /opt/zextras/conf/freshclam.conf.in
Clean Activesync Status#
Background
In previous Carbonio releases, ActiveSync could (in some cases and
with specific clients) create large amounts of historical sync state
records in the mail_item
MySQL table. Over time, this caused:
Large table sizes
Slower queries and sync performance
Excessive storage use
Carbonio 25.9.0 improvements
Release 25.9.0 introduces features to optimize database growth and maintenance:
-
New manual index creation command
A new CLI command has been introduced:
zextras$ carbonio mobile createStateIndex
Creates an index on the ActiveSync table (required for new cleanup logic)
Execution time depends on the current table size (can be long on large installations)
Needs to be executed only once per infrastructure
-
New retention period parameter for PurgeMobileState command
doPurgeMobileState now supports a retention period parameter, allowing administrators to define the time window for keeping sync states.
Example:
zextras$ carbonio mobile doPurgeMobileState retention-period 90
Keeps sync states for a defined period (default: 90 days)
Deletes devices inactive beyond that window
-
Automatic Space Recovery
At the end of each purge task, a
VACUUM
operation is now executed on the database to reclaim physical storage space. -
Improved Sync Cleanup Logic
During ActiveSync operations, old statuses are now automatically removed.
This keeps the status table smaller and reduces long-term growth.
Important
This improvement only works if a new database index is created.
Admin Guidance
After upgrading to 25.9.0 or performing a new installation, to enable the improved cleanup logic, Administrators should run
zextras$ carbonio mobile createStateIndex
On a new installation with an empty database, this task completes quickly
On an already populated database execution time can be significantly longer. For this reason, it is strongly recommended to run the command during a period of low system load.
If your infrastructure includes multiple Mailstore & Provisioning Nodes, the command must be executed only once on a single Mailstore & Provisioning Node
Regularly use doPurgeMobileState retention-period <days> to keep sync states under control and storage usage optimised
zextras$ carbonio mobile doPurgeMobileState retention-period <days>
For automation, edit the crontab and configure it to run daily as the zextras
user
zextras$ zextras$ crontab -e
Scroll to the very end of the file (after the comment ZEXTRAS-END
-- DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZEXTRAS-START
) and
add:
45 23 * * * /opt/zextras/bin/carbonio mobile doPurgeMobileState > /dev/null 2>&1
This task will clear the state table every day at 23:45 (11:45 PM).
You can change the execution time by modifying the hour (23) and minute (45) values. Also in this case if your infrastructure includes multiple Mailstore & Provisioning Nodes, the command must be scheduled only on a single Mailstore & Provisioning Node, not on every Node.
Trust Self-Signed Certificates#
This guide explains how to configure Carbonio to trust either a self-signed certificate or a certificate signed by an internal Certificate Authority (CA) when connecting to a remote backend endpoint (e.g., S3-compatible storage or LDAP databases) protected by self-signed certificates.
For these connections to be successful and to avoid warnings and communication errors, it is mandatory to import the root or intermediate CA into:
The Operating System’s trust store, to allow system tools to trust the certificate
The Jetty keystore of Carbonio, to allow internal services, like
mailboxd
, to establish secure TLS connections without warnings or failures
To achieve these results, carry out this procedure on all Nodes that should access the backend. For example, if the remote endpoint is a Storage, carry out the procedure on all Nodes installing the Mailstore & Provisioning Component.
Before carrying out the procedure, please pay attention to the following points.
Commands. All commands must be executed as the
root
userCertificate file extension. Ensure the certificate file has extension
.crt
on Ubuntu systemsCertificate file permissions. The certificate file must be readable by the
zextras
userServices restart. The last step of the procedure requires to restart Carbonio services, otherwise the new configuration will not be used
Step 1. Obtain the CA Certificate
Ensure your CA certificate is in PEM format (we will call it
ca.pem
): if it is in a .crt
or .cer
format, convert it to
PEM format.
Step 2. Import the CA Certificate into the OS
This step ensures that all OS-level tools and libraries (e.g., curl
,
wget
, backup utilities) can trust the endpoint.
The file must have a .crt
extension.
# cp ca.pem /usr/local/share/ca-certificates/ca.crt
# update-ca-certificates
The file must have a .crt
extension.
# cp ca.pem /usr/local/share/ca-certificates/ca.crt
# update-ca-certificates
# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
Step 3. Import the CA Certificate into Carbonio
This step is mandatory to ensure that Carbonio’s internal Java-based services (Jetty) trust the certificate.
# chown zextras:zextras ca.pem
# /opt/zextras/bin/zmcertmgr addcacert ca.pem
If successful, the output will confirm that the certificate was added to the keystore.
Step 4. Restart the services.
Restart Carbonio services to apply the changes.
As the zextras
user
zextras$ zmcontrol restart
As the root
user
# systemctl restart carbonio-directory-server.target
# systemctl restart carbonio-appserver.target
# systemctl restart carbonio-mta.target
# systemctl restart carbonio-proxy.target
As the zextras
user
zextras$ zmcontrol restart
As the root
user
# systemctl restart carbonio-directory-server.target
# systemctl restart carbonio-appserver.target
# systemctl restart carbonio-mta.target
# systemctl restart carbonio-proxy.target