[Dovecot] Permission denied error log messages
Hi Timo,
ok, I have a large 2.07 NFS setup, and I have been monitoring error messages to make sure I catch things, and I've come across a lot of messages that come in pairs and look like this :
Dec 01 17:48:35 lda(paul@xxxxxx.com): Error: write(/home/mailboxes/data/301/paul@xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com) failed: Permission denied
Dec 01 17:48:35 lda(paul@xxxxxx.com): Error: sieve: msgid=unspecified: failed to store into mailbox 'INBOX': Internal error occurred. Refer to server log for more information. [2010-12-01 17:48:34]
I run the dovecot installation as a single user, and that user owns ALL of my virtual accounts directories. I checked, and there aren't any permissions that aren't correct. All the way up the tree has the same owner and group, and there are plenty of messages that make it through without any issue.
The NFS servers don't have enough load on them to return errors for file operations, so I don't believe it is that. We use high end NetApp equipment and have never had any problems with them.
I'm baffled as to why it gets permission denied message on the tmp directory. There does not seem to be a recognizable pattern for times, or particular accounts. I've just got a heck of a lot of these messages in the deliver log error files...
I use qmail control files to feed the lda delivery for messages. When these errors happen, is the message lost? or is it still queued up in qmail's queue when the lda gives a fatal error like that?
Thanks,
Tim.
here is my dovecot -n output :
# 2.0.7: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 8.0-RELEASE-p3 i386 auth_username_format = %Lu auth_username_translation = %@ auth_verbose = yes disable_plaintext_auth = no dotlock_use_excl = yes first_valid_uid = 100 listen = * lock_method = dotlock log_path = /local/logs/dovecot.errors mail_fsync = always mail_gid = 100 mail_location = maildir:%h/Maildir mail_nfs_index = yes mail_nfs_storage = yes mail_plugins = " quota" mail_uid = 100 managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date imapflags notify mmap_disable = yes passdb { args = /bin/checkpassword_dovecot_auth driver = checkpassword } plugin { quota = maildir:User quota quota_rule = Trash:storage=+100M sieve = ~/.dovecot.sieve sieve_after = /home/mailboxes/sieve/to_spam_folder.sieve sieve_dir = ~/Maildir/sieve sieve_extensions = +notify +imapflags } protocols = imap pop3 sieve service auth { unix_listener auth-userdb { group = sn mode = 0600 user = sn } } ssl_cert =
On 2.12.2010, at 6.04, Tim Traver wrote:
ok, I have a large 2.07 NFS setup, and I have been monitoring error messages to make sure I catch things, and I've come across a lot of messages that come in pairs and look like this :
Dec 01 17:48:35 lda(paul@xxxxxx.com): Error: write(/home/mailboxes/data/301/paul@xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com) failed: Permission denied
write() doesn't check for permissions. That's done when the file is open()ed. So if that's happening, the possibilities I can think of are:
a) Bug in Dovecot b) Bug in Linux kernel c) NFS server failing the write due to permission error for some reason
You could apply the attached debug patch, it should at least make it clear what function exactly fails and get rid of the a) doubt.
I use qmail control files to feed the lda delivery for messages. When these errors happen, is the message lost? or is it still queued up in qmail's queue when the lda gives a fatal error like that?
dovecot-lda fails with tempfail exit code, so it should be retried.
Thanks Timo,
I've applied the patch, and I'll let it run till tomorrow to see what we find.
Just so you know, I'm running the latest stable branch of FreeBSD 8.1, but I'm also seeing the errors on a stable 8.0 machine.
I'll let you know what I see in the logs.
Tim.
On 12/1/2010 10:41 PM, Timo Sirainen wrote:
On 2.12.2010, at 6.04, Tim Traver wrote:
ok, I have a large 2.07 NFS setup, and I have been monitoring error messages to make sure I catch things, and I've come across a lot of messages that come in pairs and look like this :
Dec 01 17:48:35 lda(paul@xxxxxx.com): Error: write(/home/mailboxes/data/301/paul@xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com) failed: Permission denied write() doesn't check for permissions. That's done when the file is open()ed. So if that's happening, the possibilities I can think of are:
a) Bug in Dovecot b) Bug in Linux kernel c) NFS server failing the write due to permission error for some reason
You could apply the attached debug patch, it should at least make it clear what function exactly fails and get rid of the a) doubt.
I use qmail control files to feed the lda delivery for messages. When these errors happen, is the message lost? or is it still queued up in qmail's queue when the lda gives a fatal error like that? dovecot-lda fails with tempfail exit code, so it should be retried.
Timo,
ok, I have captured the error in the log file :
Dec 02 06:59:12 lda(martha@xxxxx.com): Error: ostream: write(0x284eb000, 8009) failed Dec 02 06:59:12 lda(martha@xxxxx.com): Error: write(/home/mailboxes/data/simplenet/59/martha@xxxxx.com/Maildir/tmp/1291301951.M464029P90603.mta4.scaledsystems.com) failed: Permission denied Dec 02 06:59:12 lda(martha@xxxxx.com): Error: sieve: msgid=002f01cb9230$ef3a9330$cdafb990$@com: failed to store into mailbox 'INBOX': Internal error occurred. Refer to server log for more information. [2010-12-02 06:59:11]
Does this help as to what the issue is?
Again, I'm running the latest 8.1 stable FreeBSD on this machine, although I see the same errors on a 8.0 as well... Disk isn't full, and it happened at 1:40 am, when there is virtually NO load on the machine, or on the NFS server.
Thanks,
Tim
On 12/1/2010 10:41 PM, Timo Sirainen wrote:
On 2.12.2010, at 6.04, Tim Traver wrote:
ok, I have a large 2.07 NFS setup, and I have been monitoring error messages to make sure I catch things, and I've come across a lot of messages that come in pairs and look like this :
Dec 01 17:48:35 lda(paul@xxxxxx.com): Error: write(/home/mailboxes/data/301/paul@xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com) failed: Permission denied write() doesn't check for permissions. That's done when the file is open()ed. So if that's happening, the possibilities I can think of are:
a) Bug in Dovecot b) Bug in Linux kernel c) NFS server failing the write due to permission error for some reason
You could apply the attached debug patch, it should at least make it clear what function exactly fails and get rid of the a) doubt.
I use qmail control files to feed the lda delivery for messages. When these errors happen, is the message lost? or is it still queued up in qmail's queue when the lda gives a fatal error like that? dovecot-lda fails with tempfail exit code, so it should be retried.
On 2.12.2010, at 16.22, Tim Traver wrote:
Dec 02 06:59:12 lda(martha@xxxxx.com): Error: ostream: write(0x284eb000, 8009) failed
Oh. I thought it might have been something more exotic, like writev() or pwrite(). But this is about as basic as it gets..
Again, I'm running the latest 8.1 stable FreeBSD on this machine, although I see the same errors on a 8.0 as well... Disk isn't full, and it happened at 1:40 am, when there is virtually NO load on the machine, or on the NFS server.
You could try asking in some FreeBSD list why write() on NFS would ever return EACCES.
On 12/2/2010 11:44 AM, Timo Sirainen wrote:
On 2.12.2010, at 16.22, Tim Traver wrote:
Dec 02 06:59:12 lda(martha@xxxxx.com): Error: ostream: write(0x284eb000, 8009) failed
Oh. I thought it might have been something more exotic, like writev() or pwrite(). But this is about as basic as it gets..
Again, I'm running the latest 8.1 stable FreeBSD on this machine, although I see the same errors on a 8.0 as well... Disk isn't full, and it happened at 1:40 am, when there is virtually NO load on the machine, or on the NFS server.
You could try asking in some FreeBSD list why write() on NFS would ever return EACCES.
The most common reason for EACCES from NFS is an export permissions denial, which in turn often originates from DNS and user lookup issues at the server. However it's also possible that client issues can be involved, such as mount options, NFS protocol selection, etc. You may want to start with your server vendor.
participants (3)
-
Tim Traver
-
Timo Sirainen
-
Tom Talpey