Do you have mailbox_list_index_very_dirty_syncs=yes? If yes, does the problem
go away if you run: doveadm -o mailbox_list_index_very_dirty_syncs=no mailbox
list -u $user
Alternatively, try doveadm force-resync -u $user '*'
Yet another possibility to try rm dovecot.list.index*
Also, there is this patch that possibly helps:
diff --git a/src/lib-storage/mail-storage.c b/src/lib-storage/mail-storage.c
index a4363fc73c..b42053bc1a 100644
--- a/src/lib-storage/mail-storage.c
+++ b/src/lib-storage/mail-storage.c
@@ -1557,11 +1557,7 @@ int mailbox_rename_nfc_forced(struct mailbox_list *list,
const char *vname_raw,
ret = mailbox_rename(box_old, box_new);
if (ret < 0 &&
- mailbox_get_last_mail_error(box_old) == MAIL_ERROR_NOTFOUND) {
- /* ignore */
- ret = 0;
- } else if (ret < 0 &&
- mailbox_get_last_mail_error(box_old) == MAIL_ERROR_EXISTS) {
+ mailbox_get_last_mail_error(box_old) == MAIL_ERROR_EXISTS) {
/* generate a new unique name */
guid_128_t guid;
guid_128_generate(guid);
@@ -1572,6 +1568,16 @@ int mailbox_rename_nfc_forced(struct mailbox_list *list,
const char *vname_raw,
box_new = mailbox_alloc(list, *vname_new_r, 0);
ret = mailbox_rename(box_old, box_new);
}
+ if (ret < 0 &&
+ mailbox_get_last_mail_error(box_old) == MAIL_ERROR_NOTFOUND) {
+ /* Source doesn't exist on disk anymore (e.g. backing store
+ already renamed externally while the list index still has
+ the old non-NFC entry). Treat as no-op rather than fail
+ the iteration: return the plain NFC name so the caller
+ doesn't expose the unique-suffix fallback name. */
+ *vname_new_r = vname_nfc;
+ ret = 0;
+ }
if (ret < 0)
*error_r = mailbox_get_last_error(box_old, NULL);
mailbox_free(&box_old);
> On 12. May 2026, at 15.43, Philip Iezzi via dovecot <[email protected]>
> wrote:
>
> Thanks Jan for reporting this. I also experience this Bug since having
> upgraded Dovecot 2.4.2 -> 2.4.3 on 2026-03-27, leading to such errors in
> mail.log:
>
> Error: Failed to rename mailbox 'INBOX/Zürich' for NFC normalization: Mailbox
> doesn't exist: INBOX/Zürich
>
> - Zürich (in above log line) uses a decomposed sequence: a plain u (U+0075)
> followed by a combining diaeresis (U+0308), which the renderer stacks on top.
> - Zürich (which we usually type) uses a precomposed character: ü is a single
> code point, U+00FC (LATIN SMALL LETTER U WITH DIAERESIS).
>
> Such errors lead to broken folder structure - the user is no longer able to
> list the whole folder structure (except INBOX) and on mail clients like
> Roundcube, all folders appear as no longer subscribed.
> Renaming the "ü" to "ü" fixes the problem. But I have a bunch of other
> customers which use such characters and in previous Dovecot versions <= 2.4.2
> this was never a problem.
>
> Is there any known issue / will this be addressed in the next minor version?
>
> Kind regards,
> Philip
>
>
>> On 5 May 2026, at 16:04, Jan Münnich via dovecot <[email protected]> wrote:
>>
>> Following up on my own thread in case anyone hits the same issue:
>>
>> The failed NFC rename in 2.4 left behind a duplicate mailbox with a 32-hex
>> GUID suffix, but only for mailboxes that had subfolders. So for every
>> affected name we ended up with two entries:
>>
>> Anträge
>> Anträge-e078d427706eda694b210000a386c91b
>>
>> The original kept its (broken) name with no message access, and the
>> GUID-suffixed sibling held the actual mail. Both showed up as real folders
>> in IMAP clients.
>>
>> I figured out from the source code that the failed rename hits a fallback
>> path that creates the GUID-suffixed sibling, but not what triggers the
>> failure in the first place. I also found a hidden option there that is not
>> listed in documentation, which works as a workaround to stop new
>> occurrences: 'mailbox_list_normalize_names_to_nfc = no'.
>>
>> Fix for already-affected mailboxes: for each one, create a temporary
>> ASCII-named replacement at the same hierarchy level, move the subfolders
>> into it, move messages from the GUID-suffixed mailbox into it, delete the
>> GUID-suffixed mailbox (the broken original then disappears), and rename the
>> replacement back to the original name. The final rename runs through the
>> regular code path (without NFC normalisation) and works fine.
>>
>> Kind regards,
>> Jan
>>
>>
>>> On 11 Apr 2026, at 17:25, Jan Münnich via dovecot <[email protected]>
>>> wrote:
>>>
>>> Hi,
>>>
>>> We just upgraded from 2.3 to 2.4.3 and are now getting errors like this for
>>> any mailbox with German umlauts in the name:
>>>
>>> "Error: Failed to rename mailbox 'Anträge' for NFC normalization: Mailbox
>>> doesn't exist: Anträge"
>>>
>>> The mailboxes work fine otherwise, doveadm mailbox status shows them with
>>> correct message counts. The errors show up on IMAP access but don't seem to
>>> break anything.
>>>
>>> We're using mdbox. On disk the directory is stored as mUTF-7:
>>>
>>> Antr&AOQ-ge
>>>
>>> doveadm mailbox list gives back the name with c3 a4 for the ä, which is
>>> already NFC. We double-checked with python3 unicodedata and it confirms the
>>> name is NFC. So it seems like dovecot is trying to rename something that
>>> doesn't need renaming, and then failing.
>>>
>>> Is there a way to turn off this automatic rename? Or is this a known issue
>>> with mdbox and mUTF-7 directory names?
>>>
>>> Any help would be appreciated to find out if this is a bug or a
>>> configuration issue on our side!
>>>
>>> Thanks,
>>> Jan
>>>
>>> _______________________________________________
>>> dovecot mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>
>> _______________________________________________
>> dovecot mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> dovecot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
