- dovecot - dovecot.org

public folders, ACLs
by Stefan G. Weichinger 06 Dec '21

06 Dec '21

greetings ... I got the following request from a customer where we run dovecot-2.3.15 on a debian server: They have a public folder with all their project-related subfolders inside: namespace { location = maildir:/home/vmail/oeffentlich prefix = Oeffentlich/ separator = / subscriptions = yes type = public } So far we don't have the mail_plugin ACL enabled. They want to be able to create projectfolders that aren't move/delete/rename-able by the users, only by some admins. But the users should be allowed to move mails between different projectfolders etc As far as I understand we can do that with Dovecot ACLs (although I am still figuring out how to properly design them ...). My questions: * if I enable the mail_plugin for ACLs, does that in any way change the behavior of existing mailboxes? afai understand: no. Only if ACL-lists exist in the various mailboxes, these get applied, right? I don't want to break things, and I want to avoid additional complexity for the non-public user mailboxes etc Maybe I can enable the plugin only for that public namespace? * maybe someone has a link to a similar setup? thanks in advance, Stefan

2 8

Errors after upgrade to v2.3.17
by Aurel Mihai 06 Dec '21

06 Dec '21

Hello, after upgrade to version 2.3.17, we enconter a lot of errors, such as: Dec 2 13:41:22 mail5 dovecot: lmtp(user@domain)<41944><EFw6IuKwqGHYowAAF7/xgA>: Error: lmtp-server: conn unix:pid=40487,uid=107 [22]: rcpt user@domain: stat(/home/virtual0/domain/user/.dovecot.lda-dupes/tmp) failed: Not a directory Here is my config: #dovecot -n # 2.3.17 (e2aa53df5b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.17 (054dddfa) # OS: Linux 4.19.0-18-amd64 x86_64 Debian 10.11 nfs # Hostname: auth_cache_verify_password_with_worker = yes auth_failure_delay = 5 secs auth_mechanisms = plain login auth_verbose = yes auth_worker_max_count = 256 default_client_limit = 10000 default_process_limit = 10000 default_vsz_limit = 1 G dict { lastlogin = mysql:/etc/dovecot/mysql/dovecot-dict-lastlogin.conf quotadict = mysql:/etc/dovecot/mysql/dovecot-dict-quota.conf } disable_plaintext_auth = no first_valid_uid = 100 imap_hibernate_timeout = 5 secs imap_idle_notify_interval = 3 mins log_timestamp = "%Y-%m-%d %H:%M:%S " login_log_format_elements = user=<%u> method=%m rip=%r lip=%l pid=%p %c login_trusted_networks = xxxx mail_fsync = always mail_location = maildir:/home/virtual0/%d/%u mail_nfs_index = yes mail_nfs_storage = yes mail_plugins = zlib quota mail_log notify mail_privileged_group = mail maildir_stat_dirs = yes managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave metric imap_command { filter = event=imap_command_finished AND tagged_reply_state=OK group_by = cmd_name } metric imap_select_no { filter = event=imap_command_finished AND cmd_name=SELECT AND tagged_reply_state=NO } metric imap_select_no_notfound { filter = event=imap_command_finished AND cmd_name=SELECT AND tagged_reply="NO*Mailbox doesn't exist:*" } metric storage_http_gets { filter = event=http_request_finished AND category=storage AND method=get } mmap_disable = yes namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { auto = subscribe special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Spam { auto = subscribe autoexpunge = 30 days special_use = \Junk } mailbox Trash { auto = subscribe autoexpunge = 60 days special_use = \Trash } mailbox virtual/All { special_use = \All } prefix = } passdb { args = /etc/dovecot/mysql/dovecot-sql.conf driver = sql } plugin { last_login_dict = proxy::lastlogin last_login_key = # hidden, use -P to show it mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size quota = dict:user::proxy::quotadict quota_rule2 = Trash:ignore quota_rule3 = Spam:ignore quota_status_nouser = DUNNO quota_status_overquota = 552 5.2.2 The email account that you tried to reach is over quota quota_status_success = DUNNO quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u sieve = ~/.dovecot.sieve sieve_before = /etc/dovecot/sieve/default.sieve sieve_dir = ~/sieve trash = /etc/dovecot/dovecot-trash.conf zlib_save = gz zlib_save_level = 6 } protocols = imap sieve pop3 lmtp service anvil { client_limit = 50000 unix_listener anvil-auth-penalty { mode = 00 } } service auth { client_limit = 50000 unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-master { group = mail mode = 0660 user = vmail } user = root vsz_limit = 1 G } service dict { unix_listener dict { mode = 0660 user = vmail } } service imap-hibernate { unix_listener imap-hibernate { group = $default_internal_group mode = 0660 } } service imap-login { inet_listener imap { address = * port = 143 } inet_listener imaps { address = * port = 993 } process_min_avail = 16 service_count = 1 } service imap { extra_groups = $default_internal_group process_min_avail = 16 unix_listener imap-master { user = $default_internal_user } vsz_limit = 2 G } service lmtp { process_min_avail = 16 unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } vsz_limit = 1 G } service managesieve-login { inet_listener sieve { port = 4190 } process_min_avail = 16 service_count = 1 } service managesieve { vsz_limit = 1 G } service pop3-login { inet_listener pop3 { address = * port = 110 } inet_listener pop3s { address = * port = 995 } process_min_avail = 16 service_count = 1 } service pop3 { process_min_avail = 16 vsz_limit = 1 G } service quota-status { executable = /usr/lib/dovecot/quota-status -p postfix process_min_avail = 16 unix_listener /var/spool/postfix/private/quota-status { group = postfix mode = 0666 user = postfix } } service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { mode = 0660 user = vmail } user = vmail } service stats { unix_listener stats-reader { mode = 0660 user = vmail } unix_listener stats-writer { mode = 0666 user = vmail } } ssl_cert = </etc/dovecot/ssl/domain.pem ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_min_protocol = TLSv1 userdb { args = /etc/dovecot/mysql/dovecot-sql.conf driver = sql } protocol imap { imap_max_line_length = 64 k mail_max_userip_connections = 16 mail_plugins = zlib quota mail_log notify trash imap_quota last_login } protocol pop3 { mail_max_userip_connections = 10 mail_plugins = zlib quota mail_log notify last_login pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_fast_size_lookups = yes pop3_no_flag_updates = yes pop3_uidl_format = %08Xu%08Xv } protocol sieve { mail_max_userip_connections = 10 managesieve_max_compile_errors = 5 } protocol lda { auth_socket_path = /var/run/dovecot/auth-master mail_plugins = zlib quota mail_log notify sieve sendmail_path = /usr/lib/sendmail syslog_facility = mail } protocol lmtp { mail_plugins = zlib quota mail_log notify sieve syslog_facility = mail } Any help please? Aurel

