...this was a hard one to describe in a title. This description should highlight the problem.


  • I was following the Workaround.org tutorial to install a postfix, dovecot (plus some additional plugins) stack.
  • Running on a Ubuntu 12.04 machine (VM with Vagrant/Chef)
  • Dovecot v2.0.19
  • Postfix v2.9.6

Conf. Files


service auth {    
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail

Edit - additional config info(some overlap)

service auth {
# auth_socket_path points to this userdb socket by default. It's typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone's userdb lookups.
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail

# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
  mode = 0660
  user = postfix
  group = postfix

# Auth process is run as this user.
#user = $default_internal_user
user = dovecot


userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n allow_all_users=yes

ls -la /var/run/dovecot/auth-userdb

srw-r--r-- 1 vmail vmail 0 Jun 20 13:04 /var/run/dovecot/auth-userdb

Postfix master.cf

dovecot    unix  -      n       n       -       -       pipe
   flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -d ${recipient}


I have followed the tutorial pretty closely, changing only some minor things. I arrived at the "Testing mail delivery" and ran echo test | mail test@chefdovecot.com

The mail didn't arrive since find /var/vmail didn't show anything.

In the server syslog the following errors are present:

postfix/pickup[16842]: 019023A06AB: uid=1000 from=<vagrant>
postfix/cleanup[19542]: 019023A06AB: message-id=   <20130620140358.019023A06AB@mail-server-berkshelf>
postfix/qmgr[16843]: 019023A06AB: from=<vagrant@mail-server-berkshelf.localdomain>, size=382, nrcpt=1 (queue active)
dovecot: lda: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: lda: Debug: Module loaded: /usr/lib/dovecot/modules/lib90_sieve_plugin.so
dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Connection refused
dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
postfix/pipe[19545]: 019023A06AB: to=<test@chefdovecot.com>, relay=dovecot, delay=1.2, delays=0.04/0.01/0/1.1, dsn=4.3.0, status=deferred (temporary failure)

The "connection refused" error should be the error I'm attacking, right? I've searched in a lot of places to understand what is going on here, but haven't come across anything helpful.

Can anyone provide any leads or insights? A solution would be great, but I'm happy to accept some new ideas to try out.

  • I've always used postfix or dovecot as the user for the authdb file..
    – NickW
    Jun 21 '13 at 8:37
  • Could a "Connection refused" error have to do with who I'm running the processes as? I would expect that to be a file permission error or such. From the error message, it seems that a connection is actually trying to be made, but gets rejected.
    – Adam
    Jun 21 '13 at 8:42
  • Yeah, it could be something "underneath" the file presented, if you're using SQL, can you see any connection being attempted? It says to look in the dovecot log for further details though, is there one?
    – NickW
    Jun 21 '13 at 8:50
  • I am using SQL. The request via auth-userdb (which I assume is to query the password and authenticate), never makes it to MySQL. Postfix queries for the domain, user and destination all get through (this is of course before the auth-userdb error). I changed the permissions to 777 to eliminate to possibility of simple file permissions, and that didn't help. Any thoughts on how to uncover some of the "underneath" workings? Also, dovecot is logging to syslog, the above snippet are a mix between dovecot and postfix log msgs.
    – Adam
    Jun 21 '13 at 9:11
  • This is the LDA part, how have you configured that in your master.cf?
    – NickW
    Jun 21 '13 at 9:20

The connection refused error is indeed the problem. Connection refused on unix sockets is not terribly intuitive, but it indicates that there is nothing listening on the socket (typically, the process is dead, or the file given as the address wasn't a socket at all). This should never be a permissions issue, unless dovecot is unable to open the socket for listening due to permissions.

Try stopping dovecot and postfix, removing the socket file at /var/run/dovecot/auth-userdb, and starting postfix and dovecot again (ensuring the user dovecot is running as has permissions on /var/run/dovecot). Usually this will fix this type of issue.

Netstat will also display unix domain sockets. Check its output (use netstat -nvlap | less and search for the path or for dovecot) to ensure dovecot is listening.

  • When you say "removing the socket file", you don't mean rm -f right? I suppose you mean from the config file? Could you clarify that part a bit?
    – Adam
    Jun 24 '13 at 8:31
  • I absolutely mean to say delete the socket file using rm. When you open a new listening socket, the file will be created if it doesn't exist; removing it, starting the process that listens on it (so it gets created), and starting the process that connects to it should ensure consistency. Jun 24 '13 at 8:45
  • Worked great. Thanks for your input, I didn't have the knowledge to try something like that.
    – Adam
    Jun 24 '13 at 9:17
  • This solution also works well also in case the socket connection became unresponsive after once running out of sockets on a VPS (the OpenVZ "numothersock" limit). The exact error message then is dovecot: lda: Error: userdb lookup(mail@example.com): Request timed out.
    – tanius
    Feb 18 '17 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.