1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Why is Dovecot not working for me?
==================================
* *Dovecot always logs an error message* if anything goes wrong, so make sure
you're looking at the correct log files. Debug messages may be written to a
different log file than error messages. See <Logging.txt>.
* Are you upgrading? Make sure you read the <upgrading documents>
[Upgrading.txt].
* Make sure you're modifying the correct config file! Ubuntu creates two of
them. Other distributions may also have older config files lying around. For
example add "garbage=blah" to the config file and verify that Dovecot now
fails to start up.
* Try logging in manually by sending IMAP commands. If you're trying with an
IMAP client you can't be sure if the problem is with the client's
configuration or Dovecot's configuration. Many IMAP clients handle all
errors simply by showing you the login password dialog, even if the problem
has nothing to do with authentication. See <TestInstallation.txt> (or
<TestPop3Installation.txt>).
* Are you using an old version? If you have a problem, see if NEWS
[http://dovecot.org/doc/NEWS] file mentions anything related to it. There
are also <binary packages> [PrebuiltBinaries.txt] available for newer
versions.
If you have upgraded OpenVZ to LXC (ProxMox 4) and you are getting permisssion
issues
-------------------------------------------------------------------------------------
This is due to ACL option being added to mount options. Simple fix is to run
---%<-------------------------------------------------------------------------
setfacl -k /var/run/dovecot
setfacl -b /var/run/dovecot/*
---%<-------------------------------------------------------------------------
and the issue should go away. For more information about this, see
https://forum.proxmox.com/threads/permission-error-w-sockets-inside-ct-since-migration-to-pve-4-1.25244/
It says "Authentication failed"
-------------------------------
First of all enable 'auth_debug_passwords=yes' and see if the logs show what
the problem is. For non-PAM setups it should contain all the information needed
to solve the problem. If it's trying to use a wrong password scheme, you can
change that. See <Authentication.PasswordSchemes.txt>.
'Aborted login (no auth attempts)' means that the client isn't even attempting
to log in. Most likely you have 'disable_plaintext_auth=yes' (default) and the
client isn't configured to use SSL/TLS (or you've also set 'ssl=no').
If you're using <PAM> [PasswordDatabase.PAM.txt]:
* Make sure that Dovecot's auth process is running as root (assuming it's
using '/etc/shadow').
* PAM errors aren't written to Dovecot's own logs. Usually they go to
'/var/log/auth.log' or something similar.
* Unfortunately PAM's error messages aren't always all that helpful in
figuring out what exactly the problem is.
* You could (temporarily) try to use <passdb shadow>
[PasswordDatabase.Shadow.txt] instead to see if it logs something more
understandable.
* Usually the problem is that you don't have a correctly named file in
'/etc/pam.d/'. See <PasswordDatabase.PAM.txt>.
Authenticated SMTP is hanging when authenticating, when configured with dovecot
authenticator
---------------------------------------------------------------------------------------------
It is possible that you SMTP daemon is configured with the wrong socket. Please
note that '/run/dovecot/auth-client' and '/run/dovecot/auth-userdb' do respond
do different protocols. They are however very similar and it is possible that
the difference may not be reported as an error and the SMTP server is waiting
for a response that will never come.
It's not finding my emails
--------------------------
'mail_debug=yes' makes Dovecot log where it's really looking for mails. Also
'auth_debug=yes' may be helpful in debugging. See <MailLocation.txt> for how to
configure where the mails are looked up from.
Permission errors accessing the mail storage
--------------------------------------------
---%<-------------------------------------------------------------------------
lda(user1): Error: chdir(/home/user1/) failed: Permission denied
(euid=1025(user1) egid=1026(user1) stat() failed: No such file or directory,
euid is not dir owner)
---%<-------------------------------------------------------------------------
Check out the access permissions of the mentioned directory, check:
1. Unix permissions with the command 'ls -aln /home/user1', see Unix
permissions
[https://en.wikipedia.org/wiki/File_system_permissions#Traditional_Unix_permissions],
as well as make sure the user has "x" permission for "'/'" and all
directories, just "'/home'" in this case, test with: "'su - user1 ls
-aln /home/user1'"
2. security tools, like SELinux: run "'sestatus'" and "'grep -i AVC
/var/log/audit/audit.log'" to identify SELinux caused denials,
3. what file system the storage is located on, for instance AFS implements
different access permissions or POSIX eXtended attributes may change the
traditional permissions.
---%<-------------------------------------------------------------------------
Couldn't create mailbox list lock
/data/mail/domain.com/username/mailboxes.lock:
file_create_locked(/data/mail/domain.com/username/mailboxes.lock) failed:
link(/data/mail/domain.com/username/mailboxes.lock6628a230290f9029,
/data/mail/domain.com/username/mailboxes.lock) failed: Operation not permitted
---%<-------------------------------------------------------------------------
1. Your filesystem is not supported
2. You have SELinux/AppArmor/RBAC or some other security framework that
prevents this
(This file was created from the wiki on 2019-06-19 12:42)
|