These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Roundcube SMTP Error (535): Authentication failed. on the new forum.
Web Hosting and Cloud Computing Control Panels
I'm having this exact problem. Did you find a solution?
Same problem here. New install ubuntu 14.04. Also not able to authenticate login to email server using outlook. mail log showing. warning: SASL authentication failure: cannot connect to saslauthd server: No such file or director
Any help would be appreciated. Thanks
Check to see if saslauthd is running:
# service saslauthd statusIf it's not, start it up.
# service saslauthd start--
Check out the forum guidelines!
Yes, service saslauthd is running.
I've also reported this issue, here: https://www.virtualmin.com/node/53194
Attention is definitely needed to this. The issue never occurred on previous installs. Roundcube, nor any external mail authentication is possible at the moment, ie. can't send via Gmail as 'send as' using authentication (ie. TLS/port 587).
To the Virtualmin Devs, let me know if you need to see any specific logs to help rectify this issue.
Yes, saslauthd is running:
service saslauthd status● saslauthd.service - LSB: saslauthd startup script
Loaded: loaded (/etc/init.d/saslauthd; generated; vendor preset: enabled)
Active: active (running) since Mon 2017-08-21 02:32:22 UTC; 6h ago
Docs: man:systemd-sysv-generator(8)
Process: 338 ExecStart=/etc/init.d/saslauthd start (code=exited, status=0/SUCCESS)
Tasks: 5 (limit: 4915)
CGroup: /system.slice/saslauthd.service
├─386 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
├─387 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
├─388 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
├─389 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
└─390 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
Found the problem. The configuration has changed somewhere along the way, and we need to explicitly setup saslauthd to put its socket inside of the Postfix chroot.
So, edit
/etc/default/saslauthd, and change the OPTIONS and PARAMS lines to this:OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
They're the last lines in the file, probably. If there's more than one of each, delete the extras (I noticed this happened on one of my test boxes, maybe due to running the installer twice, even though it's not supposed to do that).
Then restart saslauthd:
# systemctl restart saslauthdRoundCube, and any other mail client that connects via SMTP to send mail with a username and password, should work fine after this.
--
Check out the forum guidelines!
Hi Joe, Thanks for your efforts. I tried the above, but didn't get any different result, not even with server reboot. tail of /var/log/mail.log :
Aug 22 23:29:47 s49 postfix/smtpd[1441]: connect from mail-ua0-x233.google.com[{ip}]Aug 22 23:29:51 s49 postfix/smtpd[1441]: warning: SASL authentication failure: Password verification failed
Aug 22 23:29:51 s49 postfix/smtpd[1441]: warning: mail-ua0-x233.google.com[{ip}]: SASL PLAIN authentication failed: authentication failure
Aug 22 23:29:51 s49 postfix/smtpd[1441]: lost connection after AUTH from mail-ua0-x233.google.com[{ip}]
Aug 22 23:29:51 s49 postfix/smtpd[1441]: disconnect from mail-ua0-x233.google.com[{ip}] ehlo=2 starttls=1 auth=0/1 commands=3/4
For the record, my systems use : user@domain.com : for mail authentication (as configured in Viirtualmin, Server Template, Mail for domain) Could this be causing any hiccup (I've always used that setting in the past) Happy to try / check anything else you need to check. Thanks.
You can test if that's the problem by using the other name (when you use user@domain format names, every user gets two usernames, because some programs and services won't work with the @ username). I think it defaults to using a ., but it might be a - (e.g. user.domain.tld, instead of user@domain.tld). You can check your /etc/passwd to see what the users are actually called.
I wouldn't think that would be the problem, but it's easy to test, so that's a good next step.
--
Check out the forum guidelines!
Hi Joe. Thanks for this. Won't be able to test this for 2 days, but will update the ticket then.
Hi Joe. I can now confirm that your fix worked with Roundcube. Thank you. I still had the issue of being able to authenticate via Gmail, but this is because the email@domain authentication was not working. Checking /etc/passed, I can now authenticate with user-domain instead, and that'll do for me. Thank you.
You can test from the command line with "testsaslauthd -u username -p password". Should get an "OK Success" type response when it's all good.
Thanks noisemarine. But I was getting a failed error because of a missing dependency. This might be of use to anyone who's getting a failed error despite correct username and password. https://blog.felipe-alfaro.com/2006/05/20/saslauthd-and-testsaslauthd/
While we're on the subject, another issue I ran into is that some of my metapackages for Ubuntu (maybe Debian, too) don't depend on the php-mbstring package, which is required for RoundCube Unicode support (and, it has an ugly silent seeming failure mode where you have to spelunk into the Roundcube logs hidden inside the install directory to even know why it's failing). Installing the php-mbstring package solves the "blank screen on login" problem, if anyone runs into that.
Both of these issues will be fixed in the next roll out of the metapackages and the virtualmin-config package (they won't be fixed for existing installations...only new ones after the new packages go out, so go ahead and do these changes manually if you've got production systems).
--
Check out the forum guidelines!
Hmmm...thanks joe, but I noticed that my /etc/default/saslauth file on a new ubuntu 16.04 install was empty. There is nothing in this file, so I replacing any line is out of the question. What should be in this file anyways?
That won't work at all. ;-)
It should contain:
#
# Settings for saslauthd daemon
# Please read /usr/share/doc/sasl2-bin/README.Debian for details.
#
# Should saslauthd run automatically on startup? (default: no)
START=yes
# Description of this saslauthd instance. Recommended.
# (suggestion: SASL Authentication Daemon)
DESC="SASL Authentication Daemon"
# Short name of this saslauthd instance. Strongly recommended.
# (suggestion: saslauthd)
NAME="saslauthd"
# Which authentication mechanisms should saslauthd use? (default: pam)
#
# Available options in this Debian package:
# getpwent -- use the getpwent() library function
# kerberos5 -- use Kerberos 5
# pam -- use PAM
# rimap -- use a remote IMAP server
# shadow -- use the local shadow password file
# sasldb -- use the local sasldb database file
# ldap -- use LDAP (configuration is in /etc/saslauthd.conf)
#
# Only one option may be used at a time. See the saslauthd man page
# for more information.
#
# Example: MECHANISMS="pam"
MECHANISMS="pam"
# Additional options for this mechanism. (default: none)
# See the saslauthd man page for information about mech-specific options.
MECH_OPTIONS=""
# How many saslauthd processes should we run? (default: 5)
# A value of 0 will fork a new process for each connection.
THREADS=5
# Other options (default: -c -m /var/run/saslauthd)
# Note: You MUST specify the -m option or saslauthd won't run!
#
# WARNING: DO NOT SPECIFY THE -d OPTION.
# The -d option will cause saslauthd to run in the foreground instead of as
# a daemon. This will PREVENT YOUR SYSTEM FROM BOOTING PROPERLY. If you wish
# to run saslauthd in debug mode, please run it by hand to be safe.
#
# See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information.
# See the saslauthd man page and the output of 'saslauthd -h' for general
# information about these options.
#
# Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"
# Example for non-chroot Postfix users: "-c -m /var/run/saslauthd"
#
# To know if your Postfix is running chroot, 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.
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
I'm not sure how it would end up empty (we don't do anything during installation that would/could zero it out that I can see). That's a bit unnerving. Hard to know what else might be bogus on the system. But, if you don't have other random empty files that should contain configuration options, it may just be a fluke.
--
Check out the forum guidelines!
@onlinewebs /etc/default/saslauthd
Oh, lort. Yeah, that was a typo. It should definitely be
/etc/default/saslauthd.--
Check out the forum guidelines!
Thanks joe. Works perfect. Have a nice day.
Thanks Joe. It worked. I owe you a Cup of Joe :D
One more thing if its not too much of a bother to you. I want to send emails through SMTP from PHP and I need the Port and auth details for that. Could you check this thread too? https://www.virtualmin.com/node/53061
Thanks
Joe you are the man ;)
Thanks from Portugal :)
Nelson Costa https://nelsoncosta.ovh https://nelsondcosta23.github.io/