We upgraded all three of our Application Servers this weekend to Watch Directory 4.7.3. Previously were on 4.6.6.
Two of the servers are Windows 2003 server and one is Windows 2008 server.  We are getting this error on all 3 of our servers.

This error is coming from the Ftp Upload step in all these Watch Directory Tasks.  All of these tasks are multi-tasks.  The first sub-task is usually historical backup of the file and that runs just fine but the next sub-task is the ftp upload.  It initially can't connect but always connects on the 2nd try about a second later.

Just a snippet from one of the log files. Weird that it shows the connected output in the log in different spots for both of these files.

Well I guess I am going to attach the log file. You Forum site doesn't like a single word being all upper case so I can't paste in the log file. 

This has happened over 30 times today.  Doesn't matter what FTP site it is.  If the task has an ftp upload step we get the error every time.

I will have to redact some of the config file.  I realize the password is encrypted in there but I can't have anyone accessing client ftp sites or knowing what the server names and paths are.  So I will be editing the config file to put in dummy server names and paths and I will be blanking out the password field.

Hi,

Beta 2 should fix this issue:
http://www.watchdirectory.net/cgi-bin/yabb25/YaBB.pl?num=1394863717/1#1

The problem is that we can not reproduce the issue at all. It looks to me it is some kind of combination of FTP server and operating system.

Please disable the option "keep connection open as long as possible" and try the beta mentioned above.

mmmm, I now looked a little better at your log. Perhaps you are seeing something different. The issue Verne described was a memory access problem.
Please see section 2.4 on this page: http://sock-raw.org/papers/openssh_library
Specially this part:
OpenSSH tries to get that list of supported methods by sending a "none"
method request and then moving on to try the best available way to
authenticate..
That is exactly what we see in your log:

[30] Thu 20Mar14 15:01:50 - (001031) SSH2_MSG_USERAUTH_REQUEST: user: novo; service: ssh-connection; type: none
[31] Thu 20Mar14 15:01:50 - (001031) SSH2_MSG_USERAUTH_FAILURE: login failed
[30] Thu 20Mar14 15:01:50 - (001031) SSH2_MSG_USERAUTH_REQUEST: user: novo; service: ssh-connection; type: password

First an "attempt" with login type "none" (to list the connect types) and then trying the best available ("password" in this case). I will see if there is a way to skip the initial "none" connect and directly try to authenticate with a password.

Gert

It is not really possible to remove this "none" call, it is part of the normal sequence for logging in.
As the above is from your FTP server side logs, I am interested why you decided to look there. Perhaps you were affected by the same issue that Verne was and in that case the beta mentioned earlier will fix this.

Okay. So I loaded beta 3.  I no longer get errors in the WatchDirectory History Viewer and no longer get emails regarding the error.  However, I do see that the problem still exists according to the FTP logs.  As long as the uploads work and my Inbox is getting these error emails, I have no issue with this.

Thanks for your help.