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.
byte SSH_FXP_RENAME
uint32 request-id
string oldpath [UTF-8]
string newpath [UTF-8]
uint32 flags
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
or directory.
'flags' is 0 or a combination of:
SSH_FXF_RENAME_OVERWRITE 0x00000001
SSH_FXF_RENAME_ATOMIC 0x00000002
SSH_FXF_RENAME_NATIVE 0x00000004
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
with SSH_FX_FILE_ALREADY_EXISTS. 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 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.
