similar to: zlib + mdbox

It's apparent I have some level of corruption in my mailboxes - something to do with the combination of mdbox, sis, and zlib. I should note that I know I have a mix of compressed and raw messages - if that makes any difference in identifying the problems. I think I need to somehow regenerate the mailboxes with issues. Is there a suggestion for how to accomplish this? Should I perhaps use

Continuing to see errors on this with some new messages. Is it possible this has anything to do with zlib plugin, or possibly having a mix of zlib compressed & uncompressed messages with mdbox? I recently added zlib to deliver plugin list. -- Daniel L. Miller, VP - Engineering, SET AM Fire & Electronic Services, Inc. [AMFES] dmiller at amfes.com 702-312-5276

Trying to clean up the last of the corruption caused by my own stupidity. I now have two mailboxes for one user that give errors such as: doveadm(fax at amfes.com): Error: zlib.read(/var/mail/amfes.com/fax/mdbox/storage/m.9): gz trailer has wrong CRC value at 20065618 doveadm(fax at amfes.com): Error: read(/var/mail/amfes.com/fax/mdbox/storage/m.9) failed: Invalid argument (uid=238)

Getting some errors like: Feb 26 12:19:43 bubba dovecot: imap(dmiller at amfes.com): Error: read(attachments-connector(/var/mail/amfes.com/dmiller/mdbox/storage/m.7089)) failed: read(/var/mail/attachments/f6/f4/f6f4f3b882bf3488af632389d4aaba8adc332b12-60ab750a1aa4b554da1600009db5accb[base64:18 b/l]) failed:

With an error like this: doveadm(dmiller at amfes.com): Error: Corrupted dbox file /var/mail/amfes.com/dmiller/mdbox/storage/m.20 (around offset=74408): Unexpected EOF while reading metadata header What can be done? -- Daniel

So with "fts_autoindex=yes" enabled in plugins, is there anything I should be running regularly, other than the expunge/purge, to ensure Solr indexes are updated? I have a daily Solr optimize, and Solr autocommit enabled. I have an hourly "doveadm index -A *" command - is that unneeded? -- Daniel On 4/12/2015 6:53 AM, Timo Sirainen wrote: > On 10 Apr 2015, at 21:55,

Any thoughts on this? --- Daniel ------ Original Message ------ From: "Daniel Miller" <dmiller at amfes.com> To: "Dovecot Mailing List" <dovecot at dovecot.org> Sent: 2/12/2020 6:16:05 PM Subject: Shared Mailboxes with Multiple Domains >Trying to track down a problem I've been dealing with for a while. Everything else works fine - the problem is with

Why things happen is one of the great mysteries and joys of being a sysadmin... As for cleaning up SIS, I believe the "doveadm purge" command takes care of it. I have a daily cronjob which includes: #!/bin/sh # Permanently expunge old Trash doveadm expunge -A mailbox Trash savedbefore 2w # Optimize mdbox storage doveadm purge -A # Update fts indexes doveadm fts rescan -A -- Daniel

doveadm search -u dmiller at amfes.com text xyzxyz doveadm(dmiller at amfes.com): Panic: file istream-limit.c: line 79 (i_stream_limit_seek): assertion failed: (v_offset <= lstream->v_size) doveadm(dmiller at amfes.com): Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x3ca8a) [0x7fcf3daaca8a] -> /usr/local/lib/dovecot/libdovecot.so.0(default_fatal_handler+0x32)

Having a problem with a mailbox. I've been trying to rebuild - but doveadm force-resync crashes. This is mdbox with sis. doveadm purge -u dmiller at amfes.com doveadm(dmiller at amfes.com): Panic: file istream.c: line 466 (i_stream_grow_buffer): assertion failed: (stream->max_buffer_size > 0) doveadm(dmiller at amfes.com): Error: Raw backtrace:

Hello, Do you have recommendations on EXT4 and LVM options for a 3TB file-system for mdbox? We currently use the mbox format on a XFS with poor performances since the update in v2.1 (Debian). We will switch to EXT4 to have the possibility of shrinking the file-system if needed (which is not possible with XFS), we currently have LVM partitions but with mdbox we will use LVM snapshots to

For my primary namespace this is working fine - thanks to the developers! It also appears to work great for shared folders as well. But my virtual folders aren't returning results - at least not to the client. The logs show FTS Xapian opening several DB files and getting results - but nothing is being returned to client. Is this a config issue on my side or is this a current limitation of

Logs: Jun 5 06:02:25 bubba dovecot: imap(dmiller at amfes.com)<25877><IjkkJZOKPvKsOk9d>: Opening DB (RO) /var/mail/amfes.com/dmiller/sdbox/xapian-indexes/db_f2857830c70c844e2f1d00003bc41c5f Jun 5 06:02:25 bubba dovecot: imap(dmiller at amfes.com)<25877><IjkkJZOKPvKsOk9d>: FTS Xapian: FLAG=AND Jun 5 06:02:25 bubba dovecot: imap(dmiller at

Yesterday I had to recover an e-mail which a user had deleted. If I understand this correctly the message was expunged but not purged (doveadm purge had not been run). This e-mail was clearly still in the mdbox stored with zlib compression as I could tell using the doveadm dump command (doveadm dump -t dbox filename). I could however not reveal the e-mail with the normal doveadm fetch -u

Yes, latest git version. The logs show (as I read them) returned results - yet nothing shows in the client. The logs look the same (with different numbers) when querying "regular" folders - but results are shown in clients. -- Daniel On June 6, 2019 12:16:08 AM Joan Moreau <jom at grosjo.net> wrote: > Hi > Are you using the latest git version ? > WHich part exactly

> On 10/11/2020 20:07 Daniel Sch?tze <dms at cwa.uk.com> wrote: > > > Dear Aki > Thank you. Unfortunately I'm struggling to get the right syntax for this as it looks like someone else was here too > https://dovecot.org/pipermail/dovecot/2018-July/112441.html > The location in my dovecot.conf is > >

I have test environment to determine what would be best settings. I have been told that enabling zlib compression would be good to save iops on storage. But doing the test now, I get worse results. [@test2 ~]# pr -m -t mail04-mdbox-vdb-append-64kb-6.log mail04-mdbox-vdb-append-64kb-8.log |less Logi Sele Appe Logi Sele Appe 100% 100% 100% 100% 100%

Came across this in the logs... Nov 3 16:08:00 bubba dovecot: imap(dmiller at amfes.com): Error: Attachment file /var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c587400003bc41c5f size mismatch: 122626 != 165655 There's about a dozen different file entries listed in the error log. I'm using 2.0.6, mdbox, and the mails are stored on a local XFS

I've completed my mailbox rebuild - theoretically I should be free of corruption. I used dsync to export from mdbox to maildir (so should be clean) then used a virtual machine with Dovecot to import back to mdbox in another location. So...theoretically I should be free of all corruption now... Running an fts update - "doveadm search text -u user at domain.com xyzzyx" works on

That works for a one-time migration, or perhaps via a cron-job, but what I want is basically a constant one-way backup and it seems replication could do it more elegantly & efficiently. -- Daniel On 9/1/2018 11:14 PM, Aki Tuomi wrote: > You don't need to setup replication for that. See > https://wiki2.dovecot.org/Migration/MailFormat > > --- > Aki Tuomi > Dovecot oy