Hello, I will try to be brief. When uploading files using Voyager, each file from within the folder being uploaded are shown as folders, instead of files, regardless of the file extension. The files (after being displayed as folders) are also placed outside the original folder during upload. It causes a large scroll in the remote window. Afterwards if I refresh or close the program and return they are in the correct folder. So all folders and files end up correct in the end.

I have reinstalled the program and tried different settings without luck. Maybe synchronization of the computer side folders will help but not sure.

Thanks for any pointers.

Good day

I've set up a Scheduler job to Move Down files from an FTP server to my local disk.

The files download fine but then the remote files are never deleted, I don't even see a failed DELE command in the log.

I've tried the following two remote paths:

• /
• /*

Both work for downloads, both don't delete the files.

Log Sample

[03] Sat 12Apr14 17:04:37 - Receiving: /folder/blah.avi -> C:\Users\Private\Downloads\blah.avi

[05] Sat 12Apr14 17:04:37 - PASV

[06] Sat 12Apr14 17:04:38 - 227 Entering passive mode (95,211,93,130,234,161).

[03] Sat 12Apr14 17:04:38 - Opening passive mode data connection to 95.211.93.130, port 60065.

[05] Sat 12Apr14 17:04:38 - RETR /folder/blah.avi

[06] Sat 12Apr14 17:04:38 - 125 Data connection already open. Transfer starting.

[06] Sat 12Apr14 17:22:55 - 226 Transfer complete.

[03] Sat 12Apr14 17:22:56 - Transferred 358 649 864 bytes. 201,12 KB/sec.

[05] Sat 12Apr14 17:22:56 - XCRC /folder2/blah2.avi"

[06] Sat 12Apr14 17:22:56 - 500 Command "XCRC" not understood.

[04] Sat 12Apr14 17:22:56 - XCRC command failed. The command may not be supported by this server.

[03] Sat 12Apr14 17:22:56 - XCRC command checking has been disabled for future transfers using this session.

[03] Sat 12Apr14 17:22:56 - Received 358 649 864 bytes.

[03] Sat 12Apr14 17:22:56 - Transfer time: 00:29:01.453.

Any help to fix this or workaround would be much appreciated.

Hi,

Got FTP-Voyager to work great in command mode using a batch file to initiate file sync to my server from industrial robots to back them up.  Was working great as far as doing the job closing out starting another instance and going to the next robot.

New problem.....

It no longer closes out at the end of the sync.  What option did I change that keeps FTP-Voyager from closing ?  I am using "autoquit=1" in the command line.

Thanks

Stan

We are trying to upgrade our FTP Voyager from 11.1 to 16.1.  I've been working through all the kinks, but have gotten stuck on running the 16.1 scheduler as a service and being able to access in house network shares (not remote ones).  The PC is Windows 7 Pro 64 bit.  I've done everything in KB article #1156 and the recommendations at the bottom in article #1679.  They both talk about setting the service to run as a network account that has access to the shared resources.  I've tried various domain admin accounts that I know have permissions to the shares and security permissions to the folders, but when I am editing or creating a schedule and try to setup an action, I am only given local drives to pick from when I click the browse button for the "Local File or Folder" field on the Action Properties page.  If I don't run the scheduler as a service, clicking the browse button gives me a list of local drives and all my mapped drives.  And I tried running the service with the same user id and password that the computer was logged in with when the scheduler was run in stand alone mode and showed me the mapped drives, but it still only showed me local drives when ran as a service.  I've tried all this with UAC on and off, with no change.  I don't know what to try next.  Please help.

I've had FTP Voyager and FTP Scheduler installed for many years.

On 11/2/2012 the scheduler stopped running nightly backups and now only generates errors when manually executing the jobs.

"Could not retrieve additional information about the local path. Please make sure the path exists and the local user has permissions".

This system has been setup for years and has not changed. The FTP Voyager can manually connect to the profile and I can download files from the server manually without problems.

The only major change to the system were recent FTP software upgrades and patches.

I've double checked the FTP Scheduler Profiles (which never changed passwords in the first place).

I've added a brand new FTP folder with new login password to the server which connects in FTP Voyager, but generates the same errors when manually executing a synch job in FTPV Scheduler.

And I've tried restarting the FTP Voyager Scheduler service and rebooting.

Also nothing has changed on the server and all the files and folders have full read/write access (and can be copied down manually from the FTP Voyager).

Its only when executing the job from within FTP Scheduler that it now fails with these messages and it started around 11/2/12.  But I can't recall on what dates I applied the FTP software patches and upgrades.

I succesfully logged into a server and saw the content available.

I selected what I wanted to download and chose Download.

Now the log shows

STATUS>    Connecting to "64.27.7.34" on port 21.

STATUS>    Connected to 64.27.7.34:21 from 192.168.1.78:60507.

ERROR>    The server has unexpectedly closed the connection.

and cycles this 8 more times.

I cannot now see the content on the server and if I close FT Voyager and restart it just goes thru'

STATUS>    Connecting to "64.27.7.34" on port 21.

STATUS>    Connected to 64.27.7.34:21 from 192.168.1.78:60507.

ERROR>    The server has unexpectedly closed the connection.

9 times again!

Any thoughts would be helpful.

Nigel

I have a connection set up to a server, all that is fine...

I can send smaller files just fine...

Larger files? It seems that the Command channel times out...

In the header of the Welcome message is a warning of a timeout at 3 minutes of inactivity...

So I dutifully setup a 150 second Keep Alive...

What I see in the log is...

The file (11GB+) sends fine...(Although there seems to be many reconnections during the transfer)

I will see an OPTS MLST command send

followed by a PWD and then a reconnection attempt...

Finally I will see a "Transfered <many> bytes STATUS message... Followed by an XCRC - which seems to receive no response after maybe 30 seconds...

Then another PWD...

Then an ERROR> Server has unexpectedly closed the connection...

And we start again....

Ideas?

Hello,

I'm having trouble with this configuration. . .

Windows Server 2008R2 + Voyager 16.0.2.0 + FTP over TLS (implicit) + PASV + connection to Serv-U v6.4

I get this error is in the log:

COMMAND> PASV

227 Entering Passive Mode (70,89,1xx,1xx,7,209)     <== Note, this is the Serv-U IP address.

"ERROR> The home directory specified for this account on the remote server is not accessible. Please contact your system administrator for further assistance."

Things I've tested. . .

This works great (home directory displays, but not for Serv-U):

Windows Server 2008R2 + Voyager 16.0.2.0 + SFTP + PASV + connection to non-Serv-U servers

. . .and this works (home directory displays on Serv-U but using an older version of Voyager + Win7 instead of 2008R2):

Windows7 + Voyager 16.0.1.1 + FTP over TLS (implicit) + PASV + connection to Serv-U v6.4

I'm not using the Scheduler "as service" to do this testing - just the Voyager UI. I'm thinking I should try loading 16.0.1.1 on the 2008R2 server but hesitate because I'm afraid it could screw up the Scheduler that is running other jobs.

Any one have similar experience?

Thanks.

Doug

I want to use FTP Voyager to upload data on a regular schedule from remote sites to my FTP server.  The application checks all of the boxes for what I need it to do: Upload all files in a folder, do some XCRC/XMD5/XSHA1, and then delete the local files after successful upload.  My problem is that the scheduled task seems to never complete sometimes and we stop receiving files.

The Internet connections for most of our locations frequently drop.  It seems this might have something to do with the problem.  My oldest installation has been running reliably since July and has a solid connection.  The scheduler hangs most frequently on sites with the worst connectivity issues.

I have implemented a klugey work-around by scheduling a task that restarts the Voyager scheduler service.  This keeps the problem from manifesting and we receive our files.

I set the following scheduler options:

• connection timeout = 90
• connection retries = 9
• connection delay = 3
• transfer send timeout = 90
• transfer idle timeout = 5
• file transfer upload file tries = 10

Scheduled task creation:

1. I create a scheduled task that runs every 15 minutes.
2. Add an action to run an external program.  This executes a batch file that moves files into a staging folder for the FTP transfer.
3. Add a second action to synchronize remote folders.  This moves the files up to our FTP server.
   1. I add an event to this action that runs a batch file after upload.  The batch file is there to delete the uploaded file and is passed, "$LocalPath", as an argument.

This setup works perfectly well in my lab and at the site with the consistent Internet connection.  Other locations have been seen to work for days and even weeks, but eventually the scheduled task hangs until the scheduler service is restarted.  Any help would be greatly appreciated.

I am getting this error only when connecting to a server with a profile under "scheduler site profile" (under tools), when using and identical profile under the regular "site profiles" (under browser) I don't get the error. It's very consistent when I try the scheduler site profile first and many times. Once I try the site in the regular profile and it connects I can then go back to the scheduler profile and it connects just fine. If I stop and start the scheduler service the error returns.

Any ideas? I've made sure both profiles are identical. I've also removed and re-created the scheduler profile. I don't get it. It's like a bug.

I've tried the re-connection and timeout values but they don't seem to help as it actually does connect but then immediately get's disconnected.

Some log below:

12] Thu 13Feb14 18:30:01 - (Task: CTABS Daily Upload) - Performing scheduled execution of task for Thursday, February 13, 2014 18:30:00.

[03] Thu 13Feb14 18:30:02 - Resolving host "eippftp.com"...

[03] Thu 13Feb14 18:30:02 - Connecting to "67.228.3.18" on port 22.

[03] Thu 13Feb14 18:30:02 - Connected to 67.228.3.18:22 from 10.4.60.160:17567.

[03] Thu 13Feb14 18:30:02 - Negotiating SSH2 session with server...

[03] Thu 13Feb14 18:30:02 - Client Identification: SSH-2.0-FTP Voyager_16.1.0.0

[04] Thu 13Feb14 18:30:02 - The server has unexpectedly closed the connection.

[12] Thu 13Feb14 18:30:02 - (Task: CTABS Daily Upload) - Execution failed (Last Error Message: ).

[12] Thu 13Feb14 18:30:02 - (Task: CTABS Daily Upload) - Next scheduled execution on Friday, February 14, 2014 18:30:00

Thanks all :-)

I am trying to download files from a third party site that uses SFTP SSH2 port 991

I can connect to the site fine, but when I download a file, All i get is a 0 byte file, and the error msg:

SSH_FXP_STATUS: status: SSH_FX_OP_UNSUPPORTED; description:  The requested file can not be read.  Maximum read size (32K) has been exceeded.

How can I easily migrate from version 15.2.0.19 to 16.1.0.0?  I've managed to import my site profiles into ftp voyager, however how do I import my scheduled tasks into scheduler?

Hello all,

Voyager has been chugging along for weeks now, with no issues. All of a sudden, the logging behaviour has changed, and I don't understand why. ALL scheduled jobs have logging set like this:

In the past, I would get 1 log file per day that contained all the logs of all the jobs that ran that day: 2014-07-11.txt, 2014-07-12.txt, and so on.

Then all of a sudden, the file 2014-07-14.txt was the last log file created. All the jobs are still being logged, but into the file of the 14th. Why did Voyager suddenly stop creating new log files? There were no updates to the software, the server, the OS, etc. I tried restarting the service, recreating a job, but no luck. Note: I realize the Automatically rotate Log Files is set to Never, but this has been the case from day 1 when it was working. The fact that my logfile name is a variable should force new files to be created. What am I missing?

Al

I use FTP voyager 16.1.0.0 on al Windows 8.1 PRO laptop.

My problem is: I cannot see the transfer queue. Any advice please ?

Hello all,

We've been long time owners/users of FTP Voyager v16.1 and need to start uploading files that contain a date in the filename, as well as adding the date to files after they are uploaded. I'm having a very hard time getting this to work, even after reading through the Knowledgebase. I want to accomplish the following:

upload 2104-06-13_file1.txt --> /uploads/2104-06-13_file1.txt
Note the date shown in the filename above will change day to day.

upload file2.txt --> /uploads/2104-06-13_file2.txt
Note the source file does not have a date, but the destination does. The date shown in the filename above will change day to day.


I have my Scheduler Profile set up as follows:

Note:

• scheduler profiles don't have the ability to specify a Local folder... so I have to specify the full path in the Scheduled Job Actions.
• Only one rename is specified since I'm not renaming file1

And my Scheduled Job Actions (with full path for local files) are:

The logs of the job show thi

[13] Mon 16Jun14 10:41:09 - (Action: "D:\%Y-%m-%d_file1.txt" to "/uploads/%Y-%m-%d_file1.txt") - Uploading from "D:\2014-06-16_file1.txt" to "/uploads/2014-06-16_file1.txt"

[05] Mon 16Jun14 10:41:09 - CWD /uploads/2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:09 - 550 Can't change directory to /uploads/2014-06-16_file1.txt: No such file or directory

[04] Mon 16Jun14 10:41:09 - Unable to change to folder "/uploads/2014-06-16_file1.txt".

[05] Mon 16Jun14 10:41:09 - CWD /uploads

[06] Mon 16Jun14 10:41:09 - 250 OK. Current directory is /uploads

[05] Mon 16Jun14 10:41:09 - MKD /uploads/2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:09 - 257 "/uploads/2014-06-16_file1.txt" : The directory was successfully created

[05] Mon 16Jun14 10:41:09 - CWD /uploads/2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:10 - 250 OK. Current directory is /uploads/2014-06-16_file1.txt

[05] Mon 16Jun14 10:41:10 - MLST /uploads/2014-06-16_file1.txt/2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:10 - 550 Can't check for file existence

[03] Mon 16Jun14 10:41:10 - Sending: D:\2014-06-16_file1.txt -> /uploads/2014-06-16_file1.txt/2014-06-16_file1.txt

[05] Mon 16Jun14 10:41:10 - TYPE I

[06] Mon 16Jun14 10:41:10 - 200 TYPE is now 8-bit binary

[05] Mon 16Jun14 10:41:10 - PASV

[06] Mon 16Jun14 10:41:10 - 227 Entering Passive Mode (67,210,123,189,131,40)

[03] Mon 16Jun14 10:41:10 - Opening passive mode data connection to 67.210.123.189, port 33576.

[03] Mon 16Jun14 10:41:10 - Negotiating SSL connection with server...

[05] Mon 16Jun14 10:41:10 - STOR 2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:10 - 150 Accepted data connection

[03] Mon 16Jun14 10:41:10 - SSL connection established. All transactions are now secure.

[03] Mon 16Jun14 10:41:10 - Encryption cipher: 128 bit RC4; Version: TLSv1/SSLv3.

[06] Mon 16Jun14 10:41:11 - 226-File successfully transferred

[06] Mon 16Jun14 10:41:11 - 226 0.758 seconds (measured here), 46.32 Kbytes per second

[03] Mon 16Jun14 10:41:11 - Transferred 35,959 bytes. 41.66 KB/sec.

[05] Mon 16Jun14 10:41:11 - XCRC "/uploads/2014-06-16_file1.txt/2014-06-16_file1.txt"

[06] Mon 16Jun14 10:41:11 - 500 Unknown command

[04] Mon 16Jun14 10:41:11 - XCRC command failed. The command may not be supported by this server.

[03] Mon 16Jun14 10:41:11 - XCRC command checking has been disabled for future transfers using this session.

[05] Mon 16Jun14 10:41:11 - MFMT 20140616070159 /uploads/2014-06-16_file1.txt/2014-06-16_file1.txt

[06] Mon 16Jun14 10:41:11 - 213 UTIME OK

[03] Mon 16Jun14 10:41:11 - Sent 35,959 bytes.

[03] Mon 16Jun14 10:41:11 - Transfer time: 00:00:00.843.s

[13] Mon 16Jun14 10:41:11 - (Action: "D:\%Y-%m-%d_file1.txt" to "/uploads/%Y-%m-%d_file1.txt") - Action successfully completed.

and

[13] Mon 16Jun14 10:41:11 - (Action: "D:\file2.txt" to "/uploads/%Y-%m-%d_file2.txt") - Uploading from "D:\file2.txt" to "/uploads/2014-06-16_file2.txt"

[05] Mon 16Jun14 10:41:11 - CWD /uploads/2014-06-16_file2.txt

[06] Mon 16Jun14 10:41:11 - 550 Can't change directory to /uploads/2014-06-16_file2.txt: No such file or directory

[04] Mon 16Jun14 10:41:11 - Unable to change to folder "/uploads/2014-06-16_file2.txt".

[05] Mon 16Jun14 10:41:11 - CWD /uploads

[06] Mon 16Jun14 10:41:11 - 250 OK. Current directory is /uploads

[05] Mon 16Jun14 10:41:11 - MKD /uploads/2014-06-16_file2.txt

[06] Mon 16Jun14 10:41:12 - 257 "/uploads/2014-06-16_file2.txt" : The directory was successfully created

[05] Mon 16Jun14 10:41:12 - CWD /uploads/2014-06-16_file2.txt

[06] Mon 16Jun14 10:41:12 - 250 OK. Current directory is /uploads/2014-06-16_file2.txt

[05] Mon 16Jun14 10:41:12 - MLST /uploads/2014-06-16_file2.txt/file2.txt

[06] Mon 16Jun14 10:41:12 - 550 Can't check for file existence

[03] Mon 16Jun14 10:41:12 - Sending: D:\file2.txt -> /uploads/2014-06-16_file2.txt/file2.txt

[05] Mon 16Jun14 10:41:12 - PASV

[06] Mon 16Jun14 10:41:12 - 227 Entering Passive Mode (67,210,123,189,154,238)

[03] Mon 16Jun14 10:41:12 - Opening passive mode data connection to 67.210.123.189, port 39662.

[03] Mon 16Jun14 10:41:12 - Negotiating SSL connection with server...

[05] Mon 16Jun14 10:41:12 - STOR file2.txt

[06] Mon 16Jun14 10:41:12 - 150 Accepted data connection

[03] Mon 16Jun14 10:41:12 - SSL connection established. All transactions are now secure.

[03] Mon 16Jun14 10:41:12 - Encryption cipher: 128 bit RC4; Version: TLSv1/SSLv3.

[06] Mon 16Jun14 10:41:12 - 226-File successfully transferred

[06] Mon 16Jun14 10:41:12 - 226 0.136 seconds (measured here), 59.89 Kbytes per second

[03] Mon 16Jun14 10:41:12 - Transferred 8,367 bytes. 27.60 KB/sec.

[05] Mon 16Jun14 10:41:12 - MFMT 20140616131743 /uploads/2014-06-16_file2.txt/file2.txt

[06] Mon 16Jun14 10:41:12 - 213 UTIME OK

[03] Mon 16Jun14 10:41:12 - Sent 8,367 bytes.

[03] Mon 16Jun14 10:41:12 - Transfer time: 00:00:00.296.

[13] Mon 16Jun14 10:41:12 - (Action: "D:\file2.txt" to "/uploads/%Y-%m-%d_file2.txt") - Action successfully completed.

In both cases, Voyager thinks the destination filename is a folder... and of course those folders don't exist. For some reason, Voyager creates those folders and then deposits the files in them. In the case of File2, the date does not even get appended to the filename.

Can anyone explain to me where I've gone wrong? Thanks.

Al

Hey Guys -

I do a lot of downloading over the internet via FTP - most of which are files 1gb - 8gb.  For a couple of years now, I've used SmartFTP due to it's feature of being able to set "Multi-Part Transfers.  Using this makes downloading much faster per file!  For example, when downloading a large file (1gb+) with default settings, it downloads at ~250kb/s  when above is set to 32, I go my max speed of 2.0mb/s.  If not familer, here's how the setting works:

- It applies to each download worker

- You may set the file size threshold for it to be used (I set mine to 1mb)

- You configure how many "Parts" (connections) you wish for it to use (between 1 - 32)

- It may be enabled or disabled globally or per favorite

I'm trying to find an alternative FTP client as SmartFTP has had issues recently, but cannot find one which offers this setting.  Does FTP Voyager?

I downloaded and installed FTP Voyager and started a download from the same site with default settings and 1 worker.  The download speed capped at about 270kb/s.

If you could tell me how to set this if available, I'd appreciate it very much!

Thank You!

Users transfer date to serv-U server with FTP Voyager.

User do also transfer data to some linux SFTP servers.

We used to have FTP Voyager 15.2.0.15 - everything worked fine.

Since updating to FTP Voyager 16.0.2.0 authentication
with linux SFTP servers fail (connection to Serv-U is still working) It seames that the password is not transferred to the server.

Whithout configuring user and password in server profile: I've been asked for a username - not for the password.

     Log: SSH_MSG_USERAUTH_FAILURE

     /var/log/messages:

Jul  5 07:59:21 chwiitsv042 sshd[29597]: Connection from 10.142.40.230 port 2087

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: Client protocol version 2.0; client software version FTP Voyager_16.0.2.0

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: no match: FTP Voyager_16.0.2.0

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: Enabling compatibility mode for protocol 2.0

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: Local version string SSH-2.0-OpenSSH_5.1

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: user zfs-sftp matched group list sftponly at line 143

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: PAM: initializing for "zfs-sftp"

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: PAM: setting PAM_RHOST to "10.142.40.230"

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: PAM: setting PAM_TTY to "ssh"

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: do_cleanup

Jul  5 07:59:21 chwiitsv042 sshd[29597]: debug1: PAM: cleanup

Anyone an idea what's wrong ?

Thank you very much

Christof

Hello SolarWinds and FTP Voyager developers. I got a feature request. I am testing some FTP programs and like FTP Voyager sofar. But I am missing support for SCP (Secure Copy Protocol). I got some servers and a router. They support SSH login via putty. If I try to connect via SSH with FTP Voyager (or any other FTP client) I get disconnected. I also tried WinSCP with SSH. It disconnects also. If I switch from SSH to SCP in WinSCP, I can connect fine and transfer files without problems. But I do not want to have 2 or more programs installed and WinSCP has less features than FTP Voyager. Therefore it would be nice if you could add support for SCP.

I'm trying to used the command line interface of FTP Voyager and the 'profile' switch is working to connect me to the correct site, but the 'put' is not.  The site opens and I don't see any attempt to upload the file.

Below is the generated command line:

D:\Program Files\RhinoSoft\FTP Voyager\FTP Voyager.exe profile=NOR1 put=T:\Cognos\Exports\NOR1\AFFSHB20140417.tab

Hello -

I'm a new user of FTP Voyager.

I'm uploading a large file, and I've been pausing and resuming the transfer in an effort to troubleshoot some connectivity issues.  I'm uploading to a web server over explicit FTP over SSL.

In doing so, I noticed that the count of "Transferred" data is being counted in correctly.

When I resume a transfer, the amount of data transferred should start from the size of the file currently on the target server.  Instead, it is adding the amount that was previously transferred to the size of the file on the target server.  Each time I pause and resume, the amount transferred jumps even higher.

The file I'm currently experimenting with is 429,386KB

The server currently has 327,839 KB of that file uploaded to it.

After several stops and restarts, the transfer queue says I now have transferred "937 MB of 419 MB" on that 1 file.

Another quick resume and pause, and now it says I have transferred "1,249 MB of 419 MB"

So that should be a pretty simple bug to fix.

----------------------

Separate but related issue:

I will also note that when I have the transfer paused and I refresh the target directory, I see the current file size of the target file -- the amount that has been transferred so far.

I resume the transfer, I see the transfer taking place in the transfer queue.  The file size in the target directory stays the same.  (Not a problem.)

When I pause the transfer, the target directory updates, and suddenly shows the file size as being very small -- I believe it's just the amount that was transferred in the most recent block between "resume" and "pause"

If I right click the target directory and choose "refresh", then the directory updates and once again shows the correct file size for the partially uploaded file.

So those are two bugs that should be investigated.

Thanks

James Grove