3 4

Re[5]: Replication weirdness
by Daniel Miller - CLOUD 04 Dec '21

04 Dec '21

Another update. I dug deeper into the mailboxes - and found the "subscriptions" and actual mailboxes weren't correct in all cases. I guess when I shifted to the explicit INBOX/ namespace not all the existing boxes migrated correctly. So...after manually correcting all the "subscription" files, and manually moving the duplicated "Archives" folders to the correct locations nearly all the errors have gone. I wish I'd gotten more inforrmative error messages, and processes certainly shouldn't have crashed, but since I obviously created the problem due to manually poking things and improper configuration I guess I can't complain too much. I still have problems using the "-N" flag for syncing - but things seem to be working with the multiple explicit "-n" namespaces. I do still have the locking error appearing during long-running syncs - I don't see why Dovecot doesn't know that it's already syncing a given user before trying to start a second process. Probably something else I setup wrong but I don't know what. -- Daniel

1 0

Re[4]: Replication weirdness
by Daniel Miller 03 Dec '21

03 Dec '21

And some more messages... Dec 3 15:10:58 bubba dovecot: doveadm(obfuscated)<1901><UGoeMgGkqmFtBwAAnbWsyw>: Error: Mailbox Sent sync: mailbox_rename failed: Can't rename mailbox while it has aliases Dec 3 15:10:58 bubba dovecot: doveadm(obfuscated)<1900><YVHxLACkqmFsBwAAnbWsyw>: Error: Duplicate mailbox GUID f4338038839caa613a1a0500b88bfabe for mailboxes INBOX/Sent Messages and INBOX/Sent - giving a new GUID bcf4f82702a4aa616c0700009db5accb to INBOX/Sent -- Daniel ------ Original Message ------ From: "Daniel Miller" <dmiller(a)amfes.com> To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org Sent: 12/3/2021 3:13:55 PM Subject: Re[3]: Replication weirdness >And... > >The user who has both a "Sent" and a "Sent Messages" now has: > >drwx------ 3 vmail mail 24 Dec 3 09:56 Sent >lrwxrwxrwx 1 vmail mail 4 Nov 30 17:51 'Sent Messages' -> Sent >drwx------ 3 vmail mail 24 Dec 3 15:10 'Sent Messages-temp-1' >drwx------ 3 vmail mail 24 Dec 3 15:10 'Sent >Messages-temp-fc30bd0a3a9aaa61c1180500b88bfabe' > >and I got the following errors: > >Dec 3 15:10:46 cloud1 dovecot: >doveadm(obfuscated)<336247><EMEQBvWjqmF3IQUAuIv6vg>: Error: Duplicate >mailbox GUID 6aae8c39f3a3aa615a0700009db5accb for mailboxes Sent and >Sent Messages-temp-1 - giving a new GUID >63481f29f6a3aa6177210500b88bfabe to Sent >Dec 3 15:10:50 cloud1 dovecot: >doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Panic: file >dsync-brain-mailbox.c: line 851 (dsync_brain_slave_recv_mailbox): >assertion failed: (memcmp(dsync_box->mailbox_guid, >local_dsync_box.mailbox_guid, sizeof(dsync_box->mailbox_guid)) == 0) >Dec 3 15:10:50 cloud1 dovecot: >doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Error: Raw >backtrace: #0 fatal_handler_real[0x7fde7fd20060] -> #1 >i_internal_fatal_handler[0x7fde7fd20190] -> #2 i_panic[0x7fde7fc731ff] >-> #3 dsync_brain_slave_recv_mailbox[0x55dde7b22900] -> #4 >dsync_brain_run[0x55dde7b20380] -> #5 >dsync_brain_run_io[0x55dde7b20b50] -> #6 >dsync_ibc_stream_input[0x55dde7b329c0] -> #7 >io_loop_call_io[0x7fde7fd36500] -> #8 >io_loop_handler_run_internal[0x7fde7fd37ac0] -> #9 >io_loop_handler_run[0x7fde7fd365c0] -> #10 io_loop_run[0x7fde7fd36740] >-> #11 cmd_dsync_server_run[0x55dde7b04f60] -> #12 >doveadm_mail_next_user[0x55dde7b06850] -> #13 >doveadm_cmd_ver2_to_mail_cmd_wrapper[0x55dde7b077e0] -> #14 >doveadm_cmd_run_ver2[0x55dde7b17f00] -> #15 >client_connection_tcp_input[0x55dde7b1c6b0] -> #16 >io_loop_call_io[0x7fde7fd36500] -> #17 >io_loop_handler_run_internal[0x7fde7fd37ac0] -> #18 >io_loop_handler_run[0x7fde7fd365c0] -> #19 io_loop_run[0x7fde7fd36740] >-> #20 master_service_run[0x7fde7fca87d0] -> #21 main[0x55dde7af7770] >-> #22 __libc_start_main[0x7fde7f8f9fc0] -> #23 _start[0x55dde7af78d0] >Dec 3 15:10:50 cloud1 dovecot: >doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Fatal: master: >service(doveadm): child 336245 killed with signal 6 (core dumped) >Dec 3 15:10:52 cloud1 dovecot: >doveadm(obfuscated)<336253><2VTpM/ujqmF9IQUAuIv6vg>: Error: Duplicate >mailbox GUID 63481f29f6a3aa6177210500b88bfabe for mailboxes INBOX/Sent >and INBOX/Sent Messages-temp-1 - giving a new GUID >cba35507fca3aa617d210500b88bfabe to INBOX/Sent >Dec 3 15:10:58 cloud1 dovecot: >doveadm(obfuscated)<336258><ykbQAAGkqmGCIQUAuIv6vg>: Error: Duplicate >mailbox GUID dc3b4434fba3aa61660700009db5accb for mailboxes Sent and >Sent Messages-temp-1 - giving a new GUID >60ad190102a4aa6182210500b88bfabe to Sent > >-- >Daniel > >------ Original Message ------ >From: "Daniel Miller" <dmiller(a)amfes.com> >To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org >Sent: 12/3/2021 2:42:12 PM >Subject: Re[2]: Replication weirdness > >>And...one more. >> >>I'm now seeing (again) messages like: >> >>Dec 3 14:29:14 cloud1 dovecot: >>doveadm(obfuscated)<334017><e3FHNjmaqmHBGAUAuIv6vg>: Error: Duplicate >>mailbox GUID bcb9ca36ae36aa617f0a00009db5accb for mailboxes INBOX/Sent >>Messages and INBOX/Sent - giving a new GUID >>fc30bd0a3a9aaa61c1180500b88bfabe to INBOX/Sent >>Dec 3 14:38:59 cloud1 dovecot: >>doveadm(obfuscated)<334394><an5KIoOcqmE6GgUAuIv6vg>: Error: Duplicate >>mailbox GUID fc30bd0a3a9aaa61c1180500b88bfabe for mailboxes INBOX/Sent >>Messages and INBOX/Sent - giving a new GUID >>f4338038839caa613a1a0500b88bfabe to INBOX/Sent >> >>Having one message for the initial sync I suppose is reasonable. A >>second...maybe? But I'm getting nervous I'm about to start seeing the >>endless temp folders again. >>-- >>Daniel >> >>------ Original Message ------ >>From: "Daniel Miller" <dmiller(a)amfes.com> >>To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org >>Sent: 12/3/2021 2:39:25 PM >>Subject: Re: Replication weirdness >> >>>Another item. >>> >>>Again, it may be a 2.3.13 issue and I'm now on 2.3.17. But...I had >>>problem when using the "-N" parameter for dsync. So - I just have >>>(had): >>> >>>replication_dsync_parameters = -d -l 30 -U -x INBOX/virtual -x >>>INBOX/shared >>> >>>Now that things are working - I wanted to have my other namespaces >>>sync as well. So I went to: >>> >>>replication_dsync_parameters = -d -l 30 -U -n INBOX -n INBOX/Archives >>>-n INBOX/Lists -x INBOX/virtual -x INBOX/shared >>> >>>This appears to be working (the sync is just starting)...but I'm >>>seeing lock errors in the logs such as: >>>Dec 3 14:34:24 bubba dovecot: >>>doveadm(dmiller(a)amfes.com)<31785><TV+0LlGbqmEpfAAAnbWsyw>: Error: >>>Couldn't lock /var/mail/amfes.com/dmiller/.dovecot-sync.lock: >>>fcntl(/var/mail/amfes.com/dmiller/.dovecot-sync.lock, write-lock, >>>F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held >>>by pid 31373) >>> >>>Checking the pid in question I see it's actively syncing a folder in >>>my mailbox. So I'm guessing, purely guessing, that by having multiple >>>namespaces explicitly directed to sync Dovecot is trying to start a >>>sync process for each of those namespaces - but all of them share a >>>common lock and therefore only one operation is allowed at a time. >>> >>>Am I correct, and whether or not I am - how can I correct these >>>errors? Do I dare try going back to just "-N"? >>> >>>-- >>>Daniel >>> >>>------ Original Message ------ >>>From: "Daniel Miller" <dmiller(a)amfes.com> >>>To: dovecot(a)dovecot.org >>>Sent: 12/3/2021 2:16:28 PM >>>Subject: Replication weirdness >>> >>>>First, I have to say this. After configuring everything correctly - >>>>and that means *everything* correctly - Dovecot replication Just >>>>Works. I'm not sure how (yes I do - Timo & Co. Magic) - but it does. >>>>Real-time new sync is near instantaneous. >>>> >>>>Now the problem. Or the background for the problem. My primary >>>>server uses sdbox for primary storage, mdbox for archival storage, >>>>and fts-solr. I spun up a second server, using sdbox, mdbox, and >>>>fts-flatcurve. My namespaces are as defined below. As best I can >>>>tell (based on diff comparing two 'doveconf -n' outputs) my >>>>namespaces are the same on both servers. >>>> >>>>namespace archives { >>>> list = children >>>> location = mdbox:/var/mail/%d/%n/Archives/mdbox >>>> mailbox Unsorted { >>>> auto = no >>>> special_use = \Archive >>>> } >>>> prefix = INBOX/Archives/ >>>> separator = / >>>> subscriptions = no >>>> type = private >>>>} >>>>namespace inbox { >>>> alias_for = >>>> hidden = no >>>> inbox = yes >>>> list = yes >>>> location = >>>> mailbox "Deleted Messages" { >>>> auto = no >>>> autoexpunge = 30 days >>>> special_use = \Trash >>>> } >>>> mailbox Drafts { >>>> auto = subscribe >>>> special_use = \Drafts >>>> } >>>> mailbox Sent { >>>> auto = subscribe >>>> special_use = \Sent >>>> } >>>> mailbox Trash { >>>> auto = subscribe >>>> autoexpunge = 30 days >>>> special_use = \Trash >>>> } >>>> prefix = INBOX/ >>>> separator = / >>>> subscriptions = no >>>> type = private >>>>} >>>>namespace lists { >>>> list = children >>>> location = mdbox:/var/mail/%d/%n/Lists/mdbox >>>> prefix = INBOX/Lists/ >>>> separator = / >>>> subscriptions = no >>>> type = private >>>>} >>>>namespace subscriptions { >>>> hidden = yes >>>> list = no >>>> location = >>>> prefix = >>>> separator = / >>>> subscriptions = yes >>>> type = private >>>>} >>>>namespace usershares { >>>> list = yes >>>> location = sdbox:/var/mail/%%d/%%n/sdbox:NO-NOSELECT >>>> prefix = INBOX/shared/%%d/%%n/ >>>> separator = / >>>> subscriptions = no >>>> type = shared >>>>} >>>>namespace virtual { >>>> list = children >>>> location = virtual:/var/mail/%d/%n/virtual >>>> mailbox Flagged { >>>> comment = All my flagged messages >>>> special_use = \Flagged >>>> } >>>> prefix = INBOX/virtual/ >>>> separator = / >>>> subscriptions = no >>>>} >>>> >>>>I also have: >>>>plugin { >>>> mailbox_alias_new = Sent Messages >>>> mailbox_alias_new2 = Sent Items >>>> mailbox_alias_new3 = Deleted Messages >>>> mailbox_alias_old = Sent >>>> mailbox_alias_old2 = Sent >>>> mailbox_alias_old3 = Trash >>>>} >>>> >>>>This setup worked fine with my single server. Then I enabled >>>>replication - just on the primary. Dsync went to work (it seemed to >>>>take forever for the initial sync but that's what happens with large >>>>mailboxes and slow internet connections). >>>> >>>>The problem came up with certain subfolders. And I believe it only >>>>happens with subfolders that have spaces in their names. I had two >>>>user's mailboxes (under Sent), one of which had a "Sent Messages" >>>>symlink alias for "Sent", that started generating tens or hundreds >>>>of duplicates during sync. Fortunately those subfolders only had a >>>>few mails in them. But I had trees looking like: >>>> >>>>[...] (below is under /var/mail/domain/user/sdbox/mailboxes/Sent/) >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-2 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-3 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ade0400b88bfabe >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ad-temp-1 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-1 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2-temp-1-temp-1 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-3 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-4 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-5 >>>>Proposal >>>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-e2aa0f35c99ba961356500009db5accb >>>>[...] >>>> >>>>I kept stopping, cleaning up the folders, and re-starting - and they >>>>kept regenerating. I tried renaming the folders to eliminate the >>>>spaces and I think that helped in one case - for the others I just >>>>moved the folders outside of the mail area completely to let the >>>>sync finish. >>>> >>>>Now that it's been stable for a day or two - I enabled sync in the >>>>other direction. And after setting *all* the required parameters >>>>instead of just most of them...it's working. But...I'm nervous about >>>>moving the problem folders back over. I will say, if it makes any >>>>difference, my primary server *was* running version 2.3.13 and I >>>>just updated it to 2.3.17. The remote is also 2.3.17. >>>> >>>>-- >>>>Daniel

1 0

Re[3]: Replication weirdness
by Daniel Miller 03 Dec '21

03 Dec '21

And... The user who has both a "Sent" and a "Sent Messages" now has: drwx------ 3 vmail mail 24 Dec 3 09:56 Sent lrwxrwxrwx 1 vmail mail 4 Nov 30 17:51 'Sent Messages' -> Sent drwx------ 3 vmail mail 24 Dec 3 15:10 'Sent Messages-temp-1' drwx------ 3 vmail mail 24 Dec 3 15:10 'Sent Messages-temp-fc30bd0a3a9aaa61c1180500b88bfabe' and I got the following errors: Dec 3 15:10:46 cloud1 dovecot: doveadm(obfuscated)<336247><EMEQBvWjqmF3IQUAuIv6vg>: Error: Duplicate mailbox GUID 6aae8c39f3a3aa615a0700009db5accb for mailboxes Sent and Sent Messages-temp-1 - giving a new GUID 63481f29f6a3aa6177210500b88bfabe to Sent Dec 3 15:10:50 cloud1 dovecot: doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Panic: file dsync-brain-mailbox.c: line 851 (dsync_brain_slave_recv_mailbox): assertion failed: (memcmp(dsync_box->mailbox_guid, local_dsync_box.mailbox_guid, sizeof(dsync_box->mailbox_guid)) == 0) Dec 3 15:10:50 cloud1 dovecot: doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Error: Raw backtrace: #0 fatal_handler_real[0x7fde7fd20060] -> #1 i_internal_fatal_handler[0x7fde7fd20190] -> #2 i_panic[0x7fde7fc731ff] -> #3 dsync_brain_slave_recv_mailbox[0x55dde7b22900] -> #4 dsync_brain_run[0x55dde7b20380] -> #5 dsync_brain_run_io[0x55dde7b20b50] -> #6 dsync_ibc_stream_input[0x55dde7b329c0] -> #7 io_loop_call_io[0x7fde7fd36500] -> #8 io_loop_handler_run_internal[0x7fde7fd37ac0] -> #9 io_loop_handler_run[0x7fde7fd365c0] -> #10 io_loop_run[0x7fde7fd36740] -> #11 cmd_dsync_server_run[0x55dde7b04f60] -> #12 doveadm_mail_next_user[0x55dde7b06850] -> #13 doveadm_cmd_ver2_to_mail_cmd_wrapper[0x55dde7b077e0] -> #14 doveadm_cmd_run_ver2[0x55dde7b17f00] -> #15 client_connection_tcp_input[0x55dde7b1c6b0] -> #16 io_loop_call_io[0x7fde7fd36500] -> #17 io_loop_handler_run_internal[0x7fde7fd37ac0] -> #18 io_loop_handler_run[0x7fde7fd365c0] -> #19 io_loop_run[0x7fde7fd36740] -> #20 master_service_run[0x7fde7fca87d0] -> #21 main[0x55dde7af7770] -> #22 __libc_start_main[0x7fde7f8f9fc0] -> #23 _start[0x55dde7af78d0] Dec 3 15:10:50 cloud1 dovecot: doveadm(obfuscated)<336245><HrHeOPOjqmF1IQUAuIv6vg>: Fatal: master: service(doveadm): child 336245 killed with signal 6 (core dumped) Dec 3 15:10:52 cloud1 dovecot: doveadm(obfuscated)<336253><2VTpM/ujqmF9IQUAuIv6vg>: Error: Duplicate mailbox GUID 63481f29f6a3aa6177210500b88bfabe for mailboxes INBOX/Sent and INBOX/Sent Messages-temp-1 - giving a new GUID cba35507fca3aa617d210500b88bfabe to INBOX/Sent Dec 3 15:10:58 cloud1 dovecot: doveadm(obfuscated)<336258><ykbQAAGkqmGCIQUAuIv6vg>: Error: Duplicate mailbox GUID dc3b4434fba3aa61660700009db5accb for mailboxes Sent and Sent Messages-temp-1 - giving a new GUID 60ad190102a4aa6182210500b88bfabe to Sent -- Daniel ------ Original Message ------ From: "Daniel Miller" <dmiller(a)amfes.com> To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org Sent: 12/3/2021 2:42:12 PM Subject: Re[2]: Replication weirdness >And...one more. > >I'm now seeing (again) messages like: > >Dec 3 14:29:14 cloud1 dovecot: >doveadm(obfuscated)<334017><e3FHNjmaqmHBGAUAuIv6vg>: Error: Duplicate >mailbox GUID bcb9ca36ae36aa617f0a00009db5accb for mailboxes INBOX/Sent >Messages and INBOX/Sent - giving a new GUID >fc30bd0a3a9aaa61c1180500b88bfabe to INBOX/Sent >Dec 3 14:38:59 cloud1 dovecot: >doveadm(obfuscated)<334394><an5KIoOcqmE6GgUAuIv6vg>: Error: Duplicate >mailbox GUID fc30bd0a3a9aaa61c1180500b88bfabe for mailboxes INBOX/Sent >Messages and INBOX/Sent - giving a new GUID >f4338038839caa613a1a0500b88bfabe to INBOX/Sent > >Having one message for the initial sync I suppose is reasonable. A >second...maybe? But I'm getting nervous I'm about to start seeing the >endless temp folders again. >-- >Daniel > >------ Original Message ------ >From: "Daniel Miller" <dmiller(a)amfes.com> >To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org >Sent: 12/3/2021 2:39:25 PM >Subject: Re: Replication weirdness > >>Another item. >> >>Again, it may be a 2.3.13 issue and I'm now on 2.3.17. But...I had >>problem when using the "-N" parameter for dsync. So - I just have >>(had): >> >>replication_dsync_parameters = -d -l 30 -U -x INBOX/virtual -x >>INBOX/shared >> >>Now that things are working - I wanted to have my other namespaces >>sync as well. So I went to: >> >>replication_dsync_parameters = -d -l 30 -U -n INBOX -n INBOX/Archives >>-n INBOX/Lists -x INBOX/virtual -x INBOX/shared >> >>This appears to be working (the sync is just starting)...but I'm >>seeing lock errors in the logs such as: >>Dec 3 14:34:24 bubba dovecot: >>doveadm(dmiller(a)amfes.com)<31785><TV+0LlGbqmEpfAAAnbWsyw>: Error: >>Couldn't lock /var/mail/amfes.com/dmiller/.dovecot-sync.lock: >>fcntl(/var/mail/amfes.com/dmiller/.dovecot-sync.lock, write-lock, >>F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held >>by pid 31373) >> >>Checking the pid in question I see it's actively syncing a folder in >>my mailbox. So I'm guessing, purely guessing, that by having multiple >>namespaces explicitly directed to sync Dovecot is trying to start a >>sync process for each of those namespaces - but all of them share a >>common lock and therefore only one operation is allowed at a time. >> >>Am I correct, and whether or not I am - how can I correct these >>errors? Do I dare try going back to just "-N"? >> >>-- >>Daniel >> >>------ Original Message ------ >>From: "Daniel Miller" <dmiller(a)amfes.com> >>To: dovecot(a)dovecot.org >>Sent: 12/3/2021 2:16:28 PM >>Subject: Replication weirdness >> >>>First, I have to say this. After configuring everything correctly - >>>and that means *everything* correctly - Dovecot replication Just >>>Works. I'm not sure how (yes I do - Timo & Co. Magic) - but it does. >>>Real-time new sync is near instantaneous. >>> >>>Now the problem. Or the background for the problem. My primary server >>>uses sdbox for primary storage, mdbox for archival storage, and >>>fts-solr. I spun up a second server, using sdbox, mdbox, and >>>fts-flatcurve. My namespaces are as defined below. As best I can tell >>>(based on diff comparing two 'doveconf -n' outputs) my namespaces are >>>the same on both servers. >>> >>>namespace archives { >>> list = children >>> location = mdbox:/var/mail/%d/%n/Archives/mdbox >>> mailbox Unsorted { >>> auto = no >>> special_use = \Archive >>> } >>> prefix = INBOX/Archives/ >>> separator = / >>> subscriptions = no >>> type = private >>>} >>>namespace inbox { >>> alias_for = >>> hidden = no >>> inbox = yes >>> list = yes >>> location = >>> mailbox "Deleted Messages" { >>> auto = no >>> autoexpunge = 30 days >>> special_use = \Trash >>> } >>> mailbox Drafts { >>> auto = subscribe >>> special_use = \Drafts >>> } >>> mailbox Sent { >>> auto = subscribe >>> special_use = \Sent >>> } >>> mailbox Trash { >>> auto = subscribe >>> autoexpunge = 30 days >>> special_use = \Trash >>> } >>> prefix = INBOX/ >>> separator = / >>> subscriptions = no >>> type = private >>>} >>>namespace lists { >>> list = children >>> location = mdbox:/var/mail/%d/%n/Lists/mdbox >>> prefix = INBOX/Lists/ >>> separator = / >>> subscriptions = no >>> type = private >>>} >>>namespace subscriptions { >>> hidden = yes >>> list = no >>> location = >>> prefix = >>> separator = / >>> subscriptions = yes >>> type = private >>>} >>>namespace usershares { >>> list = yes >>> location = sdbox:/var/mail/%%d/%%n/sdbox:NO-NOSELECT >>> prefix = INBOX/shared/%%d/%%n/ >>> separator = / >>> subscriptions = no >>> type = shared >>>} >>>namespace virtual { >>> list = children >>> location = virtual:/var/mail/%d/%n/virtual >>> mailbox Flagged { >>> comment = All my flagged messages >>> special_use = \Flagged >>> } >>> prefix = INBOX/virtual/ >>> separator = / >>> subscriptions = no >>>} >>> >>>I also have: >>>plugin { >>> mailbox_alias_new = Sent Messages >>> mailbox_alias_new2 = Sent Items >>> mailbox_alias_new3 = Deleted Messages >>> mailbox_alias_old = Sent >>> mailbox_alias_old2 = Sent >>> mailbox_alias_old3 = Trash >>>} >>> >>>This setup worked fine with my single server. Then I enabled >>>replication - just on the primary. Dsync went to work (it seemed to >>>take forever for the initial sync but that's what happens with large >>>mailboxes and slow internet connections). >>> >>>The problem came up with certain subfolders. And I believe it only >>>happens with subfolders that have spaces in their names. I had two >>>user's mailboxes (under Sent), one of which had a "Sent Messages" >>>symlink alias for "Sent", that started generating tens or hundreds of >>>duplicates during sync. Fortunately those subfolders only had a few >>>mails in them. But I had trees looking like: >>> >>>[...] (below is under /var/mail/domain/user/sdbox/mailboxes/Sent/) >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-2 >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-3 >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ade0400b88bfabe >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ad-temp-1 >>>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-1 >>>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2 >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2-temp-1-temp-1 >>>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-3 >>>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-4 >>>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-5 >>>Proposal >>>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-e2aa0f35c99ba961356500009db5accb >>>[...] >>> >>>I kept stopping, cleaning up the folders, and re-starting - and they >>>kept regenerating. I tried renaming the folders to eliminate the >>>spaces and I think that helped in one case - for the others I just >>>moved the folders outside of the mail area completely to let the sync >>>finish. >>> >>>Now that it's been stable for a day or two - I enabled sync in the >>>other direction. And after setting *all* the required parameters >>>instead of just most of them...it's working. But...I'm nervous about >>>moving the problem folders back over. I will say, if it makes any >>>difference, my primary server *was* running version 2.3.13 and I just >>>updated it to 2.3.17. The remote is also 2.3.17. >>> >>>-- >>>Daniel

1 0

Re[2]: Replication weirdness
by Daniel Miller 03 Dec '21

03 Dec '21

And...one more. I'm now seeing (again) messages like: Dec 3 14:29:14 cloud1 dovecot: doveadm(obfuscated)<334017><e3FHNjmaqmHBGAUAuIv6vg>: Error: Duplicate mailbox GUID bcb9ca36ae36aa617f0a00009db5accb for mailboxes INBOX/Sent Messages and INBOX/Sent - giving a new GUID fc30bd0a3a9aaa61c1180500b88bfabe to INBOX/Sent Dec 3 14:38:59 cloud1 dovecot: doveadm(obfuscated)<334394><an5KIoOcqmE6GgUAuIv6vg>: Error: Duplicate mailbox GUID fc30bd0a3a9aaa61c1180500b88bfabe for mailboxes INBOX/Sent Messages and INBOX/Sent - giving a new GUID f4338038839caa613a1a0500b88bfabe to INBOX/Sent Having one message for the initial sync I suppose is reasonable. A second...maybe? But I'm getting nervous I'm about to start seeing the endless temp folders again. -- Daniel ------ Original Message ------ From: "Daniel Miller" <dmiller(a)amfes.com> To: "Daniel Miller" <dmiller(a)amfes.com>; dovecot(a)dovecot.org Sent: 12/3/2021 2:39:25 PM Subject: Re: Replication weirdness >Another item. > >Again, it may be a 2.3.13 issue and I'm now on 2.3.17. But...I had >problem when using the "-N" parameter for dsync. So - I just have >(had): > >replication_dsync_parameters = -d -l 30 -U -x INBOX/virtual -x >INBOX/shared > >Now that things are working - I wanted to have my other namespaces sync >as well. So I went to: > >replication_dsync_parameters = -d -l 30 -U -n INBOX -n INBOX/Archives >-n INBOX/Lists -x INBOX/virtual -x INBOX/shared > >This appears to be working (the sync is just starting)...but I'm seeing >lock errors in the logs such as: >Dec 3 14:34:24 bubba dovecot: >doveadm(dmiller(a)amfes.com)<31785><TV+0LlGbqmEpfAAAnbWsyw>: Error: >Couldn't lock /var/mail/amfes.com/dmiller/.dovecot-sync.lock: >fcntl(/var/mail/amfes.com/dmiller/.dovecot-sync.lock, write-lock, >F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held >by pid 31373) > >Checking the pid in question I see it's actively syncing a folder in my >mailbox. So I'm guessing, purely guessing, that by having multiple >namespaces explicitly directed to sync Dovecot is trying to start a >sync process for each of those namespaces - but all of them share a >common lock and therefore only one operation is allowed at a time. > >Am I correct, and whether or not I am - how can I correct these errors? >Do I dare try going back to just "-N"? > >-- >Daniel > >------ Original Message ------ >From: "Daniel Miller" <dmiller(a)amfes.com> >To: dovecot(a)dovecot.org >Sent: 12/3/2021 2:16:28 PM >Subject: Replication weirdness > >>First, I have to say this. After configuring everything correctly - >>and that means *everything* correctly - Dovecot replication Just >>Works. I'm not sure how (yes I do - Timo & Co. Magic) - but it does. >>Real-time new sync is near instantaneous. >> >>Now the problem. Or the background for the problem. My primary server >>uses sdbox for primary storage, mdbox for archival storage, and >>fts-solr. I spun up a second server, using sdbox, mdbox, and >>fts-flatcurve. My namespaces are as defined below. As best I can tell >>(based on diff comparing two 'doveconf -n' outputs) my namespaces are >>the same on both servers. >> >>namespace archives { >> list = children >> location = mdbox:/var/mail/%d/%n/Archives/mdbox >> mailbox Unsorted { >> auto = no >> special_use = \Archive >> } >> prefix = INBOX/Archives/ >> separator = / >> subscriptions = no >> type = private >>} >>namespace inbox { >> alias_for = >> hidden = no >> inbox = yes >> list = yes >> location = >> mailbox "Deleted Messages" { >> auto = no >> autoexpunge = 30 days >> special_use = \Trash >> } >> mailbox Drafts { >> auto = subscribe >> special_use = \Drafts >> } >> mailbox Sent { >> auto = subscribe >> special_use = \Sent >> } >> mailbox Trash { >> auto = subscribe >> autoexpunge = 30 days >> special_use = \Trash >> } >> prefix = INBOX/ >> separator = / >> subscriptions = no >> type = private >>} >>namespace lists { >> list = children >> location = mdbox:/var/mail/%d/%n/Lists/mdbox >> prefix = INBOX/Lists/ >> separator = / >> subscriptions = no >> type = private >>} >>namespace subscriptions { >> hidden = yes >> list = no >> location = >> prefix = >> separator = / >> subscriptions = yes >> type = private >>} >>namespace usershares { >> list = yes >> location = sdbox:/var/mail/%%d/%%n/sdbox:NO-NOSELECT >> prefix = INBOX/shared/%%d/%%n/ >> separator = / >> subscriptions = no >> type = shared >>} >>namespace virtual { >> list = children >> location = virtual:/var/mail/%d/%n/virtual >> mailbox Flagged { >> comment = All my flagged messages >> special_use = \Flagged >> } >> prefix = INBOX/virtual/ >> separator = / >> subscriptions = no >>} >> >>I also have: >>plugin { >> mailbox_alias_new = Sent Messages >> mailbox_alias_new2 = Sent Items >> mailbox_alias_new3 = Deleted Messages >> mailbox_alias_old = Sent >> mailbox_alias_old2 = Sent >> mailbox_alias_old3 = Trash >>} >> >>This setup worked fine with my single server. Then I enabled >>replication - just on the primary. Dsync went to work (it seemed to >>take forever for the initial sync but that's what happens with large >>mailboxes and slow internet connections). >> >>The problem came up with certain subfolders. And I believe it only >>happens with subfolders that have spaces in their names. I had two >>user's mailboxes (under Sent), one of which had a "Sent Messages" >>symlink alias for "Sent", that started generating tens or hundreds of >>duplicates during sync. Fortunately those subfolders only had a few >>mails in them. But I had trees looking like: >> >>[...] (below is under /var/mail/domain/user/sdbox/mailboxes/Sent/) >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-2 >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-3 >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ade0400b88bfabe >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ad-temp-1 >>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-1 >>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2 >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2-temp-1-temp-1 >>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-3 >>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-4 >>Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-5 >>Proposal >>Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-e2aa0f35c99ba961356500009db5accb >>[...] >> >>I kept stopping, cleaning up the folders, and re-starting - and they >>kept regenerating. I tried renaming the folders to eliminate the >>spaces and I think that helped in one case - for the others I just >>moved the folders outside of the mail area completely to let the sync >>finish. >> >>Now that it's been stable for a day or two - I enabled sync in the >>other direction. And after setting *all* the required parameters >>instead of just most of them...it's working. But...I'm nervous about >>moving the problem folders back over. I will say, if it makes any >>difference, my primary server *was* running version 2.3.13 and I just >>updated it to 2.3.17. The remote is also 2.3.17. >> >>-- >>Daniel

