Hi, Quoting Albert Shih <Albert.Shih@xxxxxxxx>:
Hi everyone. One user with I don't know what, and I don't know how was able to create a recursive tree of mailbox: user.toto.mailbox1.mailbox2.mailbox1.mailbox2. ...etc user.toto.mailbox1.mailbox3.mailbox1.mailbox3. etc.. etc.. I was able to manually destroy almost all the mailboxes.....but few remain undeleteable...meaning I cannot see them with
did you see an error message? Or are there related errors in the logs?
cyradm + lm user.toto.* so for the user it's ok. But if I do a ctl_mboxlist -d
what do you see here. If it has "(null)" in the output it is a tombstone record, afaik it was added for syncronisation/backup to indicate that a mailbox did exist
but was removed "recently" There was an issue to create dokumentation for this feature but it is still open https://github.com/cyrusimap/cyrus-imapd/issues/2265If it is under DELETED.user.toto it is there to allow admins to restore deleted mailboxes
see "delete_mode:" in man imapd.conf
I can definitively see them. I was also unable to remove those mailboxes by ctl_mboxlist -d > list.json vi list.json + remove those mailboxes ctl_mboxlist -u < list.json
This was stupid. Sorry that i am blunt but any mailbox created/renamed/deleted acls changed between dumping the mboxlist and updating the mboxlist will most likely be lost and
create an inconsistency between mailboxes.db and the filesystem With the uuid Mailbox location, reconstruct might be able to fix some of the problems but i don't use uuid mailbox locations jet, so i am not sure.
At the end I do something mark «as not to do» such as systemctl stop cyrus-imapd ctl_mboxlist -d > list.json vi list.json + remove those mailboxes rm -rf MAILBOX/uuid/*/*/uniqueid of those mailboxes ctl_mboxlist -u < list.json -f /tmp/mailboxes.db mv /tmp/mailboxes.db /var/lib/cyrus chown cyrus:mail /var/lib/cyrus/mailboxes.db systemctl start cyrus-imapd
This is the safer way, but still if the problem is not visible/critical to the user, so that there is no need to rush, asking on the list for advise is the way to go, espacially if it is marked as "not to do"
now I don't see them anymore....piouff... But I'm now worry I introduce some inconsistency somewhere.
for the future some general tips. - Stoping Cyrus before you change/remove files. - Keeping a backup of files you change (e.g. mailboxes.db) - Moving the Files/Directories outside of the cyrus directories instead of removing them with "rm" You can delete them later if you have confirmed that there is no problem
Is they are any tool I can check every db and their relations to check everything is ok ?
check manpage for reconstruct. -- -------------------------------------------------------------------------------- Michael Menge Tel.: (49) 7071 / 29-70316 Universität Tübingen Fax.: (49) 7071 / 29-5912Zentrum für Datenverarbeitung mail: michael.menge@xxxxxxxxxxxxxxxxxxxx
Wächterstraße 76 72074 Tübingen
Attachment:
smime.p7s
Description: S/MIME-Signatur
------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Tb03cd1a701e8d6d4-Mb81a6309289ed7c59adc037b Delivery options: https://cyrus.topicbox.com/groups/info/subscription
