K-1537: Unable to move object user
I’ve just updated to version : 184.108.40.2067.cd49bb60b-0+150.1
I see a lot of these in my kopano-server.log
Thu Mar 28 17:00:04 2019: [error ] K-1537: Unable to move object user “email@example.com” (id=xx)
And i noticed this messages ( about 60 of them ) repeat in an interval of 15 min.
ps. The upgrade from 8.7.0 ( contributed version ) to 220.127.116.117 worked without any problems.
Just upgrade my other kopano community from 18.104.22.168xx to 22.214.171.1247.cd49bb60b-0+150.1 and here do dont have this problem.
Hi @thctlo - is the first one of your systems perhaps a multi-tenant setup?
Hi, yes correct, the one having this is a Multi-tentant setup with mysql (db) plugin.
Bob ( or Felix),
Any suggestions here because i cant find where this is coming from.
Its a repeative interval of 15 min .
i’ve looked at kopano-dbadmin, i dont see or can find anything about this when searching with google, except the site with the K-XXXX log entries.
i saw in : Kopano-dev/kopano-core/blob/master/provider/libserver/ECUserManagement.cpp
lines 2434 - 2447 the part what generates the error.
ps. line 2437 * the the … ( small typo )
How should in interper this message?
@thctlo we managed to reproduce the issue on our lab environment - the problem occurs when in a multitenant setup the sync (kopano-admin --sync) tries to determine whether a user (-mailbox) has been recreated in a different tentant or that a mailbox has simply been moved (trying to avoid delete + create and do a move instead).
The development team is looking into it - you can track progress in https://jira.kopano.io/browse/KC-1450.
It does not look like this error message affects normal operation, but it could cause trouble when mailboxes are actually being moved between tenants.
Thank you for reply back.
I’ll keep an eye on jira bug report.
And i see on my server it does not effect the users also, only logs are growing fast.
i’ll handle that.
kg last edited by kg
I have to add something on that.
It is occuring for us as well (Multi-Tenant Setup; LDAP Backend, mysql). But for us it’s actually causing issues, because it’s deleting the users and companies and the re-creating them (attaching the existing stores). If a user tries to login or sync via z-push or is receiving an email during this, it fails (user is unable to login or sync and mails are rejected).
So this is a very severe issue for us forcing us to use older versions of Kopano until it’s fixed.
Hai, any progress on this?
Because of you try to cleanup or reattach users then NO users can be resolved by kopano.
while the tests of the email adresses resolves fine with postmap.
Update, after running , in this order:
mail is delivered again in the user mailboxes, but this was a very strange thing here.
How did this happen.?
I did run : kopano-storeadm -O and removed some old stores and domain names. ( companies ).
kopano-storeadm -O Stores without users: Store GUID Guessed username Last login Store size Store type -------------------------------------------------------------------------------------------------------------- 934df4xxxxxxxxxxx09379ad3af0 vdom2.tld <unknown> 0.00 MB public bdcf0axxxxxxx6c8b58693c6f68e vdom1.tld <unknown> 0.00 MB public Users without stores: Username -------------------------------- # Multple username ( for me companies) are shown here as: vdom1.tld vdom2.tld but also Everybody
I dont touch this again untill this bug is fixed.
Rolleps last edited by
I want to push this problem too. We have a multi tenant setup and are also experiencing the problem like @kg.
Please fix this bug as soon as possible or tell us how to work around :)
We have a multi tenant setup and are also experiencing the problem like @kg.
Since you both share the same email domain, I would be surprised if that wouldn’t be the case ;-)
The workaround would be to use our official releases, especially if you are providing Kopano in a hosted environment to your customers I would strongly recommend to not rely on untested nightly builds.
i am also faceing this issue, being suspicious about those log entries.
Also the error came up with the upgrade to latest nightly version.
If there is any possibility to help speeding up solving this problem, please let me know.
If your kopano is crashing, you can use this as workaround.
systemctl edit kopano-server and add:
Thank you very much for your reply, but in this case the server is not crashing, it keeps running functional, but those mentioned log entries are flooding the log all 15 minutes.
There are no further informations in the log, also in log mode = debug.
If there is anything i can do, help fixing this bug, please let ne know.
informations in the log, also in log mode = debug.
disable kopano-monitor and kopano-statsd
That did help me in the log flood.
I got my kopano stable running again, but i disabled everything i didnt need.
Thanks, sounds like a good plan to get the log clean again as workaround, until the bug is fixed.
But in long term i would like to fix the problem itself, so if i can do anything to support this, please let me know.
Just to keep this thread complete on what im doing in my DB.
this database also suffert from the problem.
SQL Failed: Duplicate key name ‘tmptag’, Query: “ALTER TABLE properties ADD INDEX tmptag (tag)”
after a look at git : f43e00622a9624e31b58c280058c2bb6580e6be2
im gambled that this would help me to fix this problem.
so my steps,
While everything is running.
mysql -u root use kopano; ALTER TABLE properties drop INDEX tmptag; ALTER TABLE tproperties drop INDEX tmptag; ALTER TABLE mvproperties drop INDEX tmptag; ALTER TABLE indexedproperties drop INDEX tmptag; ALTER TABLE singleinstances drop INDEX tmptag; ALTER TABLE lob drop INDEX tmptag; \q; systemctl restart kopano-server kopano-dbadm k-1216
which cleared the INDEX, removed the error, make kopano-server do it thing, and re-added the INDEX with kopano-dbadm.
Can someone confirm these steps if i did not miss anything here.
At least, i happy to see these messages, are gone.
Fri May 3 12:02:04 2019: [error ] 0x7fbc8365c890: SQL Failed: Duplicate key name 'tmptag', Query: "ALTER TABLE properties ADD INDEX tmptag (tag)" Fri May 3 12:02:04 2019: [error ] KDatabase::I_Update() query failed: "Duplicate key name 'tmptag'", query: ALTER TABLE properties ADD INDEX tmptag (tag)
hm, i’ve tried to update today also .
From 126.96.36.1991 to 188.8.131.526.529d71bca-0+193.1
kopano-server still crashes if you check the users/group/company list.
if this is still enabled in server.cfg
user_safe_mode = yes
set to no, kopano-server does not crash.
im still not seeing my last added company and user, disapeared again.
and im sure thats related to :
Fri May 3 14:03:56 2019: [info ] Auto-deleting company 1353 from external source
Any suggestion to remove that manual from the DB? or how can i find that.
gduran last edited by gduran
It took me more than a day but I’ve found a workaround to this problem while setting up a brand new install to avoid corrupting real data.
Anyway, I also stumbled on the “K-1537: Unable to move object user” issue. Moreover I also got “K-1537: Unable to move object security group” on top of that after a while. After investigating closely all the log entries I all of a sudden got an idea. Eureka!!!
The workaround is as follows and I bet this will also will help the dev-team:
I all the time noticed that the username in the log looked like firstname.lastname@example.orgExample Ltd. So the company name was added too.
I renamed all the company names in my ldap tree to the FQDN. i.e. renamed “Example Ltd” into “example.com”.
Changed loginname_format into just loginname_format = %u in the server.cfg.
Stopped kopano-server service and dropped all the tables and started the kopano-server service. (Could do this as I was starting from scratch. Next I will try to apply it to a life database using the kopano-dbadm tools although I experienced also odd behaviour as it broke the relations between groups and companies several times while figuring out what the problem was but that maybe was caused by the fact of the K-1537 error.)
executed kopano-admin --list-companies, kopano-admin --list-groups, kopano-admin --list-users and checked the users table which looked OK.
Note: Another problem I ran into is that kopano-cli --list-companies works but kopano-cli --list-groups, kopano-cli --list-users don’t!!! Another bug?
After the above I’m able to login using the email address as username and works like charm. Obviously this is not a permanent solution but I hope that the dev-team understands what to look for. Please let me know when this bug is ironed out…
Next day edit:
Maybe cheered too early! Although I was (and still am) able to login after the above exercise nasty log entrees keep on coming:
1) K-1515: Object not found unknown user “example.com”: example.com not found in LDAP:
This is repeated for all 6 defined companies in the LDAP tree. (example.com, example2.com, example3.com, example4.com, example5.com, example6.com). Though these are defined as objectClass: kopano-company. Does Kopano thinks these are users?
2) K-1537: Unable to move object user “email@example.com” (id=19):
Only for this user as only one user is defined.
Just wanted to mention that the latest nightly build solves the problem, error log is clean now.
Thanks to all suggestions and the dev-team for fixing this bug.