Hi @zgokan ,
you can find the general debugging information for z-push at https://wiki.z-hub.io/display/ZP/Debugging
Hi @robertwbrandt ,
yes the packages are putting the dagent plugins into this directory. I’d recommend only to mount those directories if you really need them (instead of mounting them read-only).
Hello @leroyk2 ,
there is a more recent version available of kopano core, please update to the last version https://documentation.kopano.io/kopano_changelog/kc.html#kopano-core-8-4-3-8-4-3-4.
Since you are running a supported build I would suggest following this up with our support if the error persists.
I’m stuck with my problem, too,
i’ve answered your question in https://forum.kopano.io/topic/804/migrate-kopano-to-pst/4
Any ideas what might be wrong?
could be a bug in webapp, since in your own store you should always have all possible permissions (you are the owner of your own store). if you want to go through the route of exporting and reimporting i’d rather recommend to do this with
kopano-backup. when running this you should then add the option
--skip-meta to not export/apply custom permissions.
Maybe there is an error in kopano and search result should be the “member” attribute?
you can define which attributes kopano queries from the ldap. you can find the default values in
/usr/share/kopano/ldap.openldap.cfg, any modifications to the defaults should be done in the
By default the following values are used:
# Optional, default = member # Active directory: member # LDAP: memberUid ldap_groupmembers_attribute = memberUid # Optional, default = text # Active directory: dn # LDAP: text ldap_groupmembers_attribute_type = text # The attribute of the user which is listed in ldap_groupmember_attribute # Active directory: empty, matching DNs # LDAP: uid, matching users in ldap_loginname_attribute ldap_groupmembers_relation_attribute = uid
Hi @bringha ,
if you’d hardlinked you attachments, you’d (hopefully) remember.
Is it possible to rebuild somehow the attachment directory
with the exception of these rfc822 messages everything is stored only once, so there is no real use of “rebuilding” the attachment directory (since for all the regular attachments there is nothing to rebuild from). As far as I remember there is a mapi attribute (PR_EC_IMAP_EMAIL) that stores a relation to the message. deleting the relation should also delete the object from the disk (which means you could then theoretically run the optimize-imap script again).
Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.