Syncplify Help Center

Applies to: Syncplify.me Server!
Version(s): 4.x - 5.x
Warning:    this articles refers to an older version of our software

SSHFS is a FUSE-based filesystem client for the SSH File Transfer Protocol (SFTP); it’s very common among Linux users to mount SFTP targets as local directories. WebEx is a well-known teamwork collaboration tool by Cisco that uses SSHFS to back-up its data to a remote SFTP server.

Unfortunately, the coupling of SSHFS/WebEx – at the time this article is being written – has at least two problems that can cause serious issues to servers that implement the SFTP protocol and its extensions correctly.

Renaming to an existing file without setting the “overwrite” flag

This is what the current SFTP protocol RFC says about renaming:

begin
  if Session.CurURIStem = 'hello' then
  begin
    Session.SiteCmd.ReplyCode := 200;
    Session.SiteCmd.ReplyMsg := 'Hello there!';
    Session.AllowNextOperation := true;
  end
  else
    Session.AllowNextOperation := false;
end.

Unfortunately, SSHFS (at least in its WebEx implementation) tries to rename its temporary files to existing destinations without setting the required SSH_FXP_RENAME_OVERWRITE flag. Therefore Syncplify.me Server! correctly replies, as required by the SFTP protocol standard, with a SSH_FX_FILE_ALREADY_EXISTS response. This, of course, causes SSHFS to be unable to “save” files that are being edited/modified.

Renaming before closing the old file handle

This is a little bit more specific to the Windows operating system. Windows file systems do not allow rename operations on open files, unless they were open with the FILE_SHARE_DELETE flag, which, when the file is open for writing is usually not set.

Unfortunately, SSHFS (at least in its WebEx implementation) sends the SSH_FXP_RENAME command before sending the SSH_FXP_CLOSE command to close the file. So, basically,  SSHFS requests to rename an open file. If the file was open for writing and therefore wasn’t open with the FILE_SHARE_RENAME flag, the rename operation will invariably fail, once again causing SSHFS to be unable to save files that are being edited/modified.

The work-around

Syncplify.me Server! v4.0 (as of v4.0.19 and up) implements a work-around to address the misbehavior of SSHFS without breaking the SFTP protocol server-wise.

A new configuration flag has been introduced at the user level so that Syncplify.me Server! administrators can apply it only for certain specific user profiles. This flag instructs Syncplify.me Server! to assume that a particular user profile will be used by a WebEx/SSHFS client, and to consequently allow rename operation even when the destination file already exists and the SSH_FXP_RENAME_OVERWRITE was not specified in the client request. In addition to that, the rename operation also forcefully closes the file handle so that the underlying Windows file system can gracefully rename the file.

In our tests, we have also noticed that the way SSHFS handles reconnections (at least in its WebEx implementation) is occasionally unable to re-authenticate correctly. To prevent further problems, then, we also suggest Syncplify.me Server! administrators to set the “Session Timeout” to a value high enough to ensure that WebEx client sessions won’t ever be disconnected on the server-side.