2.4.17 --> 2.5.3 Some mail folders no longer accessible

Patrick Goetz pgoetz at mail.utexas.edu
Sat Oct 3 06:51:42 EDT 2015


This is just a follow up to my previous email (see below). 
Reconstructing the mailboxes:

   # systemctl stop cyrus-master
   # su - cyrus
   # /usr/lib/cyrus/bin/reconstruct -r -f user/djones
   # <Ctrl>-d
   # systemctl start cyrus-master

resolved the problem.

I have a question about best practices.  I usually have the shell for 
user cyrus set to /bin/false.  So to run a reconstruct, I have to change 
this to /bin/bash (or something) first in order to be able to log in as 
cyrus and execute the reconstruct command.

On the other hand, this is only the second time I've had to run 
reconstruct in 12 years of using cyrus.  What do most people do about 
this?  Is cyrus an ordinary user who can log in by default, or is it 
best practice to have shell /bin/false, as I do with most other daemon 
users?

On 9/29/2015 6:35 AM, Sunny wrote:
>
>
> On 22/09/15 11:01, Patrick Goetz wrote:
>> Upgrading from 2.4.17 to 2.5.3 resulted in one very strange problem.
>> Some of the users have a large number of nested mail folders.  After the
>> upgrade, exactly one user found that some of his folders (say 3 out of
>> 30) are now inaccessible.  In Thunderbird they show up, but are greyed
>> out.  If you try to subscribe to the folder, the subscribe checkbox is
>> missing.  In roundcube they aren't visible at all.
>>
>> This is pretty clearly a permissions problem of some kind.  The question
>> is how could this happen and what's the least painless way of going
>> about resetting the permissions so that he has access to these folders
>> again?
>>
>> We're not doing anything fancy; for example, there are no shared
>> folders; independent email addresses are configured for shared mail
>> content and configured in the MUA.  The problem folders are in an
>> unshared account.
>>
>> Also, the manifestation of the permissions problem isn't consistent
>> across the affected folders.  As reported by the user:
>>
>> Archives Staff:  grayed out, cannot see email
>> Archives Staff Retreat:  not grayed out, cannot see email, when you
>> click on it, it says the action cannot be completed because the account
>> does not exist
>> General Convention Office:  not grayed out, can see email, when you
>> click on it, it says the action cannot be completed because the account
>> does not exist.
>>
>> Thanks.
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
> I see a similar issue with a shared mailbox in v2.3.7 some users and
> some of their subscriptions are greyed out. Rebuilding the index or
> re-adding the imap account works for a short while before it becomes
> corrupted again a week or two later. The mailbox has 1500 directories,
> 162054 files and around 40GB in size - but users don't tend to subscribe
> to all folders and only downloads the headers.
>
> Is there an optimum number of files/directories/size for a shared
> mailbox in cyrus?
>
> Regards
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>


More information about the Info-cyrus mailing list