To begin, i must apologise for the vague subject line. I struggled to come up with something both brief and descriptive. I might have used "failed to read index header" but i'm pretty sure that that is a secondary issue and does not adequately describe my problem.
My goal is to migrate mailboxes to a new server. Although I am not a professional, I've done this several times before using imapsync. However I ran into a problem with it this time that I could not resolve after a day of searching online. Being pressed for time, I chose to brute-force it using rsync. (Yeah, I was asking for it.)
Everything appeared to copy over fine, with permissions all correct, but cyrus now sees duplicate mailboxes, like so:
user.foo@xxxxxxxxxxx <- what I created
user^foo@example^com <- what's this?
The mailboxes on the OLD server have the form:
user.foo.Drafts@xxxxxxxxxxx (\HasNoChildren)
user.foo.Sent@xxxxxxxxxxx (\HasNoChildren)
user.foo.Trash@xxxxxxxxxxx (\HasNoChildren)
user.foo@xxxxxxxxxxx (\HasChildren
Before copying anything, I created the mailboxes on the NEW server, without the subfolders:
user.foo@xxxxxxxxxxx (\HasNoChildren)
Where I screwed up? in imapd.conf:
OLD server "unixhierarchysep: no"
NEW server "unixhierarchysep: yes"
After copying over with rsync, and checking that permissions looked ok, I ran reconstruct ...
bally@server:~$ su -c "/usr/lib/cyrus/bin/reconstruct -r -f user.*" cyrus -s /bin/bash
Password:
user^foo@example^com: failed to read index header
user.foo@xxxxxxxxxxx
...
Oh, dear. Let's list the mailboxes:
bally@server:~$ cyradm --user cyrus --server localhost
Password:
localhost> lm
user.foo@xxxxxxxxxxx (\HasNoChildren)
...
So, reconstruct sees both forms for some reason, and cyradm just what i'd created. And, the newly copied subfolders do not appear under the mailboxes with dots in the name. Presumably, they would appear under the ^ mailboxes, if only the index header could be read.
Note also that the form that these mystery mailbox names take is different from the example given in imapd.conf: "user.elmer^fud.rabbit^holes"
Realising the inconsistency between servers, I set unixhierarchysep: no, restarted cyrus, and then ran reconstruct again:
user.foo: failed to read index header
user.foo
...
Uh-oh. Now, the names are identical but it still sees twice the number of mailboxes. Stranger still, the domain has been dropped altogether.
Is there a safe way for me to massage this into working order? (Without having to transfer all the files again.) Should i delete, and recreate, the mailboxes? If so, what form of name should I use? I'm thoroughly confused now because reconstruct is still showing duplicates and not reading the headers.
The subfolders and cyrus.* permissions look like this, fwiw.
...
drwx------ 6 cyrus mail 4096 Feb 20 2021 Archives/
drwx------ 2 cyrus mail 4096 Aug 7 2021 Drafts/
drwx------ 2 cyrus mail 4096 Aug 20 2021 Junk/
drwx------ 2 cyrus mail 417792 Aug 19 2021 Sent/
drwx------ 2 cyrus mail 36864 Aug 19 2021 Spam/
drwx------ 2 cyrus mail 36864 Aug 14 2021 Trash/
-rw------- 1 cyrus mail 5736896 Aug 20 2021 cyrus.cache
-rw------- 1 cyrus mail 245 Apr 24 2017 cyrus.header
-rw------- 1 cyrus mail 419744 Aug 20 2021 cyrus.index
My goal is to migrate mailboxes to a new server. Although I am not a professional, I've done this several times before using imapsync. However I ran into a problem with it this time that I could not resolve after a day of searching online. Being pressed for time, I chose to brute-force it using rsync. (Yeah, I was asking for it.)
Everything appeared to copy over fine, with permissions all correct, but cyrus now sees duplicate mailboxes, like so:
user.foo@xxxxxxxxxxx <- what I created
user^foo@example^com <- what's this?
The mailboxes on the OLD server have the form:
user.foo.Drafts@xxxxxxxxxxx (\HasNoChildren)
user.foo.Sent@xxxxxxxxxxx (\HasNoChildren)
user.foo.Trash@xxxxxxxxxxx (\HasNoChildren)
user.foo@xxxxxxxxxxx (\HasChildren
Before copying anything, I created the mailboxes on the NEW server, without the subfolders:
user.foo@xxxxxxxxxxx (\HasNoChildren)
Where I screwed up? in imapd.conf:
OLD server "unixhierarchysep: no"
NEW server "unixhierarchysep: yes"
After copying over with rsync, and checking that permissions looked ok, I ran reconstruct ...
bally@server:~$ su -c "/usr/lib/cyrus/bin/reconstruct -r -f user.*" cyrus -s /bin/bash
Password:
user^foo@example^com: failed to read index header
user.foo@xxxxxxxxxxx
...
Oh, dear. Let's list the mailboxes:
bally@server:~$ cyradm --user cyrus --server localhost
Password:
localhost> lm
user.foo@xxxxxxxxxxx (\HasNoChildren)
...
So, reconstruct sees both forms for some reason, and cyradm just what i'd created. And, the newly copied subfolders do not appear under the mailboxes with dots in the name. Presumably, they would appear under the ^ mailboxes, if only the index header could be read.
Note also that the form that these mystery mailbox names take is different from the example given in imapd.conf: "user.elmer^fud.rabbit^holes"
Realising the inconsistency between servers, I set unixhierarchysep: no, restarted cyrus, and then ran reconstruct again:
user.foo: failed to read index header
user.foo
...
Uh-oh. Now, the names are identical but it still sees twice the number of mailboxes. Stranger still, the domain has been dropped altogether.
Is there a safe way for me to massage this into working order? (Without having to transfer all the files again.) Should i delete, and recreate, the mailboxes? If so, what form of name should I use? I'm thoroughly confused now because reconstruct is still showing duplicates and not reading the headers.
The subfolders and cyrus.* permissions look like this, fwiw.
...
drwx------ 6 cyrus mail 4096 Feb 20 2021 Archives/
drwx------ 2 cyrus mail 4096 Aug 7 2021 Drafts/
drwx------ 2 cyrus mail 4096 Aug 20 2021 Junk/
drwx------ 2 cyrus mail 417792 Aug 19 2021 Sent/
drwx------ 2 cyrus mail 36864 Aug 19 2021 Spam/
drwx------ 2 cyrus mail 36864 Aug 14 2021 Trash/
-rw------- 1 cyrus mail 5736896 Aug 20 2021 cyrus.cache
-rw------- 1 cyrus mail 245 Apr 24 2017 cyrus.header
-rw------- 1 cyrus mail 419744 Aug 20 2021 cyrus.index
