[Dovecot] problems with shared mailboxes and other general issues

[Tom Lieuallen]

>> acl_shared_dict = file:/private/dovecot/var/etc/shared-mailboxes
>>
>> The '../var/etc' directory is something like 755.  I have to create
>> the file first and make it 666.
>
> That should work.
>
>> When it is updated, ownership&  permissions are changed such that
>> the user giving acl permissions then owns the file and it's 600.
>
> That shouldn't happen. It should preserve the original file
> permissions. If the file doesn't exist, it should get parent
> directory's permissions and use them. Wonder if the problem is the
> parent dir's permissions?
>
> It's of course also possible that there is a bug. It would speed
> things up a bit if you could try this with latest v2.0 nightly
> snapshot if it's still broken:
> http://dovecot.org/nightly/dovecot-latest.tar.gz
>
>> I tried setting it back to 644 afterward, so other users could read
>> it, but they tried setting a lock in that dir as well.
>
> Yes, lock files are created every time the file is updated (it's
> recreated every time).

If users need to set locks, then the directory will need to be writable 
by everyone.

>> I tried this:
>>
>> acl_shared_dict =
>> file:/private/dovecot/var/etc/shared-list/shared-mailboxes-%u
>
> That just won't work (or at least do anything useful). Each user
> would have his own file, and no one else would see it.
>
>> My second choice was to use sqlite for this acl_shared_dict, but,
>> even though I compiled dovecot with sqlite support and 'ldd' shows
>> that '../libexec/dict' is linked against sqlite libraries, when I
>> tried this config:
>>
>> acl_shared_dict = sqlite:/private/dovecot/etc/acl-shared-dict.conf
>>
>> I get this, and dovecot fails to start up.
>>
>> EUnknown dict module: sqlite
>
> Right. This is because typically all except file backend goes through
> dict process, and you need to use proxy backend to do that. See for
> example quota dict configuration.

I'll see if that helps.

>> On a related note, I thought I'd increase debugging to see if that
>> helped out any.  When I change 'mail_debug' to 'yes', as soon as I
>> issue the imap login command, it logs some stuff, then kicks me
>> out.
>>
>> Jun 09 15:57:53 IMAP(tom2): Info: acl: initializing backend with
>> data: vfile Jun 09 15:57:53 IMAP(tom2): Info: acl: acl username =
>> tom2 Jun 09 15:57:53 IMAP(tom2): Info: acl: owner = 1 Jun 09
>> 15:57:53 dovecot: Error: child 6000 (imap) killed with signal 11
>> (core dumps disabled)
>
> Signal 11 means a crash. It's always a bug. A gdb backtrace would be
> helpful in fixing it. See http://dovecot.org/bugreport.html

I'll see if I can generate a gdb backtrace.  I did figure out that this 
only happens when I have the 'mail_plugins = acl imap_acl' in the 
'protocol imap' section and only with mail_debug.  When that combination 
is not in play, I don't get the crash.

>> I have been frustrated by the shared namespace documentation.  I've
>> been through it again and again, but haven't found the answers I've
>> been looking for.
>
> I guess it's not ideal yet, but I don't yet have any ideas how to
> improve it. Maybe once you get it working, you could suggest
> something?

I'll try.  I think the documentation makes perfect sense for those who 
have it working, but not for those fumbling in the dark.... :-)  I'll 
have to find my way out of this dark room before I can help illuminate 
it for anyone else. ;-)

>> namespace shared { location =
>> mbox:%%h/mail/shared:INDEX=%%h/mail/shared/.imap
>
> Don't set the :INDEX directory that way. It probably won't break
> anything, but it's confusing. Root level mailbox indexes share the
> indexes with the originating user, but non-root level mailboxes are
> added under shared/.imap/ directory rather than shared/sub/.imap/
> directory.
>
> Although .. the whole idea of using mail/shared here doesn't really
> seem right. You want users to be able to share only mailboxes under
> shared/ and show them as shared/user/.. without the additional
> shared? I don't think I've tried that kind of a setup before. Maybe
> it should work .. maybe it does work and isn't the problem. But try
> removing that first and see if it's actually the cause of your
> problem.
>
> Also I'm not sure if I ever tried using mbox for shared mailboxes,
> but I think it should work..

k.  I'm still trying to understand that; sorry.  Yes, I was thinking of 
separating out the shared folders into a subdirectory.  I was thinking 
that the folder would need special permissions so that others could 
write to it.  Perhaps maildir solves all of these issues.

So, you'd recommend using maildir instead of mbox for shared mailboxes? 
  I don't understand how that would work if my default namespace is 
using mbox.

Would I end up with yet another namespace for maildir use?  The person 
who is sharing the mailbox will need to access that shared mailbox 
somehow, and I assume *not* using the shared namespace, as it is their 
own mailbox.

So, would it be accessed as something like 'MAILDIR/mailfolder' by that 
user (assuming 'MAILDIR' is the namespace), and 
'shared/shareuser/mailfolder' by the others?

thank you

Tom Lieuallen