Cannot write file to GlobalSCAPE EFT Server Enterprise 6.4.1 in either FTPS 990 or SFTP 22

Question

I am configuring users that run a third party application that uses Rebex. I have been told that the Rebex version is 3.0.3723.0. So I assume that is the FTPS, I am waiting on confirmation of the SFTP version. Once I have that I will post. The issue is that most users can upload files without an issue. There are a few however that cannot, yet they can download data. I have tested with another FTP client and the account has the right permissions as I can write with it. Below is the error in the users log.

Failed - Error encountered - Error in Main() - Rebex.Net.SshException: Connection has been closed by the remote connection end; disconnected by application. .
   at Rebex.Net.SshSession.cqLugQ(Byte[] , Int32 , Int32 )
   at Rebex.Net.SshSession.AapcLiZ(Byte[] , Int32 , Int32 )
   at Rebex.Net.SshSession.cDtmAOZ(Int64& , Boolean )
   at Rebex.Net.SshChannel.cDtmAOZ(Boolean , Int64& )
   at Rebex.Net.SshChannel.Receive(Byte[] buffer, Int32 offset, Int32 count)
   at wWGvS.APnbEo.BXQTfX(Int32 )
   at wWGvS.APnbEo.CFLiXJ(BBdsJfZ& )
   at wWGvS.APnbEo.CFLiXJ(UInt32 )
   at wWGvS.APnbEo.AQJlLd(UInt32 )
   at Rebex.Net.Sftp.cqcMbi(AsNqWa , Object , String , Stream , Int64 , Int64 ) - cannot upload file 'My.File.Name'

Any ideas or suggestions?

Answer 1

The stack trace indicates that SFTP was actually in use (not FTP or FTPS) because its the only protocol supported by Rebex.Net.Sftp object. This means it's probably Rebex SFTP 2.0.3723.0 (please check Rebex.Net.Sftp.dll properties to make sure).

The error itself resembles a compatibility issue in ZLIB compression routine which we fixed in Rebex SFTP 2.0.3793.0. It caused the exact problem you describe with GlobalScape and BitVise servers.

The recommended solution would be to upgrade the third party application to use the latest vesion of Rebex SFTP (and FTP/FTPS). To make sure this solves the problem, try installing the current trial version - a part of the installation is a pre-compiled SftpWinFormClient sample which can be used to verify whether upload works.

Answer 2

Thanks for the quick response I will work with the developers of the 3rd party application. Do you know if the same ZLIB/Mode Z compression issues existed in the FTPS module version 3.0.3723.0? Any ideas as to why if only affects a few and most work fine? Also is there a way to make the log output verbose info in both FTPS and SFTP modules in those versions?

Comments

The error is only triggered by some files, so it's possible the others transfer a different kind of files. FTPS v3.0.3723.0 had the same bug in MODE Z, but this mode was not enabled by default. Both FTPS and SFTP module support verbose logging (see http://www.rebex.net/kb/logging.aspx - replacing LogLevel.Debug with LogLevel.Verbose produces a very verbose log), but in your case, it would have to be enabled using the third party application.

Answer 3

Thanks again. They all transfer the same file types just different sizes. Some are less than 100kb some are over 1mb. If can get them to disable Zlib/Mode Z then theoretically this should not happen? They will simply take longer to transfer. What is interesting is I found a user that can transfer from 1 IP but when his network uses another IP he can't. So I am wondering if that also comes into play somehow when negotiating the compression. The 3rd party did confirm the SFTP version they are using and it is what you stated. Also how would they disble Zlib/Mode Z? Any known issues with WS_FTP Server 6 and these versions of FTPS and SFTP?

Comments

Yes, disabling ZLIB/MODE Z was a recommended workaround. But I find it strange that an IP address would make a difference. Perhaps this was some other, unrelated issue? Particularly with SFTP, which uses a single TCP connection and ZLIB streams for the whole session, an IP address should make no difference at all. However, things can get more complicated with FTPS, which is a very firewall-unfriendly protocol... Again, I suggest downloading the SftpWinFormClient sample and giving it a try - if you can reproduce these issues with the latest version, just create a log and mail it to us!