similar to: Uniqueness of dovecot mailbox-guids

Update: seems to me that the old cyrus mailserver already uses these non-unique mailbox guids. Is it necessary to have them unique over all private namespaces? Thanks Christian ----------------urspr?ngliche Nachricht----------------- Von:Christian Binder Stadt Freilassing [christian.binder at freilassing.de ] An:"dovecot dovecot.org" [dovecot at dovecot.org ] Datum:Thu, 29 Jan 2015

If mailbox guids should be unique systemwide, would it be safe to delete all 'dovecot-uidlist' files of the user's mailboxes and then do a doveadm force-resync after mailbox migration? Thanks! Christian ----------------urspr?ngliche Nachricht----------------- Von: Christian Binder Stadt Freilassing [christian.binder at freilassing.de ] An: "dovecot dovecot.org" [dovecot

Dovecot version: 2.2.9 I'm using doveadm backup to migrate about hundred user mailboxes from cyrus to dovecot. I defined a master user for the old cyrus mailserver in imapc backend to get access to all the mailboxes. Now I realized that after migration every user's "Inbox" or "Trash" on the new dovecot server has the same mailbox-guid, e.g: User a: inbox dd9456...

Ok, problem solved. Obviously the GUIDs only have to be unique for a specific user account in dovecot. Many thanks to Heinlein Support who helped me with this question!

Can no one give some adivse on this issue? Thanks Christian

Bump. Can no one give a hint? Thanks a lot! Christian

Greetings all, I can view a mailbox's GUID like so: doveadm mailbox status -u guid However, how may I *modify* a mailbox GUID? Can this be done using doveadm or some other tool? If not, how may I go about modifying the dovecot.mailbox.log (where I assume GUID data is stored)? My specific use case has to do with me wanting to modify an existing mailbox's GUID so that its messages

While migrating from mbox to maildir using dsync, I kept running into a brick wall. Some folders would not sync. The message in stderr was: Error message GUID: Mailbox GUIDs are not permanent without index files. This is what solved things for me. I hope this might help someone. Let me know if I'm completely off sides. When working with dsync to migrate from mbox to maildir format mailboxes,

Hello, Dovecot 2.0.9 on Red Hat Enterprise Linux Server release 6.4 (Santiago) location is set to : mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY Index is set to memory due to permissions problems when using disk index. Everything works, even rename folder, but when trying to delete folder, using any mail client, it fails with: "[CANNOT] Mailbox GUIDs are not permanent

I'm getting an error backing up mailboxes. I'm using the mirror command: dsync -fvo mail_home=/home/users/bob mirror ssh vmail at 10.1.4.1 dsync -o mail_home=/home/.incoming_mail_migrations/users/bob dsync-remote(vmail): Error: Mailboxes don't have unique GUIDs: 1ef6ee37c694894d783100000581a675 is shared by INBOX and INBOX dsync-remote(vmail): Error: command BOX-LIST failed

On Tue, 2012-07-17 at 09:04 -0700, Greg KH wrote: > On Sat, Jul 14, 2012 at 01:34:06PM -0700, K. Y. Srinivasan wrote: > > Format GUIDS as per MSFT standard. This makes interacting with MSFT > > tool stack easier. [] > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c [] > > @@ -147,7 +147,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev, >

On Tue, 2012-07-17 at 09:04 -0700, Greg KH wrote: > On Sat, Jul 14, 2012 at 01:34:06PM -0700, K. Y. Srinivasan wrote: > > Format GUIDS as per MSFT standard. This makes interacting with MSFT > > tool stack easier. [] > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c [] > > @@ -147,7 +147,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev, >

Hi all, I'm running two debian machines with dovecot 2.0.9 autobuilds and would like to keep mails synchronized on both via dsync. Mails are kept in maildir on both sides. While syncing, dsync gives the following error: dsync-local(jan.binder): Error: Can't rename mailbox INBOX to INBOX_a432bf2eca595a4dba47000043b078f4: Renaming INBOX isn't supported. dsync-local(jan.binder): Error:

I have recently updated with 2.2.29.1-avh1~xenial1 ubuntu package on 16.04. It appears that I have a couple of duplicate GUIDs which fsck can't clear so the machine is looping through doing continuous fsck runs. Any way to determine what the offending messages are and how to delete or otherwise stop this? Jul 1 17:09:24 post dovecot: doveadm(djk at tobit.co.uk): Warning: fscking index

Hello, got a Debian-Linux Server (Squeeze) which is running fine with samba version 3.5.6. > getent passwd |grep userx gives: userx:*:10182:10005:user, x:/home/DOMAIN/userx:/bin/false now there is another new installed debian server (Wheezy) which should replace the old one. Installed samba (3.6.6) and winbind, joined the domain and showing the users with wbinfo -u works well. But the

Hi, Have some old dboxes where doveadm sync fails with "Backend doesn't support GUIDs, sync with header hashes instead". The error is right after reading from the folder dovecot.index.log.2. The dovecot version is 2.3.10. Any fix/workaround for the error?

Recently I have in logs a LOT of messages like this: [....] Nov 06 19:39:36 IMAP(kjonca): Error: mdbox /home/kjonca/Mail/1/storage: Duplicate GUID 13511 in m.1530:845670 (size=2622) and m.1371:1831730 (size=916) Nov 06 19:39:36 IMAP(kjonca): Error: mdbox /home/kjonca/Mail/1/storage: Duplicate GUID 13512 in m.1530:847414 (size=2274) and m.1371:1832476 (size=1069) Nov 06 19:39:36 IMAP(kjonca):

New APIs: part_set_gpt_type part_get_gpt_type --- appliance/packagelist.in | 1 + daemon/parted.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++ generator/actions.ml | 30 +++++++++++ generator/tests_c_api.ml | 7 +++ generator/types.ml | 5 ++ src/MAX_PROC_NR | 2 +- 6 files changed, 173 insertions(+), 1 deletion(-) diff --git

Sounds a lot like my problem, which I described some days ago here on the list, but no luck. Please report to the list if you make any progress. Regards, Em 14/11/2019 10:41, Dav Rdrz via dovecot escreveu: > Hi, I hope you're all right. I describe below the scenario where the > problem occurs. > I'm trying to activate a master user [1] to be able to access all the > boxes of

>>>>> "Marcio" == Marcio Merlone via dovecot <dovecot at dovecot.org> writes: Marcio> Sounds a lot like my problem, which I described some days ago Marcio> here on the list, but no luck. Please report to the list if Marcio> you make any progress. Marcio, Looking at your passdb { } block, you don't have the "result_sucess = continue" option.