[Dovecot] wrong permission
Im still finding a number of control directories that have the wrong permission:
Jun 26 00:02:34 userimap13.xs4all.nl dovecot: IMAP(xxx): file_dotlock_create(/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do/dovecot-uidlist) failed: Permission denied
userimap1# ls -al "/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do" total 8 drw------- 2 xxx user 4096 May 12 23:43 . drwx------ 7 xxx user 4096 May 12 23:43 ..
This folder was created May 12, well after us starting to use 1.1RC versions. I currently fixed a few hundred of these (out of millions of folders), and whats interesting is that a very large percentage of those (1/3th) is the folder "Apple Mail To Do", created by Mail.App I think. Obviously that same folder is no where near 1/3th of our total folder number, so thats a bit strange.
I really doubt this is some local setting issue, because then id see much more of those. Right now it's a tiny fraction of our total folder amount, which leads me to believe it's some weird edge case in the dovecot code.
Anyone have any ideas?
Cor
On Thu, 2008-06-26 at 11:02 +0200, Cor Bosman wrote:
Im still finding a number of control directories that have the wrong permission:
Jun 26 00:02:34 userimap13.xs4all.nl dovecot: IMAP(xxx): file_dotlock_create(/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do/dovecot-uidlist) failed: Permission denied
userimap1# ls -al "/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do" total 8 drw------- 2 xxx user 4096 May 12 23:43 . drwx------ 7 xxx user 4096 May 12 23:43 ..
So the problem is it's 0600 instead of 0700?
This folder was created May 12, well after us starting to use 1.1RC versions. I currently fixed a few hundred of these (out of millions of folders), and whats interesting is that a very large percentage of those (1/3th) is the folder "Apple Mail To Do", created by Mail.App I think. Obviously that same folder is no where near 1/3th of our total folder number, so thats a bit strange.
Maybe because OS X users were upgrading to Leopard and its Mail.app started creating these mailboxes?
I really doubt this is some local setting issue, because then id see much more of those. Right now it's a tiny fraction of our total folder amount, which leads me to believe it's some weird edge case in the dovecot code.
Do you have dovecot-shared files anywhere? Have you specified umask setting in dovecot.conf?
Jun 26 00:02:34 userimap13.xs4all.nl dovecot: IMAP(xxx): file_dotlock_create(/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do/dovecot-uidlist) failed: Permission denied
userimap1# ls -al "/var/spool/mail/dovecot-control/g/gl/xxx/INBOX/.Apple Mail To Do" total 8 drw------- 2 xxx user 4096 May 12 23:43 . drwx------ 7 xxx user 4096 May 12 23:43 ..
So the problem is it's 0600 instead of 0700?
Yes, the directory is not accessible so dovecot cant read/write inside it.
I really doubt this is some local setting issue, because then id see much more of those. Right now it's a tiny fraction of our total folder amount, which leads me to believe it's some weird edge case in the dovecot code.
Do you have dovecot-shared files anywhere? Have you specified umask setting in dovecot.conf?
No shared files. I havent specified any mask.
Here's another example:
u/un/unaxxxno/INBOX/.Sent Items: total 8 drw------- 2 unxxxano user 4096 Jul 1 19:51 .
-rwxr-xr-x 1 root wheel 424263 Jun 25 13:51 /usr/local/sbin/dovecot
So this was created after we started using 1.1.1. Yesterday I only found 5 after a week of operation. So I realize this can be very hard to find as we have millions and millions of folders. In theory it could even be an NFS server bug, although we havent seen this in the mailspool directories.
FreeBSD , NetAPP NFS server, here's our config:
userimap1# dovecot -n # 1.1.1: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ ssl_ca_file: /etc/ssl/certs/verisign.pem ssl_cert_file: /etc/ssl/certs/userimap.pem ssl_key_file: /etc/ssl/private/userimap.pem disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable: /usr/local/libexec/dovecot/imap-login login_greeting: XS4ALL User-IMAP ready. login_process_size: 512 login_processes_count: 32 login_max_processes_count: 1024 max_mail_processes: 1024 first_valid_uid: 20 mail_location: maildir:%Nu:INBOX=%Nu:INDEX=/var/spool/mail/dovecot-control/indexes/%1u/%2u/%u:CONTROL=/var/spool/mail/dovecot-control/%1u/%2u/%u/INBOX mailbox_idle_check_interval: 60 mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock maildir_stat_dirs: yes mbox_read_locks: dotlock_try mbox_write_locks: dotlock_try mail_executable: /usr/local/libexec/dovecot/rawlog /usr/local/libexec/dovecot/imap mail_process_size: 512 mail_plugins: imap_quota quota imap_capability: IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA imap_client_workarounds: outlook-idle delay-newmail namespace: type: private separator: / location: maildir:%Nu:INDEX=/var/spool/mail/dovecot-control/indexes/%1u/%2u/%u:INBOX=%Nu:CONTROL=/var/spool/mail/dovecot-control/%1u/%2u/%u/INBOX inbox: yes list: yes subscriptions: yes namespace: type: private separator: / prefix: home/ location: mbox:~/mail/:INDEX=/var/spool/mail/dovecot-control/indexes/%1u/%2u/%u hidden: yes subscriptions: yes auth default: cache_size: 1024 master_user_separator: * passdb: driver: passwd-file args: /usr/local/etc/dovecot.masterusers passdb: driver: pam args: cache_key=%u%r dovecot userdb: driver: passwd plugin: quota: fs
On Jul 24, 2008, at 8:40 AM, Cor Bosman wrote:
Here's another example:
u/un/unaxxxno/INBOX/.Sent Items: total 8 drw------- 2 unxxxano user 4096 Jul 1 19:51 .
-rwxr-xr-x 1 root wheel 424263 Jun 25 13:51 /usr/local/sbin/dovecot
So this was created after we started using 1.1.1. Yesterday I only
found 5 after a week of operation. So I realize this can be very hard to
find as we have millions and millions of folders. In theory it could even be an NFS server bug, although we havent seen this in the mailspool directories.
Do you see any errors related to this in log files? Do you see
maildirfolder file inside that directory? If it really is created
without +x, then Dovecot should fail the maildirfolder file creation
and log it.
So this was created after we started using 1.1.1. Yesterday I only
found 5 after a week of operation. So I realize this can be very hard to
find as we have millions and millions of folders. In theory it could even be an NFS server bug, although we havent seen this in the mailspool directories.Do you see any errors related to this in log files? Do you see
maildirfolder file inside that directory? If it really is created
without +x, then Dovecot should fail the maildirfolder file creation
and log it.
Yes, I do see errors, thats how I find them. Permission denied errors.
Cor
On Jul 31, 2008, at 1:50 PM, Cor Bosman wrote:
So this was created after we started using 1.1.1. Yesterday I only found 5 after a week of operation. So I realize this can be very hard to find as we have millions and millions of folders. In theory it could even be an NFS server bug, although we havent seen this in the mailspool directories.
Do you see any errors related to this in log files? Do you see maildirfolder file inside that directory? If it really is created without +x, then Dovecot should fail the maildirfolder file creation and log it.
Yes, I do see errors, thats how I find them. Permission denied errors.
But what about the maildirfolder file? Does it exist? If not, do you
see an error in logs:
open(.../maildirfolder, O_CREAT) failed: Permission denied
find as we have millions and millions of folders. In theory it could even be an NFS server bug, although we havent seen this in the mailspool directories.
Do you see any errors related to this in log files? Do you see maildirfolder file inside that directory? If it really is created without +x, then Dovecot should fail the maildirfolder file creation and log it.
Yes, I do see errors, thats how I find them. Permission denied errors.
But what about the maildirfolder file? Does it exist? If not, do you
see an error in logs:open(.../maildirfolder, O_CREAT) failed: Permission denied
I dont see any logged errors with O_CREAT. Only these:
dovecot-uidlist) failed: Permission denied
The created directories are empty:
userimap1# cd /var/spool/mail/dovecot-control/r/ro/rossXXX/INBOX/.Sport.NKR userimap1# ls -al total 8 drw------- 2 rossXXX user 4096 Jul 2 18:35 . drwx------ 33 rossXXX user 4096 Jul 31 07:39 ..
Cor
On Jul 31, 2008, at 2:38 PM, Cor Bosman wrote:
But what about the maildirfolder file? Does it exist? If not, do you see an error in logs:
open(.../maildirfolder, O_CREAT) failed: Permission denied
I dont see any logged errors with O_CREAT. Only these:
dovecot-uidlist) failed: Permission denied
The created directories are empty:
userimap1# cd /var/spool/mail/dovecot-control/r/ro/rossXXX/ INBOX/.Sport.NKR userimap1# ls -al total 8 drw------- 2 rossXXX user 4096 Jul 2 18:35 . drwx------ 33 rossXXX user 4096 Jul 31 07:39 ..
That's beginning to sound like Dovecot isn't even creating these
directories. But what else could be?..
userimap1# cd /var/spool/mail/dovecot-control/r/ro/rossXXX/ INBOX/.Sport.NKR userimap1# ls -al total 8 drw------- 2 rossXXX user 4096 Jul 2 18:35 . drwx------ 33 rossXXX user 4096 Jul 31 07:39 ..
That's beginning to sound like Dovecot isn't even creating these
directories. But what else could be?..
Nothing really. We dont even use deliver. Only thing that knows about those control dirs is dovecot.
Cor
On Jul 31, 2008, at 7:31 PM, Cor Bosman wrote:
userimap1# cd /var/spool/mail/dovecot-control/r/ro/rossXXX/ INBOX/.Sport.NKR userimap1# ls -al total 8 drw------- 2 rossXXX user 4096 Jul 2 18:35 . drwx------ 33 rossXXX user 4096 Jul 31 07:39 ..
That's beginning to sound like Dovecot isn't even creating these directories. But what else could be?..
Nothing really. We dont even use deliver. Only thing that knows about those control dirs is dovecot.
All mkdir()s in imap process go through mkdir_parents(), so see if this gives you assert-crashes: diff -r 6fec5522a3b0 src/lib/mkdir-parents.c --- a/src/lib/mkdir-parents.c Thu Jul 10 22:38:31 2008 +0530 +++ b/src/lib/mkdir-parents.c Thu Jul 31 19:45:22 2008 +0300 @@ -9,6 +9,8 @@ int mkdir_parents(const char *path, mode { const char *p; int ret; + + i_assert((mode & 0100) != 0); /* EISDIR check is for BSD/OS which returns it if path contains '/' at the end and it exists.
participants (2)
-
Cor Bosman
-
Timo Sirainen