-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Nov 2013, Google wrote:
Nov 24 17:34:27 proliant-1 dovecot: [ID 583609 mail.error] imap(mark): Error:
rename(/mpool/mail/mark/dovecot.index.log.newlock,
/mpool/mail/mark/dovecot.index.log) failed: Permission denied
That's a filesystem problem.
The output from doveconf -n (this is changes from the default settings I
think?) is:
root@proliant-1:~# doveconf -n
# 2.0.20: /etc/opt/csw/dovecot/dovecot.conf
# OS: SunOS 5.11 i86pc zfs
auth_first_valid_uid = 101
disable_plaintext_auth = no
first_valid_uid = 101
mail_location = maildir:/mpool/mail/%u
passdb {
driver = pam
}
ssl_cert = </opt/csw/ssl/certs/dovecot.pem
ssl_key = </opt/csw/ssl/private/dovecot.pem
userdb {
driver = passwd
}
The mail_location is in a ZFS filesystem on my RAIDz array. I couldnt think
of any other way of creating user-specific folders in the location. As the value
suggests, each user gets their own directory on the filesystem for mail.
The users do have distinct home directories (from passwd) separated from
the mail location?
Is this still a ‘safe’ way to do things or would I be better off relocating each
user’s ‘home’ directory to the pool somehow?
This is what the directory currently looks like:
mark@proliant-1:~$ ls -la /mpool/mail
total 6
drwxrwxrwx+ 3 root root 3 2013-11-24 17:17 .
drwxr-xr-x+ 5 root root 5 2013-11-24 13:50 ..
drwxrwxrwx+ 5 mark staff 9 2013-11-24 22:20 mark
mark@proliant-1:~$ ls -la /mpool/mail/mark/
total 14
drwxrwxrwx+ 5 mark staff 9 2013-11-24 22:20 .
drwxrwxrwx+ 3 root root 3 2013-11-24 17:17 ..
drwxrwxrwx+ 2 mark staff 2 2013-11-24 17:17 cur
-rwxrwxrwx+ 1 mark staff 51 2013-11-24 22:20 dovecot-uidlist.tmp
-rwxrwxrwx+ 1 mark staff 8 2013-11-24 22:20 dovecot-uidvalidity
-rwxrwxrwx+ 1 mark staff 0 2013-11-24 17:17 dovecot-uidvalidity.529234ad
-rwxrwxrwx+ 1 mark staff 40 2013-11-24 22:20 dovecot.index.log.newlock
drwxrwxrwx+ 2 mark staff 2 2013-11-24 17:17 new
drwxrwxrwx+ 2 mark staff 3 2013-11-24 17:21 tmp
Any ideas?
is it possible that two Dovecot instances try to access the same storage ?
Or is there some hardening (SELinux/AppArmor) in action? Or are there some
special ACLs in ZFS that prevent that rename() operation on file system
level? Does the user mark has the permission at all?
- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUpW1n13r2wJMiz2NAQL6+wf/UdkI0kKZKwRT1+VgSxE2QJqVwrDr0GN2
IK5fljL3Hnx4PDjnofEJ6yXT7xJGTveaZ9yQahQbx0oakBBTKsEgZsNxBB+TOyjE
MsYBzYbQKK+JqR7yUt3YwnJXmPrCATOhd0WKqgX4xb94X4nn3id2/l3bjqNnQUtm
QPB2r+gVT2AtisB5Onzaocf7wdkPoMD1vMaW+Z9VqSBvzWzezoxoEXDbButWkrQf
C1K0r+eK+IU3KxXboZ2ceu4QqlFth8GlOX9F9e2zFfRJ747qJcmEI9wxfbqCkBKs
ic+A//km4mv6Y6erObBOj/jtT82jm7P0RBWBKkmKnO6Fg7AI/GIvQg==
=qGop
-----END PGP SIGNATURE-----
