ERR: authdaemon: s_connect() failed: No such file or directory

Hi, this is the similar message that I've seen. I use fetchmail + maildrop + mutt + esmtp to retrieve my gmail via POP3

Running fetchmail --verbose gives me:

fetchmail: reading message <email address hidden>:23 of 258 (6274729 octets)
#********************ERR: authdaemon: s_connect() failed: No such file or directory
maildrop: Changing to /home/janhouse00

but I am still able to retrieve the message

Executing the following command would produce the same kind of error message, too.

authtest -s pop3 <email address hidden> "mygmailpaswd"
ERR: authdaemon: s_connect() failed: No such file or directory
Authentication FAILED: Illegal seek

Anyway, I personally think this would just be some kind of warning message and does not really cause a significant impact.

On Ubuntu 7.10 AMD64, I performed:
# strace authtest <email address hidden> "password"

It looks like there is a socket, '/var/run/courier/authdaemon/socket', it is attempting to access, which is not on the system. Specifically, '/var/run/courier/ does not exist. I've attached the output from 'strace'.

It seems that I don't have the package 'courier-authdaemon' installed, which is responsible for creating that socket. After installing 'courier-authdaemon', I no longer receive the error.

This is not a fetchmail bug, but happens inside maildrop, which tries to communicate with authdaemon. Please reassign to authdaemon or maildrop.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Still an issue on 8.10.

Installing courier-authdaemon does not fix it.

Thanks for the information.

Still an issue on 9.04. I have the same setup, fetchmail + maildrop, with courier-authlib installed (but authdaemon NOT running). I get my emails but in fetchmail.log I get:

ERR: authdaemon: s_connect() failed: No such file or directory

after every mail it downloads.

Hi there,
This is just to confirm that this is still happening in 9.04. It's purely maildrop issue, fetchmail has nothing to do with it. You can test it by calling:
maildrop -d <username>
It will issue the error message. Looks like maildrop was compiled to be a part of courier. As mentioned above Courier-authlib is installed, but not running.

Nevertheless the email is still delivered. So, it can be probably ignored or if it annoys you, change fetchmail to use procmail instead...

I'm running 10.04, and this bug (or one very closely related to it) is still a problem.

I have a user cron that runs a script to retrieve mail like so:
/usr/bin/fetchmail -a -s -m "/usr/bin/maildrop -d %T"

The maildrop binary is permissioned thusly:
-rwxr-sr-x 1 root mail 174168 2010-02-02 00:56 /usr/bin/maildrop

When fetchmail invokes maildrop this way, it does so as a non-superuser. Unfortunately, the authdaemon directory under /var/run/courier has these permissions:
drwxr-x--- 2 root root 100 2010-07-14 12:37 /var/run/courier/authdaemon/

This causes maildrop to complain that it can't connect to the authdaemon socket. This error message appears as an email from the local cron (or just on STDERR if I invoke the fetchmail script directly on the command line):
ERR: authdaemon: s_connect() failed: Permission denied

(Note: for some reason, my mail is still delivered, even though the above error message is shown.)

Yes. The message goes to stderr and maildrop tries to continue. In case authdaemon is not essential to message delivery, the message is harmless and maildrop succeeds. That is why its exit code indicates (definitively) that there was a failure. However, in cases where authdaemon *is* essential to message delivery, the message is a debugging aid that complements the exit code that indicates that there *was* a failure.

