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
      <[email protected]> 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
        <[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/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
          <[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:

          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
            <[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 '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 -- [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]


_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--
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:   [email protected]
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/

_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to