VM Recovery

Recover your Virtual Machine data now!

SFTP or SSH network connection errors


Contents




Failed to establish SFTP connection error code 103. - The semaphore cannot be set again

Our customers often write us that establishing remote connection to ESX server via SFTP results in following error:

Failed to establish SFTP connection error code 103. - The semaphore cannot be set again

We have investigated this issue and discovered that this problem may appear at the ESX 4.x versions that don't have SFTP support. This is a network error message, and normally it appears when a number of connections from one client exceed the predefined limit at the server, however ESX 4.x doesn't have proper SFTP support which is required to gain direct disk access via a network. If you see such error, you have following options:

  • close other programs that may have already established connections to ESX such as Putty or other SFTP client. Try to reconnect when resources are free.

  • upgrade your ESX to 5.0+ version to access it via SSH,

  • access VMFS disk(s) or drive images directly using some dedicated, stand alone, physical Windows PC.

Actually we recommend everyone to use the last option, it could require more effort, however, you will reduce recovery time a lot.

Please note: accessing VMFS via network protocols like SSH or SFTP severely reduce performance. Our test configuration achieves a scan speed of approx 340Gb per hour for local disk access for a single HDD. Compare it with 0.75Gb per hour via SFTP/SSH on a 1Gbit LAN connection.

FTP failed (Error: Connection lost due to error 10058)

10058 SSH connection error

In general, an error code 10058 occurs as the result of a socket previously shut down or partially closed. Once the socket is in this state, then it will not allow further data transmissions across the connection.
The common cause of this error to be an authentication failure. And this is a result of an incorrect password or username.

Please note: the SSH login allows ANSI characters only. Usage of different charsets, UTF8\UTF16 or Unicode is not allowed.

On the contrary some SSH and sFTP clients allow the password to be used non-Latin characters, different charsets, or UTF\Unicode. We have run a series of tests trying to use non-Latin characters in different SSH clients and received a following results:

  • Windows built-in SSH and sFTP clients - don't work with non ANSI characters
  • TotalCmd+SFTP(plugin) - doesn't work
  • Putty - works
  • FileZilla - works
  • VMFS Recovery™ - doesn't work

If you encountered this issue, please either create ANSI compatible credentials or use an alternative method to access VMFS datastore. I remind you, that SSH is still the slowest of them all.

If you would like to obtain more information about this problem you may be interested to check the following links: MS TechNet description, MSDN error codes, similar problem explained with VmWare Virtual Desktop Manager.




Return to contents