1 0

Re: Replication weirdness
by Daniel Miller 03 Dec '21

03 Dec '21

Another item. Again, it may be a 2.3.13 issue and I'm now on 2.3.17. But...I had problem when using the "-N" parameter for dsync. So - I just have (had): replication_dsync_parameters = -d -l 30 -U -x INBOX/virtual -x INBOX/shared Now that things are working - I wanted to have my other namespaces sync as well. So I went to: replication_dsync_parameters = -d -l 30 -U -n INBOX -n INBOX/Archives -n INBOX/Lists -x INBOX/virtual -x INBOX/shared This appears to be working (the sync is just starting)...but I'm seeing lock errors in the logs such as: Dec 3 14:34:24 bubba dovecot: doveadm(dmiller(a)amfes.com)<31785><TV+0LlGbqmEpfAAAnbWsyw>: Error: Couldn't lock /var/mail/amfes.com/dmiller/.dovecot-sync.lock: fcntl(/var/mail/amfes.com/dmiller/.dovecot-sync.lock, write-lock, F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held by pid 31373) Checking the pid in question I see it's actively syncing a folder in my mailbox. So I'm guessing, purely guessing, that by having multiple namespaces explicitly directed to sync Dovecot is trying to start a sync process for each of those namespaces - but all of them share a common lock and therefore only one operation is allowed at a time. Am I correct, and whether or not I am - how can I correct these errors? Do I dare try going back to just "-N"? -- Daniel ------ Original Message ------ From: "Daniel Miller" <dmiller(a)amfes.com> To: dovecot(a)dovecot.org Sent: 12/3/2021 2:16:28 PM Subject: Replication weirdness >First, I have to say this. After configuring everything correctly - and >that means *everything* correctly - Dovecot replication Just Works. I'm >not sure how (yes I do - Timo & Co. Magic) - but it does. Real-time new >sync is near instantaneous. > >Now the problem. Or the background for the problem. My primary server >uses sdbox for primary storage, mdbox for archival storage, and >fts-solr. I spun up a second server, using sdbox, mdbox, and >fts-flatcurve. My namespaces are as defined below. As best I can tell >(based on diff comparing two 'doveconf -n' outputs) my namespaces are >the same on both servers. > >namespace archives { > list = children > location = mdbox:/var/mail/%d/%n/Archives/mdbox > mailbox Unsorted { > auto = no > special_use = \Archive > } > prefix = INBOX/Archives/ > separator = / > subscriptions = no > type = private >} >namespace inbox { > alias_for = > hidden = no > inbox = yes > list = yes > location = > mailbox "Deleted Messages" { > auto = no > autoexpunge = 30 days > special_use = \Trash > } > mailbox Drafts { > auto = subscribe > special_use = \Drafts > } > mailbox Sent { > auto = subscribe > special_use = \Sent > } > mailbox Trash { > auto = subscribe > autoexpunge = 30 days > special_use = \Trash > } > prefix = INBOX/ > separator = / > subscriptions = no > type = private >} >namespace lists { > list = children > location = mdbox:/var/mail/%d/%n/Lists/mdbox > prefix = INBOX/Lists/ > separator = / > subscriptions = no > type = private >} >namespace subscriptions { > hidden = yes > list = no > location = > prefix = > separator = / > subscriptions = yes > type = private >} >namespace usershares { > list = yes > location = sdbox:/var/mail/%%d/%%n/sdbox:NO-NOSELECT > prefix = INBOX/shared/%%d/%%n/ > separator = / > subscriptions = no > type = shared >} >namespace virtual { > list = children > location = virtual:/var/mail/%d/%n/virtual > mailbox Flagged { > comment = All my flagged messages > special_use = \Flagged > } > prefix = INBOX/virtual/ > separator = / > subscriptions = no >} > >I also have: >plugin { > mailbox_alias_new = Sent Messages > mailbox_alias_new2 = Sent Items > mailbox_alias_new3 = Deleted Messages > mailbox_alias_old = Sent > mailbox_alias_old2 = Sent > mailbox_alias_old3 = Trash >} > >This setup worked fine with my single server. Then I enabled >replication - just on the primary. Dsync went to work (it seemed to >take forever for the initial sync but that's what happens with large >mailboxes and slow internet connections). > >The problem came up with certain subfolders. And I believe it only >happens with subfolders that have spaces in their names. I had two >user's mailboxes (under Sent), one of which had a "Sent Messages" >symlink alias for "Sent", that started generating tens or hundreds of >duplicates during sync. Fortunately those subfolders only had a few >mails in them. But I had trees looking like: > >[...] (below is under /var/mail/domain/user/sdbox/mailboxes/Sent/) >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-2 >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-3 >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ade0400b88bfabe >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ad-temp-1 >Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-1 >Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2 >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2-temp-1-temp-1 >Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-3 >Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-4 >Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-5 >Proposal >Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-e2aa0f35c99ba961356500009db5accb >[...] > >I kept stopping, cleaning up the folders, and re-starting - and they >kept regenerating. I tried renaming the folders to eliminate the spaces >and I think that helped in one case - for the others I just moved the >folders outside of the mail area completely to let the sync finish. > >Now that it's been stable for a day or two - I enabled sync in the >other direction. And after setting *all* the required parameters >instead of just most of them...it's working. But...I'm nervous about >moving the problem folders back over. I will say, if it makes any >difference, my primary server *was* running version 2.3.13 and I just >updated it to 2.3.17. The remote is also 2.3.17. > >-- >Daniel

1 0

Replication weirdness
by Daniel Miller 03 Dec '21

03 Dec '21

First, I have to say this. After configuring everything correctly - and that means *everything* correctly - Dovecot replication Just Works. I'm not sure how (yes I do - Timo & Co. Magic) - but it does. Real-time new sync is near instantaneous. Now the problem. Or the background for the problem. My primary server uses sdbox for primary storage, mdbox for archival storage, and fts-solr. I spun up a second server, using sdbox, mdbox, and fts-flatcurve. My namespaces are as defined below. As best I can tell (based on diff comparing two 'doveconf -n' outputs) my namespaces are the same on both servers. namespace archives { list = children location = mdbox:/var/mail/%d/%n/Archives/mdbox mailbox Unsorted { auto = no special_use = \Archive } prefix = INBOX/Archives/ separator = / subscriptions = no type = private } namespace inbox { alias_for = hidden = no inbox = yes list = yes location = mailbox "Deleted Messages" { auto = no autoexpunge = 30 days special_use = \Trash } mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Sent { auto = subscribe special_use = \Sent } mailbox Trash { auto = subscribe autoexpunge = 30 days special_use = \Trash } prefix = INBOX/ separator = / subscriptions = no type = private } namespace lists { list = children location = mdbox:/var/mail/%d/%n/Lists/mdbox prefix = INBOX/Lists/ separator = / subscriptions = no type = private } namespace subscriptions { hidden = yes list = no location = prefix = separator = / subscriptions = yes type = private } namespace usershares { list = yes location = sdbox:/var/mail/%%d/%%n/sdbox:NO-NOSELECT prefix = INBOX/shared/%%d/%%n/ separator = / subscriptions = no type = shared } namespace virtual { list = children location = virtual:/var/mail/%d/%n/virtual mailbox Flagged { comment = All my flagged messages special_use = \Flagged } prefix = INBOX/virtual/ separator = / subscriptions = no } I also have: plugin { mailbox_alias_new = Sent Messages mailbox_alias_new2 = Sent Items mailbox_alias_new3 = Deleted Messages mailbox_alias_old = Sent mailbox_alias_old2 = Sent mailbox_alias_old3 = Trash } This setup worked fine with my single server. Then I enabled replication - just on the primary. Dsync went to work (it seemed to take forever for the initial sync but that's what happens with large mailboxes and slow internet connections). The problem came up with certain subfolders. And I believe it only happens with subfolders that have spaces in their names. I had two user's mailboxes (under Sent), one of which had a "Sent Messages" symlink alias for "Sent", that started generating tens or hundreds of duplicates during sync. Fortunately those subfolders only had a few mails in them. But I had trees looking like: [...] (below is under /var/mail/domain/user/sdbox/mailboxes/Sent/) Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-2 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-1-temp-f80b1a00ce9aa961a86-temp-3 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ade0400b88bfabe Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-023fa4271c9ca9611ad-temp-1 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-1 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-2-temp-1-temp-1 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-3 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-4 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-5 Proposal Requests-temp-c6e003375e64a961c93d00009db5accb-temp-2-temp-e2aa0f35c99ba961356500009db5accb [...] I kept stopping, cleaning up the folders, and re-starting - and they kept regenerating. I tried renaming the folders to eliminate the spaces and I think that helped in one case - for the others I just moved the folders outside of the mail area completely to let the sync finish. Now that it's been stable for a day or two - I enabled sync in the other direction. And after setting *all* the required parameters instead of just most of them...it's working. But...I'm nervous about moving the problem folders back over. I will say, if it makes any difference, my primary server *was* running version 2.3.13 and I just updated it to 2.3.17. The remote is also 2.3.17. -- Daniel

