Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My server has developed an expected problem where I am unable to connect from a mail client.

I've looked at the server logs and the only thing that looks to identify a problem are events like the following:

Nov 23 18:32:43 hig3 dovecot: imap-login: Login: user=, method=PLAIN, rip=xxxxxxxx, lip=xxxxxxx, TLS Nov 23 18:32:55 hig3 postfix/smtpd[11653]: connect from xxxxxxx.co.uk[xxxxxxx] Nov 23 18:32:55 hig3 postfix/smtpd[11653]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Nov 23 18:32:55 hig3 postfix/smtpd[11653]: warning: xxxxxxx.co.uk[xxxxxxxx]: SASL LOGIN authentication failed: generic failure Nov 23 18:32:56 hig3 postfix/smtpd[11653]: lost connection after AUTH from xxxxxxx.co.uk[xxxxxxx] Nov 23 18:32:56 hig3 postfix/smtpd[11653]: disconnect from xxxxxxx.co.uk[xxxxxxx]

The problem is unusual, because just half an hour previously at my office, I was not being prompted for a correct username and password in my mail client. I haven't made any changes to the server, so I can't understand what would have happened to make this error occur.

Searches for the error messages yield various results, with 'fixes' that I'm uncertain of (obviously don't want to make it worse or fix something that isn't broken).

When I run

testsaslauthd -u xxxxx -p xxxxxx

I also get the following result:

connect() : No such file or directory

But when I run

testsaslauthd -u xxxxx -p xxxxxx -f /var/spool/postfix/var/run/saslauthd/mux -s smtp

I get:

0: OK "Success."

I found those commands on another forum and am not entirely sure what they mean, but I'm hoping they might give an indication of where the problem might lie.

When I run

ps -ef|grep saslauthd

This is the output:

root 1245 1 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1250 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1252 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1254 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 1255 1245 0 Nov24 ? 00:00:00 /usr/sbin/saslauthd -a pam -c -m /var/spool/postfix/var/run/saslauthd -r -n 5 root 5902 5885 0 08:51 pts/0 00:00:00 grep --color=auto saslauthd

If it makes any difference, I'm running Ubuntu 10.04.1, Postfix 2.7.0 and Webmin/ Virtualmin.

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted
+50

Postfix can run in a chroot (by default in /var/spool/postfix) or not. If it is, it will try to open /var/spool/postfix/var/run/saslauthd/mux for sasl authentication. If it's not, it will try to open /var/run/saslauthd/mux

It seems that, for some reason, your postfix instance was running in a chroot, and it's not anymore. It's odd, but that's what I guess from the details of your question. If it's what's happened, you may change saslauthd configuration to use /var/run/saslauthd or run postfix in a chroot again.

To know if your Postfix is running chroot, you can check /etc/postfix/master.cf : If it has the line smtp inet n - y - - smtpd or smtp inet n - - - - smtpd, then your Postfix is running in a chroot. If it has the line smtp inet n - n - - smtpd then your Postfix is NOT running in a chroot. This check comes from /etc/default/saslauthd (Ubuntu sasl configuration file).

share|improve this answer
    
Your answer has just crystalised the link between the line in master.cf and chroot - thank you! Although I'm sure I'd checked this countless times earlier, for whatever reason, I missed the third 'n'. I'm mystified as to how it came to suddenly change in the master.cf file, though. –  James Nov 27 '12 at 13:55
add comment

No such file or directory when trying to connect suggests the UNIX socket it is looking for SASLAuthd on doesn't exist.

If you run "ps -ef ¦ grep saslauthd", can you see it still running?

If so, maybe see if it has its own log location.

If not it could just need a restart.

share|improve this answer
1  
Thanks for the reply. I think it's running - I've added the output to my question and am assuming that the output shows that it's running. I've restarted both the server and the service, but to no avail. Why might this have happened without any intervention on my part? Seems like an odd thing to happen. –  James Nov 25 '12 at 8:54
add comment

Every time I've encountered a similar problem with saslauthd (and when everything else has been double-checked), it has been about directory/file permissions. Check each and every step of this /var/spool/postfix/var/run/saslauthd path to make sure saslauthd actually can get there.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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