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 at xxxxxx.com): Error:
write(/home/mailboxes/data/301/paul at
xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com)
failed: Permission denied
Dec 01 17:48:35 lda(paul at 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 = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
userdb {
driver = prefetch
}
userdb {
args = /bin/checkpassword_dovecot_deliver
driver = checkpassword
}
verbose_proctitle = yes
protocol pop3 {
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
}
protocol lda {
info_log_path = /local/logs/dovecot-deliver.log
log_path = /local/logs/dovecot-deliver-errors.log
mail_plugins = " quota sieve"
}
protocol imap {
mail_plugins = " quota imap_quota"
}
protocol sieve {
managesieve_sieve_capability = comparator-i;ascii-numeric fileinto
reject vacation imap4flags notify include envelope body relational regex
subaddress copy
}
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 at xxxxxx.com): Error: > write(/home/mailboxes/data/301/paul at xxxxxx.com/Maildir/tmp/1291254514.M620308P83269.mta2.scaledsystems.com) > failed: Permission deniedwrite() 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 1321 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20101202/e22a350c/attachment-0002.obj>
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 at xxxxxx.com): Error: >> write(/home/mailboxes/data/301/paul at 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 at xxxxx.com): Error: ostream: write(0x284eb000, 8009) failed Dec 02 06:59:12 lda(martha at xxxxx.com): Error: write(/home/mailboxes/data/simplenet/59/martha at xxxxx.com/Maildir/tmp/1291301951.M464029P90603.mta4.scaledsystems.com) failed: Permission denied Dec 02 06:59:12 lda(martha at 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 at xxxxxx.com): Error: >> write(/home/mailboxes/data/301/paul at 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.