@divB said in Suffering from sync loops: Try a different mail app. i have seen simular things on android. due to… i still have one zarafa 6.30 running with an old z-push. I also notice with some apps, that if they have a mail and contacts and callendar, you need to install all of the same supplier. 0x8004010F - code: 12, if its the same as on a real exchange, disable GAB in z-push is worth a try. or create one that the use can access. if in the mail app, an option exist about offline adress books, disable it. A few suggestion you could try, to keep it running, but upgrading is the best option.

Thanks! a note is the INSTALL should be sufficient then. ;-)

Hi @amaccuish, there have been some fixes and also more logging. Please update to the latest master branch version. @june @white-eagle thanks for reporting the umlaut issue. Unfortunately I didn’t have time to debug it more extensively yet. Manfred

ok, de deliver problems are happening due to missing “kopano-group” entries in AD. changing the ldap queries to “group” fixed it.

@jengelh said in howto create company?: kopano-admin --create-company companyname.tld. Ow, i tried that also. Unable to create company: "companyname.tld" not found Using the -v option (possibly multiple times) may give more hints. user@core:~$ sudo kopano-admin --create-company companyname.tld -v Unable to create company: "companyname.tld" already exists Using the -v option (possibly multiple times) may give more hints. user@core:~$ sudo kopano-admin --create-company companyname.tld -vvvv Unable to create company: "companyname.tld" already exists Using the -v option (possibly multiple times) may give more hints. user@core:~$ sudo kopano-admin --create-company companyname.tld -v -v -v Unable to create company: "companyname.tld" already exists Using the -v option (possibly multiple times) may give more hints. Unable to create company: “companyname.tld” not found Using the -v option (possibly multiple times) may give more hints. sudo kopano-admin --list-companies|grep companyname returns no ouput. Running : 8.7.84.74.1605530ff-0+135.1 with mariadb as backend.

hmm. that resulted in 2019-11-11T13:22:39.572895: [kopano-dagent|T14201] [=======] LMTP service will now exit 2019-11-11T13:22:39.609848: [kopano-dagent|T2766] [=======] Starting kopano-dagent version 8.7.85 (pid 2766 uid 999) (LMTP mode) 2019-11-11T13:22:39.610073: [kopano-dagent|T2766] [warning] K-1558: Unable to limit socket 0.0.0.0%lo:2003 to lo: Operation not permitted 2019-11-11T13:22:39.610118: [kopano-dagent|T2766] [warning] K-1558: Unable to limit socket [::]%lo:2003 to lo: Operation not permitted Updated… If you run kopano-dagent.service with overrides. remove the file with : LimitNOFILE= systemctl daemon-reload systemctl start kopano-dagent And it starts as it should.

Thanks for the report. Fixed in https://stash.kopano.io/projects/KWM/repos/kwmserver/commits/d0411f38fa1cb9dd9f6f8e9b1289518e1d7b3323 and will be in the next release.

Hi Walter, yes, you’re right. I think I must have had “tomatoes on my eyes”. ;-) Thanks!

Hi, I am having the same problem and using sophos utm. Can you tell me what you have changed in the utm to get it working? Thank you very much Tobi

Hi @sbauhaus, the issue came back a while ago, but has since been resolved.

Thanks, helped for most mailboxes but one public folder. In this folder no mail arrives despite to: ==> kopano/dagent.log <== Fri Nov 8 13:24:30 2019: [error ] WARNING: setrlimit(RLIMIT_NOFILE, 8192) failed: Operation not permitted. You will only be able to connect up to 4096 sockets. Either start the process as root, or increase user limits for open file descriptors. ==> mail.log <== Nov 8 13:24:30 kopano postfix/pipe[15798]: 442111140E90: to=<xxxx@example.com>, relay=kopano, delay=0.23, delays=0.05/0.01/0/0.17, dsn=2.0.0, status=sent (delivered via kopano service) Nov 8 13:24:30 kopano postfix/qmgr[1470]: 442111140E90: removed Mail to all other public folders gets delivered.

I read this thread, which did not help me. The problen is the script checks in the new version only on UTF-8 if "UTF-8" not in encoding: the old version checks both: if "UTF-8" not in encoding and "UTF8" not in encoding: No idea why this was removed. The next problem is that python 3 is expected to run. Under CentOS 6 python 2.6 is running. I have now change the script for CENTOS 6. If someone needs them: localize-folder-swt.py

Thanks @genesis74, I have also found that setting, but was not sure if that’s the correct place to fix it. Thanks

Hi marty, thanks for the quick response! So I do not need to do further testing, just have to wait for the fix… ;-)

The 1st error is independent of KC-1447 and has been recurring since spamd commissioning: 2019-11-07 12:01:19,592 - spamd - ERROR - Traceback (most recent call last): File "/usr/lib/python3/dist-packages/kopano/property_.py", line 197, in prop sprop = HrGetOneProp(mapiobj, proptag) File "/usr/lib/python3/dist-packages/MAPI/Defs.py", line 52, in HrGetOneProp raise MAPI.Struct.MAPIError.from_hresult(props[0].Value) MAPI.Struct.MAPIErrorNotFound: MAPI error 8004010F (MAPI_E_NOT_FOUND) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/kopano/log.py", line 103, in log_exc try: yield File "/usr/lib/python3/dist-packages/kopano_spamd/__init__.py", line 69, in update if item.message_class != 'IPM.Note': # TODO None? File "/usr/lib/python3/dist-packages/kopano/item.py", line 351, in message_class return self._get_fast(PR_MESSAGE_CLASS_W, must_exist=True) File "/usr/lib/python3/dist-packages/kopano/properties.py", line 118, in _get_fast return self.prop(proptag).value File "/usr/lib/python3/dist-packages/kopano/properties.py", line 42, in prop proptype=proptype) File "/usr/lib/python3/dist-packages/kopano/property_.py", line 206, in prop raise NotFoundError('no such property: %s' % REV_TAG.get(proptag, hex(proptag))) kopano.errors.NotFoundError: no such property: PR_MESSAGE_CLASS_W

Made various fixes to the “Out of Office (OOF) for another user” feature. Including fixes for an admin to set OOF and we lowered the required permissions for a user, now set to the “Secretary” profile. This fix was from 3.5.11 and not from 3.5.12 but I’ve just now tried it in 3.5.12 and it indeed seems to work fine now. Admin can now set OOF for the users - very important feature. Thank you for fixing this!

that works with: python3 manage_recipients… For Information: running system is Univention 4.4.1 errata 234

@sbsadmin @taquionbcn That ‘hanging’ issue is under investigation by a developer.

@davodego Not yet via widgets