[Dovecot] Upgrade to 1.1 maildir & shared folders problems
Hello,
We recently upgraded to Dovecot 1.1 from 1.0.5 and we are having few issues:
Maildir's are not created anymore for new users if they dont excits, the directories where created before, is this a configuration issue?
Cannot subscribe to shared folders, if currently subscribed they work fine but cannot re-subscribe, also i noticed that the control directory for the namespace is not created anymore, before it was, any ideas?
//sami
conf:
1.1.1: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap pop3 ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_greeting: ready. login_processes_count: 5 verbose_proctitle: yes first_valid_uid: 1000 mail_location: maildir:~/:INDEX=/var/dovecot/index/%u:CONTROL=/var/dovecot/control/%u mail_nfs_storage: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_process_size: 1024 mail_plugins(default): acl quota imap_quota mail_plugins(imap): acl quota imap_quota mail_plugins(pop3): mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): outlook-idle, delay-newmail imap_client_workarounds(imap): outlook-idle, delay-newmail imap_client_workarounds(pop3): namespace: type: private separator: / location: maildir:~/:INDEX=/var/dovecot/index/%u:CONTROL=/var/dovecot/control/%u inbox: yes list: yes subscriptions: yes namespace: type: public separator: / prefix: shared/ location: maildir:/var/mail/jaetut:INDEX=/var/dovecot/jaetut/index/%u:CONTROL=/var/dovecot/jaetut/control/%u list: yes subscriptions: yes auth default: passdb: driver: sql args: /usr/local/etc/dovecot-sql.conf userdb: driver: sql args: /usr/local/etc/dovecot-sql.conf userdb: driver: prefetch plugin: quota: fs acl: vfile:/usr/local/etc/dovecot-acls
On Fri, 2008-06-27 at 10:50 +0300, sami@medusa.tutka.fi wrote:
Hello,
We recently upgraded to Dovecot 1.1 from 1.0.5 and we are having few issues:
- Maildir's are not created anymore for new users if they dont excits, the directories where created before, is this a configuration issue?
I did change the code so that the maildir creation is delayed until it's really needed. But I don't know of any bugs in this, and I can't reproduce your problem. Could you show the error messages from the log file you get when a new user tries to access the mailbox?
- Cannot subscribe to shared folders, if currently subscribed they work fine but cannot re-subscribe, also i noticed that the control directory for the namespace is not created anymore, before it was, any ideas?
Again the control directory creation is delayed until it's needed. So that might not be the actual problem. Are there anything in error logs when this happens?
Also could you try manually so you can see what exactly Dovecot replies to the subscribe commands? Try something like:
telnet localhost 143 a login username password b unsubscribe shared/some-mailbox c subscribe shared/some-mailbox
What are the replies?
On Sat, 28 Jun 2008, Timo Sirainen wrote:
On Fri, 2008-06-27 at 10:50 +0300, sami@medusa.tutka.fi wrote:
Hello,
We recently upgraded to Dovecot 1.1 from 1.0.5 and we are having few issues:
- Maildir's are not created anymore for new users if they dont excits, the directories where created before, is this a configuration issue?
I did change the code so that the maildir creation is delayed until it's really needed. But I don't know of any bugs in this, and I can't reproduce your problem. Could you show the error messages from the log file you get when a new user tries to access the mailbox?
Hello,
Telnet: Escape character is '^]'.
- OK ready. AUTH LOGIN testi33 testi33 AUTH OK Logged in. Connection closed by foreign host.
Log: Jun 30 11:14:47 [dovecot] imap-login: Login: user=<testi33>, method=PLAIN, rip=212.116.32.210, lip=212.116.32.130 Jun 30 11:14:47 [dovecot] child 23578 (imap) killed with signal 11
Not much to go on here, i remember running in to this same problem in some early 1.0 rc's, but if i remember correctly it just was fixed in a later release and started working. Any ideas how to proceed on this one? i could setup a test enviroment and run strace if needed?
- Cannot subscribe to shared folders, if currently subscribed they work fine but cannot re-subscribe, also i noticed that the control directory for the namespace is not created anymore, before it was, any ideas?
Again the control directory creation is delayed until it's needed. So that might not be the actual problem. Are there anything in error logs when this happens?
Also could you try manually so you can see what exactly Dovecot replies to the subscribe commands? Try something like:
telnet localhost 143 a login username password b unsubscribe shared/some-mailbox c subscribe shared/some-mailbox
What are the replies?
if i list the mail boxes it does not show the folders under shared:
- LIST (\Noselect \HasNoChildren) "/" "shared" . OK List completed.
The subscribe and unsubscribe seems to be working:
C unsubscribe shared/shared-folder C OK Unsubscribe completed. C subscribe shared/shared-folder C OK Subscribe completed.
I get this in the logs:
Jun 30 11:17:44 [dovecot] imap-login: Login: user=<username>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
It seems to be the problem is with listing the folders? as if im subscribed to the folders they work fine, but can not see the folders again in imap? The /var/mail/jaetut folder has write permission to everyone. any ideas?
//sami
On Mon, 2008-06-30 at 11:31 +0300, sami@medusa.tutka.fi wrote:
Jun 30 11:14:47 [dovecot] imap-login: Login: user=<testi33>, method=PLAIN, rip=212.116.32.210, lip=212.116.32.130 Jun 30 11:14:47 [dovecot] child 23578 (imap) killed with signal 11
That's a crash. Could you get gdb backtrace from it? See http://dovecot.org/bugreport.html how to do it.
Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
Do you use SELinux or something like that? "Operation not permitted" is not the same as "Permission denied" which comes with normal filesystem permission problems.
On Mon, 30 Jun 2008, Timo Sirainen wrote:
On Mon, 2008-06-30 at 11:31 +0300, sami@medusa.tutka.fi wrote:
Jun 30 11:14:47 [dovecot] imap-login: Login: user=<testi33>, method=PLAIN, rip=212.116.32.210, lip=212.116.32.130 Jun 30 11:14:47 [dovecot] child 23578 (imap) killed with signal 11
That's a crash. Could you get gdb backtrace from it? See http://dovecot.org/bugreport.html how to do it.
Here is a backtrace from a test-server, running newer debian than the production boxes:
#0 fs_quota_mount_init (root=0x81098f0, mount=0x0) at quota-fs.c:210 roots = (struct quota_root * const *) 0x8109890 i = 1 #1 0xb7e34bd1 in fs_quota_storage_added (quota=0x8109850, storage=0x810a148) at quota-fs.c:253 mount = (struct fs_quota_mountpoint *) 0x0 root = <value optimized out> dir = <value optimized out> is_file = false #2 0xb7e32d66 in quota_add_user_storage (quota=0x8109850, storage=0x810a148) at quota.c:467 roots = <value optimized out> storages = <value optimized out> backends = <value optimized out> path = 0x810a540 "/var/spool/mail/testi33/" path2 = <value optimized out> i = 1 is_file = false #3 0xb7e37d44 in quota_mail_storage_created (storage=0x810a148) at quota-storage.c:469 qstorage = (union mail_storage_module_context *) 0x810a240 #4 0x080a0646 in mail_storage_create (ns=0x8109d40, driver=0x8100178 "maildir", data=<value optimized out>, user=0xbf971f65 "testi33", flags=3328, lock_method=FILE_LOCK_METHOD_FCNTL, error_r=0xbf971028) at mail-storage.c:254 _data_stack_cur_id = 3 storage_class = (struct mail_storage *) 0x80f9640 storage = (struct mail_storage *) 0x810a148 classes = (struct mail_storage * const *) 0xa home = <value optimized out> value = <value optimized out> i = 0 count = 1 #5 0x0809eaa0 in mail_namespaces_init (pool=0x8109d28, user=0xbf971f65 "testi33", namespaces_r=0xbf971084) at mail-namespace.c:81 _data_stack_cur_id = 2 namespaces = (struct mail_namespace *) 0x0 ns = <value optimized out> ns_p = (struct mail_namespace **) 0xbf971038 flags = 3072 lock_method = FILE_LOCK_METHOD_FCNTL mail = <value optimized out> data = 0xbf971d30 "maildir:/var/spool/mail/testi33//:INDEX=/var/dovecot/index/testi33:CONTROL=/var/dovecot/control/testi33" error = <value optimized out> i = 1 #6 0x080681bf in main (argc=135305456, argv=0xbf971124, envp=0xbf971134) at main.c:234 home = 0x0
Seems to be quota plugin related, i removed the plugin and i could log on with a new user that did not have a maildir yet.
When we upgraded to 1.1 i enabled the quota plugin witch i forgot to mention (sorry) since it was working nicely and reporting the quota to the users. quota is from a netapp filer that we use over nfs, any idea if we can make this work? later we will change to dovecots deliver and use it's quota, but mean time it would be nice for the users to see their quota directly from the mail client.
Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
Do you use SELinux or something like that? "Operation not permitted" is not the same as "Permission denied" which comes with normal filesystem permission problems.
Not using SELinux, the location is also nfs if it makes a diffrence (control + index files are going to a local disk). i get the same error on the testbox as well, anything i could do to find out more why it's not creating the file?
//sami
On Mon, 30 Jun 2008 sami@medusa.tutka.fi wrote:
Seems to be quota plugin related, i removed the plugin and i could log on with a new user that did not have a maildir yet.
When we upgraded to 1.1 i enabled the quota plugin witch i forgot to mention (sorry) since it was working nicely and reporting the quota to the users. quota is from a netapp filer that we use over nfs, any idea if we can make this work? later we will change to dovecots deliver and use it's quota, but mean time it would be nice for the users to see their quota directly from the mail client.
This seems to happen also on local filesystem, if quota plugin is enabled as fs: users that do not have maildirs cannot login and the crash happens, any possibility for a fix?;)
Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
Do you use SELinux or something like that? "Operation not permitted" is not the same as "Permission denied" which comes with normal filesystem permission problems.
Not using SELinux, the location is also nfs if it makes a diffrence (control + index files are going to a local disk). i get the same error on the testbox as well, anything i could do to find out more why it's not creating the file?
//sami
I tested this more and it seems that the dovecot-acl-list file is created with permission only to the current user:
-rw------- 1 1002 sami 55 2008-07-07 09:40 dovecot-acl-list
So i manualy added rw permission to everyone and it seems to be working, the uid on the file changes everytime someone logs on, but the permissions seem to be sticking to it, any reason why dovecot would remove the file at anypoint and re-create it with the "wrong" permissions?
//sami
Hello,
Any toughts on this one?
//sami
On Mon, 7 Jul 2008 sami@medusa.tutka.fi wrote:
On Mon, 30 Jun 2008 sami@medusa.tutka.fi wrote:
Seems to be quota plugin related, i removed the plugin and i could log on with a new user that did not have a maildir yet.
When we upgraded to 1.1 i enabled the quota plugin witch i forgot to mention (sorry) since it was working nicely and reporting the quota to the users. quota is from a netapp filer that we use over nfs, any idea if we can make this work? later we will change to dovecots deliver and use it's quota, but mean time it would be nice for the users to see their quota directly from the mail client.
This seems to happen also on local filesystem, if quota plugin is enabled as fs: users that do not have maildirs cannot login and the crash happens, any possibility for a fix?;)
Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
Do you use SELinux or something like that? "Operation not permitted" is not the same as "Permission denied" which comes with normal filesystem permission problems.
Not using SELinux, the location is also nfs if it makes a diffrence (control + index files are going to a local disk). i get the same error on the testbox as well, anything i could do to find out more why it's not creating the file?
//sami
I tested this more and it seems that the dovecot-acl-list file is created with permission only to the current user:
-rw------- 1 1002 sami 55 2008-07-07 09:40 dovecot-acl-list
So i manualy added rw permission to everyone and it seems to be working, the uid on the file changes everytime someone logs on, but the permissions seem to be sticking to it, any reason why dovecot would remove the file at anypoint and re-create it with the "wrong" permissions?
//sami
On Mon, 2008-07-07 at 10:22 +0300, sami@medusa.tutka.fi wrote:
On Mon, 30 Jun 2008 sami@medusa.tutka.fi wrote:
Seems to be quota plugin related, i removed the plugin and i could log on with a new user that did not have a maildir yet.
When we upgraded to 1.1 i enabled the quota plugin witch i forgot to mention (sorry) since it was working nicely and reporting the quota to the users. quota is from a netapp filer that we use over nfs, any idea if we can make this work? later we will change to dovecots deliver and use it's quota, but mean time it would be nice for the users to see their quota directly from the mail client.
This seems to happen also on local filesystem, if quota plugin is enabled as fs: users that do not have maildirs cannot login and the crash happens, any possibility for a fix?;)
It crashes because it can't find where the filesystem is mounted at. I don't know why that would happen, but I fixed the crash anyway: http://hg.dovecot.org/dovecot-1.1/rev/5659ce2398e4
Jun 30 11:19:07 [dovecot] IMAP(username): fchown(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted Jun 30 11:19:07 [dovecot] IMAP(username): dovecot-acl-list creation failed: safe_mkstemp(/var/mail/jaetut/temp.valas.17956.7b8393cabde89cbd) failed: Operation not permitted
Do you use SELinux or something like that? "Operation not permitted" is not the same as "Permission denied" which comes with normal filesystem permission problems.
Oh, right, the real error is that it tries to change the file's group to one that the user doesn't belong to. So you probably have dovecot-shared file which has a wrong group.
I tested this more and it seems that the dovecot-acl-list file is created with permission only to the current user:
-rw------- 1 1002 sami 55 2008-07-07 09:40 dovecot-acl-list
This file should be created using the same permissions as the mailbox root directory, which I guess in your case would be /var/mail/jaetut. Anyway I wrote a patch to help find out this when mail_debug=yes: http://hg.dovecot.org/dovecot-1.1/rev/4e3e73ff1b92
So i manualy added rw permission to everyone and it seems to be working, the uid on the file changes everytime someone logs on, but the permissions seem to be sticking to it, any reason why dovecot would remove the file at anypoint and re-create it with the "wrong" permissions?
The file (as well as many other files created by Dovecot) is updated by recreating it.
On Sun, 20 Jul 2008, Timo Sirainen wrote:
On Mon, 2008-07-07 at 10:22 +0300, sami@medusa.tutka.fi wrote:
On Mon, 30 Jun 2008 sami@medusa.tutka.fi wrote:
It crashes because it can't find where the filesystem is mounted at. I don't know why that would happen, but I fixed the crash anyway: http://hg.dovecot.org/dovecot-1.1/rev/5659ce2398e4
Thank you, this fixed the problem and everything seems to be working nicely ;)
Oh, right, the real error is that it tries to change the file's group to one that the user doesn't belong to. So you probably have dovecot-shared file which has a wrong group.
I tested this more and it seems that the dovecot-acl-list file is created with permission only to the current user:
-rw------- 1 1002 sami 55 2008-07-07 09:40 dovecot-acl-list
This file should be created using the same permissions as the mailbox root directory, which I guess in your case would be /var/mail/jaetut. Anyway I wrote a patch to help find out this when mail_debug=yes: http://hg.dovecot.org/dovecot-1.1/rev/4e3e73ff1b92
So i manualy added rw permission to everyone and it seems to be working, the uid on the file changes everytime someone logs on, but the permissions seem to be sticking to it, any reason why dovecot would remove the file at anypoint and re-create it with the "wrong" permissions?
The file (as well as many other files created by Dovecot) is updated by recreating it.
Thanks for this too, later the gid will be same with all the users so i guess this wont be a problem anymore.
//sami
participants (2)
-
sami＠medusa.tutka.fi
-
Timo Sirainen