Orphaned search folders?
-
In my Kopano server log I see the following messages on every server start:
[notice ] Listening for SSL connections on port 237 [notice ] Listening for priority pipe connections on /var/run/kopano/prio.sock [notice ] Listening for pipe connections on /var/run/kopano/server.sock [notice ] Connection to database 'kopano' succeeded [notice ] Loading searchfolders [info ] Rebuilding search folder 6240779 [info ] Rebuilding search folder 6240781 [crit ] ECSearchFolders::Search() GetEntryListToObjectList failed: 0x80000015 [info ] Rebuilding search folder 6241386 [crit ] ECSearchFolders::Search() GetEntryListToObjectList failed: 0x80000015 [notice ] Startup succeeded on pid 15911I’d like to get rid of these messages but don’t know how. I already tried to run the
searchfolder_delete.pyscript and also altered it to search for folders with hierarchyid=6240781 etc. but it doesn’t find these folders. In the DB the items still exist:mysql> SELECT * FROM hierarchy WHERE id = 6240781; +---------+--------+------+-------+-------+ | id | parent | type | flags | owner | +---------+--------+------+-------+-------+ | 6240781 | 4 | 3 | 2 | 1 | +---------+--------+------+-------+-------+ 1 row in set (0.00 sec)Any suggestions?
-
Hi @tobydox
this statement:
@tobydox said in Unable to retrieve parents for relation groupmember: uid attribute not found:
Only the Kopano installation is based on a migrated Zarafa setup (where we updated the unique user attribute in the database to match the newly created users in the new domain).
makes me wonder what exactly you already modified in your database. your error message could be directly connected those changes.
-
@fbartels said in Orphaned search folders?:
makes me wonder what exactly you already modified in your database. your error message could be directly connected those changes.
We only updated the externid row in the users table to use UUIDs (from the entryUUID attributes in LDAP) instead of numerical UIDs. Nothing else was changed and the setup is working in production without any other issues for almost 2 months now :-)
-
does the following give a hint where these searchfolders might be located…?
import kopano for user in kopano.users(): print(user) for folder in user.root.folders(): print(folder, folder.hierarchyid) -
@mark-dufour said in Orphaned search folders?:
does the following give a hint where these searchfolders might be located…?
Unluckily not. It’s also not in the public store and I iterated over all items in all folders in all stores and none have the hierarchyids in question. Here are some more details directly from the DB:
mysql> SELECT * FROM tproperties WHERE hierarchyid=6240779; +----------+-------------+-------+------+-----------+----------------------+------------+------------+-------------+----------+------------+ | folderid | hierarchyid | tag | type | val_ulong | val_string | val_binary | val_double | val_longint | val_hi | val_lo | +----------+-------------+-------+------+-----------+----------------------+------------+------------+-------------+----------+------------+ | 4 | 6240779 | 12289 | 30 | NULL | WebApp Search Folder | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 12295 | 64 | NULL | NULL | NULL | NULL | NULL | 30611463 | 1282285952 | | 4 | 6240779 | 12296 | 64 | NULL | NULL | NULL | NULL | NULL | 30611463 | 1282285952 | | 4 | 6240779 | 13825 | 3 | 2 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 13826 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 13827 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 13834 | 11 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 13847 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 26168 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 26176 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 26177 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | | 4 | 6240779 | 26179 | 3 | 0 | NULL | NULL | NULL | NULL | NULL | NULL | +----------+-------------+-------+------+-----------+----------------------+------------+------------+-------------+----------+------------+ 12 rows in set (0.00 sec) -
which folder is the one with hierarchyid 4 (the parent of the searchfolder, according to the DB)…?
-
@mark-dufour said in Orphaned search folders?:
which folder is the one with hierarchyid 4 (the parent of the searchfolder, according to the DB)…?
mysql> SELECT * FROM hierarchy WHERE id=4; +----+--------+------+-------+-------+ | id | parent | type | flags | owner | +----+--------+------+-------+-------+ | 4 | 3 | 3 | 0 | 1 | +----+--------+------+-------+-------+ 1 row in set (0.00 sec) mysql> SELECT * FROM hierarchy WHERE id=3; +----+--------+------+-------+-------+ | id | parent | type | flags | owner | +----+--------+------+-------+-------+ | 3 | NULL | 1 | 0 | 1 | +----+--------+------+-------+-------+ 1 row in set (0.00 sec) mysql> SELECT * FROM users WHERE id=1; +----+----------+-------------+-----------+---------+ | id | externid | objectclass | signature | company | +----+----------+-------------+-----------+---------+ | 1 | NULL | 196610 | | 0 | +----+----------+-------------+-----------+---------+ 1 row in set (0.00 sec) -
I’d like to know the folder name as well (eg. ‘FIND_ROOT’)… what does the script I pasted above say about ‘hierarchy 4’…?
-
@mark-dufour said in Orphaned search folders?:
I’d like to know the folder name as well (eg. ‘FIND_ROOT’)… what does the script I pasted above say about ‘hierarchy 4’…?
It doesn’t appear as it’s the public store:
store = kopano.Server().public_store print store.hierarchyid, store.findroot.hierarchyidgives
3 6241326while iterating over all folders of the public store just returns our public contact folders and calendars.
-
ok, so that’s why searchfolder_delete.py didn’t see it…
do you see the folder(s) like this:
for folder in kopano.public_store.findroot.folders(): print folder, folder.hierarchyidif so you sholud be able to delete them as follows:
findroot.delete(folder) -
@mark-dufour said in Orphaned search folders?:
for folder in kopano.public_store.findroot.folders():
print folder, folder.hierarchyidThis just gives
Folder(WebApp Search Folder) 6241385 Folder(WebApp Search Folder1) 6241386 Folder(WebApp Search Folder10) 6248108 Folder(WebApp Search Folder11) 6248167 Folder(WebApp Search Folder12) 6248168 Folder(WebApp Search Folder13) 6248308 Folder(WebApp Search Folder14) 6246205 Folder(WebApp Search Folder15) 6248449 Folder(WebApp Search Folder16) 6246895 Folder(WebApp Search Folder17) 6246900 Folder(WebApp Search Folder18) 6246922 Folder(WebApp Search Folder19) 6250024 Folder(WebApp Search Folder2) 6241387 ....but the folder IDs in question are not listed.
-
hmm. maybe the folders are ‘hidden’ because of some rights issue… but it’s a bit difficult to debug like this. would it be possible to have a look around on your system perhaps, using SSH/teamviewer…?
-
@mark-dufour said in Orphaned search folders?:
TeamViewer would work. I’ll contact you via chat.
-
We tracked down the issue to search folders being erroneously being created in the root of the public store, probably orphans from the migration from Zarafa to Kopano where the public store did not have a FINDROOT. The script used for deleting these orphans:
import kopano for folder in kopano.Server().public_store.root.folders(): if folder.hierarchyid==NNNNNNN and folder.prop(PR_FOLDER_TYPE).value == 2: print folder.hierarchyid findroot.delete(folder)