1 0

Searching 30 GB mailbox
by Einar Bjarni Halldórsson 03 Dec '21

03 Dec '21

Hi, We're migrating our mailboxes from Zimbra to dovecot, running on FreeBSD 12.2. We're using mdbox and solr for fts. dovecot version 2.3.17. One of our mailboxes gets a bcc of every outgoing mail from our system and it currently holds ~4.5 million messages taking 30 GB. One of the ways we use the mailbox is that when outgoing mail is sent, we store the Message-ID in our database, and in our admin interface we can open the mail and it's fetched from IMAP by doing a 'SEARCH HEADER Message-ID <MSG_ID>'. In Zimbra this was reasonably fast, but after migrating the mailbox to dovecot it's 30 seconds which I think we can reduce. After turning on mail_debug I see this in our log https://pastebin.com/kP9H7gSB Looks like solr finishes searching instantly, then there's ~30 seconds of silence in the logs, and then more log lines about fetching data from mail cache. The same thing happens if I use telnet and just issue a 'SEARCH HEADER...' command. How can I find out what dovecot is doing in those 30 seconds? .einar

5 14

Expunged message reappeared
by Claudio Corvino 03 Dec '21

03 Dec '21

Hi, I have two IMAP/LMTP Dovecot server in replica (version 2.3.4.1), I use LDAP/AD for /userdb, /replica is working, but sometimes I get these errors into log: Dec 3 15:47:15 xxx dovecot: imap(xxx)<28251><TOSxmj7SPRYloY5/>: Warning: Maildir /mnt/mail-storage-lv0007/xxx/Maildir: Expunged message reappeared, giving a new UID (old uid=233140, file=1638540323.M588041P27708.xxx,S=84376,W=85507:2,) The user delete the message and then the message reappears into mail client after one second. Does anybody knows how can I fix it? Thanks in advance Regards

1 1