NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox)
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
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 <dovecot@dovecot.org> 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
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 <dovecot@dovecot.org> 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 <dovecot@dovecot.org> 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
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 <dovecot@dovecot.org> 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 <dovecot@dovecot.org> 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 <dovecot@dovecot.org> 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
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
Yes, I have mailbox_list_index_very_dirty_syncs=yes.
Unfortunately I cannot test the suggested solutions anymore though since I already fixed all folders by renaming them (with an automated script to a different name and then back to the original name in correct encoding). Maybe Philip can?
Kind regards, Jan
Hi Timo No, I don't have mailbox_list_index_very_dirty_syncs=yes, using default no value. I can no longer reproduce this problem since having upgraded from 2.4.3 to 2.4.4, no single "Error: Failed to rename mailbox '...' for NFC normalization" error since then. Previously, on Dovecot 2.4.3, the Errors also popped up on regular umlauts, even after renaming those characters to regular umlauts to make sure those were not represented as NFD. But on Dovecot 2.4.4 all good, without any further workarounds needed. May this be related to this changelog entry? - lib-storage: Auto-rename non-NFC subscription file entries to NFC on read. Kind regards, Philip
On 16 May 2026, at 13:53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
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 <dovecot@dovecot.org> 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 <dovecot@dovecot.org> 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 <dovecot@dovecot.org> 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi Timo No, I don't have mailbox_list_index_very_dirty_syncs=yes, using default no value. I can no longer reproduce this problem since having upgraded from 2.4.3 to 2.4.4, no single "Error: Failed to rename mailbox '...' for NFC normalization" error since then. Previously, on Dovecot 2.4.3, the Errors also popped up on regular umlauts, even after renaming those characters to regular umlauts to make sure those were not represented as NFD. But on Dovecot 2.4.4 all good, without any further workarounds needed. May this be related to this changelog entry? - lib-storage: Auto-rename non-NFC subscription file entries to NFC on read. Kind regards, Philip On 16 May 2026, at 13:53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote: 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 <dovecot@dovecot.org> 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/Zuerich' for NFC normalization: Mailbox doesn't exist: INBOX/Zuerich - Zuerich (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. - Zuerich (which we usually type) uses a precomposed character: ue 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 "ue" to "ue" 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 Muennich via dovecot <dovecot@dovecot.org> 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: Antraege Antraege-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 Muennich via dovecot <dovecot@dovecot.org> 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 'Antraege' for NFC normalization: Mailbox doesn't exist: Antraege" 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 ae, 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi everyone, we also hit this bug(?) last week. Like Jan, we were upgrading from 2.3 to 2.4.3. 'mailbox_list_index_very_dirty_syncs' is 'no' in our setup. After the update, folders with a 32-hex GUID suffix started to appear. The only thing that stopped it from spreading, was the setting 'mailbox_list_normalize_names_to_nfc = no'. I cleaned up the folders with a script, using the method Jan described. After Philip's encouraging comment, I upgraded one of our servers to 2.4.4 and removed 'mailbox_list_normalize_names_to_nfc = no' from its config. But the same error started to appear in the logs again: Error: Failed to rename mailbox 'Infos, Vertäge, etc' for NFC normalization: Mailbox doesn't exist: Infos, Vertäge, etc But there's a difference: No folder with a 32-hex GUID was suffix created. In the example from the log message above, there's still only one folder on disk, even after the error appeared: mdbox/mailboxes/Infos, Vert&AOQ-ge, etc The mails in the folder are still accessible, but it no longer appears as subscribed in Roundcube Mail. But for other folders, we again got the GUID-suffixed "copy", like in Dovecot 2.4.3. We switched back to 'mailbox_list_normalize_names_to_nfc = no' for now. So far, I failed to reproduce the issue on a different server with Dovecot 2.4.4. On this server, I can create (nested) folders with umlauts, put mails into them, etc. - The error never appears in the logs, everything works fine. I'm not sure what to do next. Regards, Michael On 5/17/26 23:34, Philip Iezzi via dovecot wrote:
Hi Timo No, I don't have mailbox_list_index_very_dirty_syncs=yes, using default no value. I can no longer reproduce this problem since having upgraded from 2.4.3 to 2.4.4, no single "Error: Failed to rename mailbox '...' for NFC normalization" error since then. Previously, on Dovecot 2.4.3, the Errors also popped up on regular umlauts, even after renaming those characters to regular umlauts to make sure those were not represented as NFD. But on Dovecot 2.4.4 all good, without any further workarounds needed. May this be related to this changelog entry? - lib-storage: Auto-rename non-NFC subscription file entries to NFC on read. Kind regards, Philip
On 16 May 2026, at 13:53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote: 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 <dovecot@dovecot.org> 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/Zuerich' for NFC normalization: Mailbox doesn't exist: INBOX/Zuerich
- Zuerich (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. - Zuerich (which we usually type) uses a precomposed character: ue 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 "ue" to "ue" 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 Muennich via dovecot <dovecot@dovecot.org> 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:
Antraege Antraege-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 Muennich via dovecot <dovecot@dovecot.org> 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 'Antraege' for NFC normalization: Mailbox doesn't exist: Antraege"
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 ae, 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Michael Goth .webflow GmbH Geschäftsführer: Andreas Schrei Wasserburger Straße 4 D - 83352 Altenmarkt a. d. Alz Amtsgericht Traunstein HRB 18537 E-Mail: mg@webflow.de Tel: +49 (0) 8621 - 99989 - 26 Fax: +49 (0) 8621 - 99989 - 28 Web: www.webflow.de Informationen zur Datennutzung und zu Ihren Betroffenenrechten finden Sie unter folgender URL: https://www.webflow.de/unternehmen/datenschutzerklaerung/
Hi, During the upgrade from Dovecot 2.3.21.1 (d492236fa0) to 2.4.4-5+debian12 (8b687aa65c), we noticed that this error also occurred in our environment. The error appears repeatedly in the log file. Unfortunately, we were not able to reproduce it manually. We tried many operations with the affected mailbox using our webmail frontend, but none of them triggered the error. More or less by accident, we found a simple way to reproduce it: "doveadm mailbox list -u USER -s" Without the "-s" option, the error does not occur. The attached information may be useful for debugging. It seems helpful because the problem can now be reproduced on demand. Maybe the "-s" code path (subscribed mailboxes) gives a hint where the problem comes from. Please see the attached observations and hex dumps for more details (the strace mailbox name comes from „strace doveadm mailbox list -u USER -s)“ : Regards, Jens ——————————————————————— Name from strace: Fu&Awg-hrerschein 00000000 46 75 26 41 77 67 2d 68 72 65 72 73 63 68 65 69 |Fu&Awg-hrerschei| 00000010 6e 0a |n.| 00000012 Name from filesystem (ls -Nd): F&APw-hrerschein 00000000 46 26 41 50 77 2d 68 72 65 72 73 63 68 65 69 6e |F&APw-hrerschein| 00000010 0a |.| 00000011 doveadm mailbox list -7 INBOX.F&APw-hrerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 0a |schein.| 00000017 doveadm mailbox list -7 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Führerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Führerschein INBOX.F&APw-hrerschein-6960360bc4b6476ae3362000ca608b0a doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Führerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Führerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 2d 36 39 66 32 35 33 31 30 63 |schein-69f25310c| 00000020 34 62 36 34 37 36 61 66 31 33 36 32 30 30 30 63 |4b6476af1362000c| 00000030 61 36 30 38 62 30 61 0a |a608b0a.| 00000038 doveadm mailbox list -8 INBOX.Führerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 0a |ein.| 00000014 doveadm mailbox list -8 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Führerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Führerschein doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Führerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Führerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 2d 38 31 62 35 61 30 32 34 63 34 62 36 |ein-81b5a024c4b6| 00000020 34 37 36 61 31 62 33 37 32 30 30 30 63 61 36 30 |476a1b372000ca60| 00000030 38 62 30 61 0a |8b0a.| 00000035 Von: Michael Goth via dovecot <dovecot@dovecot.org> Datum: Mittwoch, 20. Mai 2026 um 09:07 An: dovecot@dovecot.org <dovecot@dovecot.org> Betreff: Re: NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox) Hi everyone, we also hit this bug(?) last week. Like Jan, we were upgrading from 2.3 to 2.4.3. 'mailbox_list_index_very_dirty_syncs' is 'no' in our setup. After the update, folders with a 32-hex GUID suffix started to appear. The only thing that stopped it from spreading, was the setting 'mailbox_list_normalize_names_to_nfc = no'. I cleaned up the folders with a script, using the method Jan described. After Philip's encouraging comment, I upgraded one of our servers to 2.4.4 and removed 'mailbox_list_normalize_names_to_nfc = no' from its config. But the same error started to appear in the logs again: Error: Failed to rename mailbox 'Infos, Vertäge, etc' for NFC normalization: Mailbox doesn't exist: Infos, Vertäge, etc But there's a difference: No folder with a 32-hex GUID was suffix created. In the example from the log message above, there's still only one folder on disk, even after the error appeared: mdbox/mailboxes/Infos, Vert&AOQ-ge, etc The mails in the folder are still accessible, but it no longer appears as subscribed in Roundcube Mail. But for other folders, we again got the GUID-suffixed "copy", like in Dovecot 2.4.3. We switched back to 'mailbox_list_normalize_names_to_nfc = no' for now. So far, I failed to reproduce the issue on a different server with Dovecot 2.4.4. On this server, I can create (nested) folders with umlauts, put mails into them, etc. - The error never appears in the logs, everything works fine. I'm not sure what to do next. Regards, Michael On 5/17/26 23:34, Philip Iezzi via dovecot wrote:
Hi Timo No, I don't have mailbox_list_index_very_dirty_syncs=yes, using default no value. I can no longer reproduce this problem since having upgraded from 2.4.3 to 2.4.4, no single "Error: Failed to rename mailbox '...' for NFC normalization" error since then. Previously, on Dovecot 2.4.3, the Errors also popped up on regular umlauts, even after renaming those characters to regular umlauts to make sure those were not represented as NFD. But on Dovecot 2.4.4 all good, without any further workarounds needed. May this be related to this changelog entry? - lib-storage: Auto-rename non-NFC subscription file entries to NFC on read. Kind regards, Philip
On 16 May 2026, at 13:53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote: 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 <dovecot@dovecot.org> 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/Zuerich' for NFC normalization: Mailbox doesn't exist: INBOX/Zuerich
- Zuerich (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. - Zuerich (which we usually type) uses a precomposed character: ue 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 "ue" to "ue" 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 Muennich via dovecot <dovecot@dovecot.org> 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:
Antraege Antraege-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 Muennich via dovecot <dovecot@dovecot.org> 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 'Antraege' for NFC normalization: Mailbox doesn't exist: Antraege"
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 ae, 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Michael Goth .webflow GmbH Geschäftsführer: Andreas Schrei Wasserburger Straße 4 D - 83352 Altenmarkt a. d. Alz Amtsgericht Traunstein HRB 18537 E-Mail: mg@webflow.de Tel: +49 (0) 8621 - 99989 - 26 Fax: +49 (0) 8621 - 99989 - 28 Web: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webflow.de%2F&data=05%7C02%7Cjens.urban%40freenet.ag%7Cfabd00c4538547135cc708deb63e6887%7C7d95deb30bca4c9da61e1fd6c47ed60c%7C0%7C0%7C639148576313080380%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HZfOCPuHi7IvL%2Fx1XJHnqYrOuP5W4gfmC8zYXJCVamY%3D&reserved=0<http://www.webflow.de/> Informationen zur Datennutzung und zu Ihren Betroffenenrechten finden Sie unter folgender URL: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.webflow.de%2Funternehmen%2Fdatenschutzerklaerung%2F&data=05%7C02%7Cjens.urban%40freenet.ag%7Cfabd00c4538547135cc708deb63e6887%7C7d95deb30bca4c9da61e1fd6c47ed60c%7C0%7C0%7C639148576313099807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W6dpxhwFxjVlE%2BL8%2Fu4fRfEKecyNn74I7NMjNvRNOMQ%3D&reserved=0<https://www.webflow.de/unternehmen/datenschutzerklaerung/> _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Hi, During the upgrade from Dovecot 2.3.21.1 (d492236fa0) to 2.4.4-5+debian12 (8b687aa65c), we noticed that this error also occurred in our environment. The error appears repeatedly in the log file. Unfortunately, we were not able to reproduce it manually. We tried many operations with the affected mailbox using our webmail frontend, but none of them triggered the error. More or less by accident, we found a simple way to reproduce it: "doveadm mailbox list -u USER -s" Without the "-s" option, the error does not occur. The attached information may be useful for debugging. It seems helpful because the problem can now be reproduced on demand. Maybe the "-s" code path (subscribed mailboxes) gives a hint where the problem comes from. Please see the attached observations and hex dumps for more details (the strace mailbox name comes from "strace doveadm mailbox list -u USER -s)" : Regards, Jens ---------------------------------------------- Name from strace: Fu&Awg-hrerschein 00000000 46 75 26 41 77 67 2d 68 72 65 72 73 63 68 65 69 |Fu&Awg-hrerschei| 00000010 6e 0a |n.| 00000012 Name from filesystem (ls -Nd): F&APw-hrerschein 00000000 46 26 41 50 77 2d 68 72 65 72 73 63 68 65 69 6e |F&APw-hrerschein| 00000010 0a |.| 00000011 doveadm mailbox list -7 INBOX.F&APw-hrerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 0a |schein.| 00000017 doveadm mailbox list -7 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein INBOX.F&APw-hrerschein-6960360bc4b6476ae3362000ca608b0a doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 2d 36 39 66 32 35 33 31 30 63 |schein-69f25310c| 00000020 34 62 36 34 37 36 61 66 31 33 36 32 30 30 30 63 |4b6476af1362000c| 00000030 61 36 30 38 62 30 61 0a |a608b0a.| 00000038 doveadm mailbox list -8 INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 0a |ein.| 00000014 doveadm mailbox list -8 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 2d 38 31 62 35 61 30 32 34 63 34 62 36 |ein-81b5a024c4b6| 00000020 34 37 36 61 31 62 33 37 32 30 30 30 63 61 36 30 |476a1b372000ca60| 00000030 38 62 30 61 0a |8b0a.| 00000035 Von: Michael Goth via dovecot <dovecot@dovecot.org> Datum: Mittwoch, 20. Mai 2026 um 09:07 An: dovecot@dovecot.org <dovecot@dovecot.org> Betreff: Re: NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox) Hi everyone, we also hit this bug(?) last week. Like Jan, we were upgrading from 2.3 to 2.4.3. 'mailbox_list_index_very_dirty_syncs' is 'no' in our setup. After the update, folders with a 32-hex GUID suffix started to appear. The only thing that stopped it from spreading, was the setting 'mailbox_list_normalize_names_to_nfc = no'. I cleaned up the folders with a script, using the method Jan described. After Philip's encouraging comment, I upgraded one of our servers to 2.4.4 and removed 'mailbox_list_normalize_names_to_nfc = no' from its config. But the same error started to appear in the logs again: Error: Failed to rename mailbox 'Infos, Verta*ge, etc' for NFC normalization: Mailbox doesn't exist: Infos, Verta*ge, etc But there's a difference: No folder with a 32-hex GUID was suffix created. In the example from the log message above, there's still only one folder on disk, even after the error appeared: mdbox/mailboxes/Infos, Vert&AOQ-ge, etc The mails in the folder are still accessible, but it no longer appears as subscribed in Roundcube Mail. But for other folders, we again got the GUID-suffixed "copy", like in Dovecot 2.4.3. We switched back to 'mailbox_list_normalize_names_to_nfc = no' for now. So far, I failed to reproduce the issue on a different server with Dovecot 2.4.4. On this server, I can create (nested) folders with umlauts, put mails into them, etc. - The error never appears in the logs, everything works fine. I'm not sure what to do next. Regards, Michael On 5/17/26 23:34, Philip Iezzi via dovecot wrote:
Hi Timo No, I don't have mailbox_list_index_very_dirty_syncs=yes, using
default no
value. I can no longer reproduce this problem since having upgraded from
2.4.3 to
2.4.4, no single "Error: Failed to rename mailbox '...' for NFC normalization" error since then. Previously, on Dovecot 2.4.3, the Errors also popped up on regular umlauts, even after renaming those characters to regular umlauts to
make
sure those were not represented as NFD. But on Dovecot 2.4.4 all
good,
without any further workarounds needed. May this be related to this changelog entry? - lib-storage: Auto-rename non-NFC subscription file entries to NFC
on
read. Kind regards, Philip
On 16 May 2026, at 13:53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote: 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 <dovecot@dovecot.org> 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/Zuerich' for NFC
normalization:
Mailbox doesn't exist: INBOX/Zuerich
- Zuerich (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. - Zuerich (which we usually type) uses a precomposed character:
ue 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
clients like Roundcube, all folders appear as no longer
subscribed.
Renaming the "ue" to "ue" 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 Muennich via dovecot <dovecot@dovecot.org> 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:
Antraege Antraege-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 Muennich via dovecot <dovecot@dovecot.org> 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 'Antraege' for NFC
normalization:
Mailbox doesn't exist: Antraege"
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
ae,
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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Michael Goth .webflow GmbH Geschaeftsfuehrer: Andreas Schrei Wasserburger Strasse 4 D - 83352 Altenmarkt a. d. Alz Amtsgericht Traunstein HRB 18537 E-Mail: mg@webflow.de Tel: +49 (0) 8621 - 99989 - 26 Fax: +49 (0) 8621 - 99989 - 28 Web: [1]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webflow... Informationen zur Datennutzung und zu Ihren Betroffenenrechten finden Sie unter folgender URL: [2]https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.webflo... _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org References Visible links 1. http://www.webflow.de/ 2. https://www.webflow.de/unternehmen/datenschutzerklaerung/
Hi! back when we hit this issue, I did some more digging and I think I found the root cause of the problem: TLDR: After renaming a mailbox from non-NFC to NFC-form, the subscription is not updated from non-NFC to NFC. This constantly triggers a fallback code path which causes interesting side-effects. The details: In the beginning, the mdbox/subscriptions file contains an entry in non-NFC mUTF7: 'DA&Awg- KNATSCH' The directory in mdbox/mailboxes also has this non-NFC mUTF7 name: 'DA&Awg- KNATSCH'. As soon as an IMAP client lists the folders, Dovecot silently renames the non-NFC mailbox directory to its NFC form on disk, as seen in the logs with 'mail_debug = yes': Debug: Mailbox 'DÄ KNATSCH' renamed for NFC normalization In mdbox/mailboxes, the directory is now called 'D&AMQ- KNATSCH'. But the entry in mdbox/subscriptions is not updated and still contains the non-NFC form 'DA&Awg- KNATSCH'. The next time a client connects, it again tries to access the 'DA&Awg- KNATSCH' folder. Now Dovecot tries _again_ to rename 'DA&Awg- KNATSCH' into its NFC-form. But this fails, because the target directory 'D&AMQ- KNATSCH' already exists. This in turn triggers the fallback code path which now tries to rename 'DA&Awg- KNATSCH' into something like 'D&AMQ- KNATSCH-584c5a01303f196a26742c00911dccb7'. This also fails because the non-NFC source directory 'DA&Awg- KNATSCH' doesn't exist anymore. This error triggers the message we see in the logs: Error: Failed to rename mailbox 'DÄ KNATSCH' for NFC normalization: Mailbox doesn't exist: DÄ KNATSCH At this point, the folder shows up as unsubscribed in Roundcube. If I resubscribe in Roundcube, I can access the mails fine. The mdbox/subscriptions file now has two entries: DA&Awg- KNATSCH D&AMQ- KNATSCH So the root problem seems to be the non-NFC-entry in mdbox/subscriptions which doesn't get updated after renaming the mailbox to its NFC form. # List the mailboxes of the user to trigger a rename of the directory $> bin/doveadm mailbox list -u non-nfc-user ... DÄ KNATSCH ... # Resubscribe with the output from the above command. This adds the correct subscription. $> bin/doveadm mailbox subscribe -u non-nfc-user "DÄ KNATSCH" I tried to unsubscribe the non-NFC form, but that only unsubscribes the NFC form. Apparently the non-NFC form gets normalized to NFC before unsubscribing. But wait, there's more! As long as the non-NFC entry stays in mdbox/subscriptions, we hit the fallback codepath whenever something iterates over the mailboxes. Because of this, Dovecot does not report the non-NFC mailbox name in its subscription list, but the one with the GUID-suffix: $> doveadm mailbox list -s -u non-nfc-user doveadm(non-nfc-user): Error: Failed to rename mailbox 'DÄ KNATSCH' for NFC normalization: Mailbox doesn't exist: DÄ KNATSCH DÄ KNATSCH <-- This is the NFC subscription ... DÄ KNATSCH-a0fdd806a250196a6aaa2c00911dccb7 <-- the broken non-NFC subscription Roundcube just seems to ignore the GUID one because no such mailbox exists. So I think updating the mailbox name to NFC should also update any matching subscriptions of the user. Otherwise, the subscription gets lost and we get constant errors in the logs. HTH, Michael On 7/3/26 15:55, Jens Urban via dovecot wrote:
Hi, During the upgrade from Dovecot 2.3.21.1 (d492236fa0) to 2.4.4-5+debian12 (8b687aa65c), we noticed that this error also occurred in our environment. The error appears repeatedly in the log file. Unfortunately, we were not able to reproduce it manually. We tried many operations with the affected mailbox using our webmail frontend, but none of them triggered the error. More or less by accident, we found a simple way to reproduce it: "doveadm mailbox list -u USER -s" Without the "-s" option, the error does not occur. The attached information may be useful for debugging. It seems helpful because the problem can now be reproduced on demand. Maybe the "-s" code path (subscribed mailboxes) gives a hint where the problem comes from. Please see the attached observations and hex dumps for more details (the strace mailbox name comes from "strace doveadm mailbox list -u USER -s)" : Regards, Jens
---------------------------------------------- Name from strace: Fu&Awg-hrerschein 00000000 46 75 26 41 77 67 2d 68 72 65 72 73 63 68 65 69 |Fu&Awg-hrerschei| 00000010 6e 0a |n.| 00000012 Name from filesystem (ls -Nd): F&APw-hrerschein 00000000 46 26 41 50 77 2d 68 72 65 72 73 63 68 65 69 6e |F&APw-hrerschein| 00000010 0a |.| 00000011 doveadm mailbox list -7 INBOX.F&APw-hrerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 0a |schein.| 00000017 doveadm mailbox list -7 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein INBOX.F&APw-hrerschein-6960360bc4b6476ae3362000ca608b0a doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 26 41 50 77 2d 68 72 65 72 |INBOX.F&APw-hrer| 00000010 73 63 68 65 69 6e 2d 36 39 66 32 35 33 31 30 63 |schein-69f25310c| 00000020 34 62 36 34 37 36 61 66 31 33 36 32 30 30 30 63 |4b6476af1362000c| 00000030 61 36 30 38 62 30 61 0a |a608b0a.| 00000038 doveadm mailbox list -8 INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 0a |ein.| 00000014 doveadm mailbox list -8 -s doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein doveadm(xx@xx): Error: Failed to rename mailbox 'INBOX.Fuehrerschein' for NFC normalization: Mailbox doesn't exist: INBOX.Fuehrerschein 00000000 49 4e 42 4f 58 2e 46 c3 bc 68 72 65 72 73 63 68 |INBOX.F..hrersch| 00000010 65 69 6e 2d 38 31 62 35 61 30 32 34 63 34 62 36 |ein-81b5a024c4b6| 00000020 34 37 36 61 31 62 33 37 32 30 30 30 63 61 36 30 |476a1b372000ca60| 00000030 38 62 30 61 0a |8b0a.| 00000035 Von: Michael Goth via dovecot <dovecot@dovecot.org> Datum: Mittwoch, 20. Mai 2026 um 09:07 An: dovecot@dovecot.org <dovecot@dovecot.org> Betreff: Re: NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox)
Hi everyone,
we also hit this bug(?) last week. Like Jan, we were upgrading from 2.3 to 2.4.3. 'mailbox_list_index_very_dirty_syncs' is 'no' in our setup.
After the update, folders with a 32-hex GUID suffix started to appear. The only thing that stopped it from spreading, was the setting 'mailbox_list_normalize_names_to_nfc = no'.
I cleaned up the folders with a script, using the method Jan described.
After Philip's encouraging comment, I upgraded one of our servers to 2.4.4 and removed 'mailbox_list_normalize_names_to_nfc = no' from its config. But the same error started to appear in the logs again:
Error: Failed to rename mailbox 'Infos, Verta*ge, etc' for NFC normalization: Mailbox doesn't exist: Infos, Verta*ge, etc
But there's a difference: No folder with a 32-hex GUID was suffix created. In the example from the log message above, there's still only one folder on disk, even after the error appeared:
mdbox/mailboxes/Infos, Vert&AOQ-ge, etc
The mails in the folder are still accessible, but it no longer appears as subscribed in Roundcube Mail.
But for other folders, we again got the GUID-suffixed "copy", like in Dovecot 2.4.3.
We switched back to 'mailbox_list_normalize_names_to_nfc = no' for now.
So far, I failed to reproduce the issue on a different server with Dovecot 2.4.4. On this server, I can create (nested) folders with umlauts, put mails into them, etc. - The error never appears in the logs, everything works fine.
I'm not sure what to do next.
Regards, Michael
On 5/17/26 23:34, Philip Iezzi via dovecot wrote: > Hi Timo > No, I don't have mailbox_list_index_very_dirty_syncs=yes, using default no > value. > I can no longer reproduce this problem since having upgraded from 2.4.3 to > 2.4.4, no single "Error: Failed to rename mailbox '...' for NFC > normalization" error since then. > Previously, on Dovecot 2.4.3, the Errors also popped up on regular > umlauts, even after renaming those characters to regular umlauts to make > sure those were not represented as NFD. But on Dovecot 2.4.4 all good, > without any further workarounds needed. > May this be related to this changelog entry? > - lib-storage: Auto-rename non-NFC subscription file entries to NFC on > read. > Kind regards, > Philip > > On 16 May 2026, at 13:53, Timo Sirainen via dovecot > <dovecot@dovecot.org> wrote: > 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 > <dovecot@dovecot.org> 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/Zuerich' for NFC normalization: > Mailbox doesn't exist: INBOX/Zuerich > > - Zuerich (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. > - Zuerich (which we usually type) uses a precomposed character: ue 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 "ue" to "ue" 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 Muennich via dovecot > <dovecot@dovecot.org> 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: > > Antraege > Antraege-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 Muennich via dovecot > <dovecot@dovecot.org> 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 'Antraege' for NFC normalization: > Mailbox doesn't exist: Antraege" > > 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 ae, > 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 -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-leave@dovecot.org > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-leave@dovecot.org > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-leave@dovecot.org > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-leave@dovecot.org > > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-leave@dovecot.org
-- Michael Goth
.webflow GmbH
Geschaeftsfuehrer: Andreas Schrei Wasserburger Strasse 4 D - 83352 Altenmarkt a. d. Alz
Amtsgericht Traunstein HRB 18537
E-Mail: mg@webflow.de Tel: +49 (0) 8621 - 99989 - 26 Fax: +49 (0) 8621 - 99989 - 28 Web: [1]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webflow...
Informationen zur Datennutzung und zu Ihren Betroffenenrechten finden Sie unter folgender URL: [2]https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.webflo...
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
References
Visible links 1. http://www.webflow.de/ 2. https://www.webflow.de/unternehmen/datenschutzerklaerung/
_______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- Michael Goth .webflow GmbH Geschäftsführer: Andreas Schrei Wasserburger Straße 4 D - 83352 Altenmarkt a. d. Alz Amtsgericht Traunstein HRB 18537 E-Mail: mg@webflow.de Tel: +49 (0) 8621 - 99989 - 26 Fax: +49 (0) 8621 - 99989 - 28 Web: www.webflow.de Informationen zur Datennutzung und zu Ihren Betroffenenrechten finden Sie unter folgender URL: https://www.webflow.de/unternehmen/datenschutzerklaerung/
On 6. Jul 2026, at 8.39, Michael Goth via dovecot <dovecot@dovecot.org> wrote:
So I think updating the mailbox name to NFC should also update any matching subscriptions of the user. Otherwise, the subscription gets lost and we get constant errors in the logs.
I thought this was already fixed, but looks like accidentally the test was using mailbox_list_utf8=yes. With the default =no it was broken. Attached a fix.

On 6. Jul 2026, at 8.39, Michael Goth via dovecot <dovecot@dovecot.org> wrote:
So I think updating the mailbox name to NFC should also update any
matching subscriptions of the user. Otherwise, the subscription gets
lost and we get constant errors in the logs.I thought this was already fixed, but looks like accidentally the test was using mailbox_list_utf8=yes. With the default =no it was broken. Attached a fix.
On 6. Jul 2026, at 21.53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
On 6. Jul 2026, at 8.39, Michael Goth via dovecot <dovecot@dovecot.org> wrote:
So I think updating the mailbox name to NFC should also update any matching subscriptions of the user. Otherwise, the subscription gets lost and we get constant errors in the logs.I thought this was already fixed, but looks like accidentally the test was using mailbox_list_utf8=yes. With the default =no it was broken. Attached a fix.
I guess nobody looked at the accidentally wrong diff :) But the fix is now committed: https://github.com/dovecot/core/commit/7b9cdf4848655d423bea78f5dbba7803350a2...
Hi,
I tested the patch. The NFC error is gone.
I copied one affected user to a test user. The problem was reproducible on two different servers. After running with the patched version, the NFC error disappeared. After migrating the mailbox back to an unpatched server, the NFC error was still gone. So the patch seems to change something persistent.
However, I still get more subscribed mailbox names than real mailboxes. Before the test on the unpatched server 'mailbox list -s‘ returned 50 mailbox names and 9 errors.
Without -s I get 50 mailboxes. With -s I get 68 names, but only 50 mailboxes really exist. The additional names have a GUID-like suffix. I don't know if they are related to this issue or if they are old subscription entries.
Would it make sense to remove the affected subscription entries automatically?
Regards, Jens
Von: Timo Sirainen <timo@sirainen.com> Datum: Freitag, 10. Juli 2026 um 16:28 An: Michael Goth <mg@webflow.de>; dovecot@dovecot.org <dovecot@dovecot.org>; Jens Urban <Jens.Urban@freenet.ag> Betreff: Re: NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox)
On 6. Jul 2026, at 21.53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
On 6. Jul 2026, at 8.39, Michael Goth via dovecot <dovecot@dovecot.org> wrote:
So I think updating the mailbox name to NFC should also update any matching subscriptions of the user. Otherwise, the subscription gets lost and we get constant errors in the logs.I thought this was already fixed, but looks like accidentally the test was using mailbox_list_utf8=yes. With the default =no it was broken. Attached a fix.
I guess nobody looked at the accidentally wrong diff :) But the fix is now committed:
Hi, I tested the patch. The NFC error is gone. I copied one affected user to a test user. The problem was reproducible on two different servers. After running with the patched version, the NFC error disappeared. After migrating the mailbox back to an unpatched server, the NFC error was still gone. So the patch seems to change something persistent. However, I still get more subscribed mailbox names than real mailboxes. Before the test on the unpatched server 'mailbox list -saEUR~ returned 50 mailbox names and 9 errors. Without -s I get 50 mailboxes. With -s I get 68 names, but only 50 mailboxes really exist. The additional names have a GUID-like suffix. I don't know if they are related to this issue or if they are old subscription entries. Would it make sense to remove the affected subscription entries automatically? Regards, Jens Von: Timo Sirainen <timo@sirainen.com> Datum: Freitag, 10. Juli 2026 um 16:28 An: Michael Goth <mg@webflow.de>; dovecot@dovecot.org <dovecot@dovecot.org>; Jens Urban <Jens.Urban@freenet.ag> Betreff: Re: NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox) On 6. Jul 2026, at 21.53, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
On 6. Jul 2026, at 8.39, Michael Goth via dovecot
<dovecot@dovecot.org>
wrote:
So I think updating the mailbox name to NFC should also update any matching subscriptions of the user. Otherwise, the subscription gets lost and we get constant errors in the logs.I thought this was already fixed, but looks like accidentally the test was using mailbox_list_utf8=yes. With the default =no it was broken. Attached a fix.
I guess nobody looked at the accidentally wrong diff :) But the fix is now committed:
participants (5)
-
Jan Münnich
-
Jens Urban
-
Michael Goth
-
Philip Iezzi
-
Timo Sirainen