mazek

Member
Sep 25, 2005
6
0
151
Hi,

Ive found many similar problems in archive but none of give solutions helped. Quite common problem with smtp authorization:

fixed_plain authenticator failed for ([172.19.9.24]) [x.x.x.x]: 535 Incorrect authentication data ([email protected])

I have tried:
- turning off pop3 befor smtp, antirelayd turnde off, exim restarted
- turning off "Attempt to prevent pop3 connection floods" in setting tweak
- eximup & upcp
- /etc/doemodomains and demousers is empty
- /etc/relayhosts relayhostsusers emptied & exim restarted
- resolved logrotate /tmp noexec issue

and no idea what has changed after last update.

WHM 10.8.0 cPanel 10.9.0-S9966
CentOS 4.5 x86_64 - WHM X v3.1.0


any ideas?

thank You.
 
Last edited:

jerrybell

Well-Known Member
Nov 27, 2006
90
0
156
So, I ran into the same problem. After looking at the exim config, I tried using the "unix" username and password - not the email account id and password - sure enough it works. In order to get it to work the way it should work, we'll have to figure out how to check a password against the database where the email account id's are stored.
 

jerrybell

Well-Known Member
Nov 27, 2006
90
0
156
So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry
 

panayot

Well-Known Member
Nov 18, 2004
126
0
166
Thank you Jerry! This worked pefectly for me :D

So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry
 

expertis

Member
May 9, 2007
6
0
151
Hi Jerry,

Thanks for the post, this fixed a problem I just experienced with one domain. I had to go in and set the permissions on 'shadow' to 640 and the users were then able to send out mail.

Does anyone know why this shadow files permissions would have changed? This domains users weren't having any problem sending or receiving until 2 days ago. From that point forward they could receive email, but not send email. It would stay in the Outlook outbox.

Thank you,

Spencer
 

mterrats

Registered
Aug 5, 2006
2
0
151
@Jerry: thanks for the tip, I had this issue after migrating some sites from Ensim X to cPanel.

I did a small/fancy/dirty php script that will do what Jerry said, copy/paste the code and execute it, it will walk through all your domains and check if those files have the right ownership and permissions. If you see some site is not ok you can do it manually or set the $debug variable in the script to false and let it fix it for you ;)

PHP:
#!/usr/bin/php -q
<?
// file: fix_auth_perms.php
// turn it off if you want to fix them
// based on http://forums.cpanel.net/showpost.php?p=323248&postcount=3
// more details http://xux.in/blog/post/cpanel-535-incorrect-authentication-data/
$debug = true;
 
$maps = file("/etc/domainusers");
if (!is_array($maps)) die("No users found!\n");
 
foreach ($maps as $map) {
  list($user,$domain) = explode(": ",trim($map));
  if (!$user || !$domain) continue;
  echo "\nChecking $domain ...\n";
  _file_fix("/home/$user/etc",$user,"mail");
  _file_fix("/home/$user/etc/$domain",$user,"mail");
  _file_fix("/home/$user/etc/$domain/shadow","","mail","0640");
  //exit;
}
 
// $file = full dir/file path
// $nuser = desired user name
// $ngroup = desired group name
// $perms = desired permissions in octal mode (0640)
function _file_fix($file="",$nuser="",$ngroup="",$perms="") {
  global $debug;
  $uname_array = posix_getpwuid(fileowner($file));
  $gname_array = posix_getgrgid(filegroup($file));
  $file_perms = substr(sprintf('%o', fileperms($file)), -4);
  echo "  $file owned by $uname_array[name].$gname_array[name] ($file_perms)\n";
    //wrong ownership, fixing it now!
  if (!$debug) {
    if ($nuser && $nuser != $uname_array[name]) {
      if (!chown($file, $uname_array[name])) echo "  couldn't change file owner to $nuser\n";
      else echo "  changed file owner to $nuser\n";
    }
    if ($ngroup && $ngroup != $gname_array[name]) {
      if (!chgrp($file, $gname_array[name])) echo "  couldn't change group owner to $ngroup\n";
      else echo "  changed group owner to $ngroup\n";
    }
  }
  if ($perms && $perms != $file_perms) {
    if (!$debug) {
      if (!chmod($file,octdec($perms))) echo "  couldn't change file mode to $perms\n";
      else echo "  changed file mode to $perms\n";
    }
  }
  //making a nice output :P
  if (!$nuser) $nuser = $uname_array[name];
  if (!$ngroup) $ngroup = $gname_array[name];
  if (!$perms) $perms = $file_perms;
  echo "  $file should now be owned by $nuser.$ngroup ($perms)\n";
}
 
?>
 

RACKSET

Active Member
Apr 28, 2006
44
0
156
localhost
So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry
Also make sure that files under /home/%user%/etc/%domain%/@pwcache be owned by the unix user, with a group of "mail".

That was the issue with one of our clients, and no one mentioned the solution. Hope this help others have the same issue.
 

PDW

Well-Known Member
Dec 29, 2003
121
0
166
I have this same error coming up for both Harde, Squirrell Mail and then RC doesnt show anything or work.

Ive checked the owner permissions, the folder and file permissions
backdated and updated cpanel. I did get SQM to work by going in and changing the sendmail $useSendmail = false; to $useSendmail = true; but stil lat a loss for everything else.