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:
Files (and directories) can be renamed using the SSH_FXP_RENAME message.
string oldpath [UTF-8]
string newpath [UTF-8]
where 'request-id' is the request identifier, 'oldpath' is the name of
an existing file or directory, and 'newpath' is the new name for the file
'flags' is 0 or a combination of:
If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already
exists a file with the name specified by newpath, the server MUST respond
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.
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 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.