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).
@rworobel actually when working with Univention there are some other tools available for upgrades. You could for example log into the Univention management console. there you should also get a message about package updates (and most importantly the pending update to 4.2).
But if you want to stay on 4.1 that is probably fine as well (for the moment at least).
if no backend provider is specified z-push will automatically choose one from the installed backends, so if you only install the kopano backend you are safe with just leaving this empty.
Hello @powercommy ,
we had some server troubles over the weekend with the system hosting the atlassian stack for z-hub.io. The system is now back online. You can find our contribution guidelines at https://wiki.z-hub.io/display/ZP/Development+guidelines
Hi @rworobel ,
if you have a subscription you could follow https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server (page offline at the moment because of server troubles, should be online rather soonish).
The only thing to have in mind here is that if you manually update on ucs 4.1, you could run into issues when during upgrade to ucs 4.2.
HI @rworobel ,
if you have a subscription upgrading is as simple as adding our repositories to your sources.list and the doing an
apt-get update && apt-get upgrade.
If you don’t have a subscription you could follow the steos in https://documentation.kopano.io/kopanocore_administrator_manual/upgrading.html. Most importantly 4.1, 4.2 and 4.5 (since you’re on Ubuntu).
Hi @bringha ,
have you hardlinked the files in ´/var/lib/kopano/attachments´ in the past? When having imap enabled for a user the rfc822 mail will be stored in the attachment directory so that the gateway can deliver it directly to the client instead regenerating it from the mapi data.
Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.