Admittedly, it might be nice if the stderr from the connect attempt could be buffered and printed out only upon an error exit. But the lack of this may be due to some technical constraint such as the library printing it rather than maildrop itself (haven't checked this time).

In the third sentence I obviously meant to say - that there was *no* failure.

I can also confirm this bug (Ubuntu 10.04 LTS with maildrop 2.2.0-3.1). I use getmail4 to fetch mails and try to deliver them using maildrop as an MDA. For each mail fetched, maildrop seems to be returning the following error:

  msg 1/1 (7036 bytes), delivery error (command maildrop 10858 error (67, ERR: authdaemon: s_connect() failed: No such file or directory
Invalid user specified.))
  Delivery error (command maildrop 10859 error (67, ERR: authdaemon: s_connect() failed: No such file or directory

The user which was specified with -d definitely exists, though. Nevertheless, the mail was not delivered. I was able to fix this bug for me by patching the package (--disable-authlib in debian/rules) and rebuilding it using debuild.

On Thu, Jul 29, 2010 at 08:57:34PM -0000, Simon Elsbrock wrote:
> For each mail fetched, maildrop seems to be returning the
> following error:
>
> msg 1/1 (7036 bytes), delivery error (command maildrop 10858 error (67, ERR: authdaemon: s_connect() failed: No such file or directory
> Invalid user specified.))
> Delivery error (command maildrop 10859 error (67, ERR: authdaemon: s_connect() failed: No such file or directory
>
> The user which was specified with -d definitely exists, though.
> Nevertheless, the mail was not delivered. I was able to fix this bug for
> me by patching the package (--disable-authlib in debian/rules) and
> rebuilding it using debuild.

This is not the same bug as reported in the original bug report.

You are actually getting the fatal error rather than just a warning.
Maildrop is returning an error status to fetchmail:

% grep 67 /usr/include/sysexits.h
#define EX_NOUSER 67 /* addressee unknown */

File a new bug and include more details regarding your actual configuration.

--
     2. That which causes joy or happiness.

I had the same problem on my system 10.04

After modifying the permissions on the /var/run/courier/authdaemon directory the error disappeared

chmod 755 /var/run/courier/authdaemon/

--- the error ---
Oct 27 15:02:24 servername postfix/pipe[10665]: B30227076F: to=<email address hidden>, relay=maildrop, delay=0.17, delays=0.08/0.01/0/0.07, dsn=5.1.1, status=bounced (user unknown. Command output: ERR: authdaemon: s_connect() failed: Permission denied Invalid user specified. )

The fix is easy:
- sudo aptitude purge maildrop
- download the maildrop tar.bz2 from http://www.courier-mta.org/download.php#maildrop
- follow the install instructions
  - sudo aptitude install libpcre3-dev
  - ./configure
  - ./make
  - ./make install-strip
  - ./make install-doc
- change .fetchmailrc to use /usr/local/bin/maildrop instead of /usr/bin/maildrop

There are two packages in the repositories; maildrop and courier-maildrop. maildrop has been (in my opinion erroneously) compiled with courier-auth support, and courier-authlib has been made a pre-req. That may well have needed to be done for courier-maildrop, but I don't think it should be done for standalone maildrop.

On Mon, Feb 07, 2011 at 12:56:54PM -0000, foolishchild wrote:
> The fix is easy:
> - sudo aptitude purge maildrop
> - download the maildrop tar.bz2 from http://www.courier-mta.org/download.php#maildrop
> - follow the install instructions
> - sudo aptitude install libpcre3-dev
> - ./configure
> - ./make
> - ./make install-strip
> - ./make install-doc
> - change .fetchmailrc to use /usr/local/bin/maildrop instead of /usr/bin/maildrop
>
> There are two packages in the repositories; maildrop and courier-
> maildrop. maildrop has been (in my opinion erroneously) compiled with
> courier-auth support, and courier-authlib has been made a pre-req. That
> may well have needed to be done for courier-maildrop, but I don't think
> it should be done for standalone maildrop.

*sigh* The fix would actually be to make your fetchmail stop annoying you
by interpreting all stderr output as an error. courier-auth support isn't
harming your delivery here, it's only making your delivery agent complain
for no apparent reason. Fix *that*.

--
     2. That which causes joy or happiness.

Re https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/102947/comments/17 the underlying problem is that /var/run/courier/authdaemon gets created with wrong permissions so that unprivileged agents cannot access the .../socket in that directory. Linking a duplicate bug here.

Note that this has been restated several times before, see comment #15. See https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/777060 for additional details. It might be advisable to make maildrop depend on courier-authdaemon.

Josip, note that it is NOT fetchmail BUT getmail that balks on stderr output.

On Wed, May 04, 2011 at 12:34:33PM -0000, Matthias Andree wrote:
> Note that this has been restated several times before, see comment #15.
> See https://bugs.launchpad.net/ubuntu/+source/courier-
> authlib/+bug/777060 for additional details. It might be advisable to
> make maildrop depend on courier-authdaemon.

That would just exacerbate the situation, because the use of authlib
(authdaemon) is not actually mandatory, maildrop has an -a option that
can make it so. In this same bug report we already saw a person say
courier-authlib support should be completely removed, rather.

I'm guessing some more patching of authlib to be silent would make this
middle-ground position more bearable...

--
     2. That which causes joy or happiness.

Please don't patch authlib - it's too silent already, and maildrop's "can't connect" is hard enough to find - namely non-existent if run from Postfix.

On Wed, May 04, 2011 at 01:42:34PM -0000, Matthias Andree wrote:
> Please don't patch authlib - it's too silent already, and maildrop's
> "can't connect" is hard enough to find - namely non-existent if run from
> Postfix.

maildrop has two straightforward modes - when you don't specify -a and when
you do. Each of these can and should be internally consistent. If you don't
want authlib to be silent - just use -a and make sure of that.

--
     2. That which causes joy or happiness.

The -a naturally cannot fix the bogus permissions of the /var/run
directory, as logged here:

May 4 16:56:28 hermes postfix/local[813]: 894EE47DFD: to=<ma...>,
orig_to=<ma...>, relay=local, delay=0.06, delays=0.01/0/0/0.05,
dsn=4.3.0, status=deferred (temporary failure. Command output: ERR:
authdaemon: s_connect() failed: Permission denied /usr/bin/maildrop:
Temporary authentication failure. )

Ouch. :-) [maildrop could also log in a bit more detail where
s_connect tried to connect to, namely the socket name, but that should
be filed as a separate bug and with the upstream]

On Wed, May 04, 2011 at 03:00:04PM -0000, Matthias Andree wrote:
> The -a naturally cannot fix the bogus permissions of the /var/run
> directory, as logged here:
>
> May 4 16:56:28 hermes postfix/local[813]: 894EE47DFD: to=<ma...>,
> orig_to=<ma...>, relay=local, delay=0.06, delays=0.01/0/0/0.05,
> dsn=4.3.0, status=deferred (temporary failure. Command output: ERR:
> authdaemon: s_connect() failed: Permission denied /usr/bin/maildrop:
> Temporary authentication failure. )
>
> Ouch. :-) [maildrop could also log in a bit more detail where
> s_connect tried to connect to, namely the socket name, but that should
> be filed as a separate bug and with the upstream]

That's all courier-authlib business, that's why I brought it up.
The authlib and/or the interaction with authlib should be either quiet
or screaming, and then things will be consistent from the get-go.

--
     2. That which causes joy or happiness.