0 votes
by (120 points)

Hi, I'm having issues accessing a folder on our SFTP server. This was working before and there have been no code changes. I'm currently getting the error 'No Such File; no Such Directory' below is the log text:

2020-06-17 16:00:30.938 Opening log file.
2020-06-17 16:00:30.939 INFO FileLogWriter(1)[13] Info: Assembly: Rebex.Common 2017 R6.3 for .NET 4.0-4.7
2020-06-17 16:00:30.960 INFO FileLogWriter(1)[13] Info: Platform: Windows 10.0.17763 32-bit; CLR: 4.0.30319.42000
2020-06-17 16:00:30.960 DEBUG FileLogWriter(1)[13] Info: Culture: en; Windows-1252
2020-06-17 16:00:30.960 INFO FileLogWriter(1)[13] Info: FIPS-only mode has been enabled
2020-06-17 16:00:30.960 INFO Sftp(1)[13] Command: SSH_FXP_REALPATH (5, '/IOC/ITF')
2020-06-17 16:00:30.962 INFO Sftp(1)[13] Response: SSH_FXP_NAME (5, 1 item)
2020-06-17 16:00:30.962 INFO Sftp(1)[13] Command: SSH_FXP_STAT (6, '/IOC/ITF')
2020-06-17 16:00:30.969 INFO Sftp(1)[13] Response: SSH_FXP_STATUS (6, 2, 'File not found: /IOC/ITF')
2020-06-17 16:00:30.970 ERROR Sftp(1)[13] Info: Rebex.Net.SftpException: No such file; No such directory.
   at Rebex.Net.Sftp.WR(String N, JJM M)
Applies to: Rebex SFTP

1 Answer

0 votes
by (144k points)
edited by

Does this error occur during ChangeDirectory method call?

If /IOC/ITF actually exists, that would mean the error is caused by a server-side bug in SSH_FXP_STAT command implementation. In that case, we recommend contacting the server vendor to have it fixed.

Alternatively, you might upgrade to Rebex SFTP 2020 R3 which has a workaround for servers with broken SSH_FXP_STAT command. The following code shows how to enable the workaround:

var client = new Sftp();
client.LogWriter = new ConsoleLogWriter(LogLevel.Debug);
client.Login("demo", "password");

// enable workaround for servers with broken SSH_FXP_STAT
client.Settings.​EnableBrokenDirectoryStatWorkaround = true;


If you give this a try, please let us know whether it solves the issue.

by (120 points)
Thanks for the quick response.... issue is resolved..... issue was caused by recent updates to the server causing some of the accounts access to change.
Hi Lukas - I'm coming across this same issue when trying to navigate a client-supplied SFTP server. When we use Rebex to connect to their SFTP server, I can see the directory in question when calling GetList(). I can also see and access the directory when connecting via FileZilla and WinSCP. When attempting to call ChangeDirectory("targetDirectory") though, we're receiving the "No such file; No such directory." error. Based on that, it seems like the broken SSH_FXP_STAT command is the issue, but since I'm not very familiar with setting up/configuring a server, is there something more specific I can tell the server vendor to look for to help them resolve the issue?
by (144k points)
A client-side log created with LogLevel.Debug (like in the code snippet above) that shows a successful GetList(path) call and a failed ChangeDirectory(path) call (both with the same path) should be sufficient to demonstrate to a vendor that there is an issue with SSH_FXP_STAT command.
Thank you, I didn't realize the example above had the logging in it, I should've looked closer. I just skimmed over it when I saw it was for the workaround. That did it for me though, thanks again for the quick answer!
One other thing that seems strange - when we connect via an SFTP client such as FileZilla or WinSCP, the directory is accessible. It only seems to have issues when we use Rebex to navigate to the directory. Could this still be an issue with the SSH_FXP_STAT command?
by (144k points)
We have investigated this many times with different servers, and server-side issues with SSH_FXP_STAT are indeed to blame. A log would hopefully make it possible to determine whether this is the case now as well.
As for FileZilla, WinSCP and other GUI-based clients, these don't actually use SSH_FXP_STAT command when browsing directories. Instead, they simply list a directory (using a sequence of SSH_FXP_OPENDIR/SSH_FXP_READDIR/SSH_FXP_CLOSE command) and display the result. And when you enter a subdirectory, they just list that again using the same sequence of commands with different path. There is no need for SSH_FXP_STAT there, which explains why a server-side bug in that command often gets unnoticed - it does not affect common SFTP clients. With Rebex SFTP, you can actually avoid using SSH_FXP_STAT command as well - just don't use ChangeDirectory and DirectoryExists, and rely on GetList to retrieve information about directory items. Methods such as GetInfo GetFileLength, GetFileDateTime and FileExists also use SSH_FXP_STAT, but it seems that server-side SSH_FXP_STAT issues often only affect directories, so these might be safe.
by (144k points)
Enabling ​EnableBrokenDirectoryStatWorkaround basically instructs Rebex SFTP to determine directory existence by trying to actually open/close the directory, without listing it, which corresponds to SSH_FXP_OPENDIR/SSH_FXP_CLOSE. This works with servers with broken SSH_FXP_STAT, so it can be used to make ChangeDirectory/DirectoryExcits work with them, but it implies a slight slowdown because opening directory for enumeration is a more complex operation that simply determining its attributes.