This (zimbraMailSignatureMaxLength) is COS or account only attribute. You could check it on a test account first and then if you want you could apply it on COS level too. To implement it on the COS level the command structure is same as previous reference:

su - zextras
carbonio prov mc default zimbraMailSignatureMaxLength 524288

# carbonio prov mc COS_NAME zimbraMailSignatureMaxLength 524288

Though this does not require any service restart, but feel free to refresh your browser.

Let us know how it goes.

I would also like to have some kind of feedback. Tomorrow it's 2 months since I made this initial post, and so far nothing!

Regards,
Henrik

Gruesse
Michael

Thanks for the question. A few quick clarifications would be more useful for us:

1. Zimbra edition (Network or Open Source) and whether Zextras Suite is installed on top, including its version.

2. Whether Connect, Drive, and Docs are actually in use today, or just available.

Thanks for the report. The error about exceeding the signature size limit is the zimbraMailSignatureMaxLength cap kicking in. It defaults to 10240 bytes per signature.

Could you please try this and let us know the results:

su - zextras
carbonio prov ma user@example.com zimbraMailSignatureMaxLength 524288

@victorsina

The screenshot-not-appearing-on-destination is likely a separate issue.

For the Ctrl-V paste behavior on 26.3.0: the recommendation is to insert inline images using the toolbar Add inline image option, instead of pasting from the clipboard. The Add inline image path is the supported way to embed images for delivery to external clients like Gmail and Outlook. 

It is good that the connection-refused chain cleared after the reboot. The reboot appears to have cleared the stale service-discoverd checks that lingered after the .hcl was moved aside.

The user@999.service restart loop looks like a separate thing to me. On a healthy Carbonio CE box, this user manager stays dormant: I just checked our test box (UID 999 = carbonio-prometheus there) and user@999.service, user-999.slice, and user-runtime-dir@999.service are all inactive (dead) with no journal entries, even though six prometheus processes are running as that UID right now.

Still, the restart loop usually points to something explicitly opening a session for UID 999 (a cron job, a monitoring agent, or a leftover loginctl enable-linger). If you'd like to pin it down, journalctl -u user@999.service --since "10 min ago" is usually enough to spot the trigger. Otherwise the box is fine to keep using.