"No such file" error when interacting with filenames containing special characters

• WinSCP version: 5.17.10 and latest beta
  
• Not an upgrade problem
  
• Windows 10 Enterprise LTSC
  
• SFTP
  
• Using GUI, Commander style
  
• Error message:
  

  No such file or directory.
  Error code: 2
  Error message from server (en-US): No such file

• Steps for reproduction: attempt to download, upload or interact with a file or folder with special characters through an SFTP connexion on Hetzner storagebox servers
  

WinSCP seems to not handle interactions with a file or folder containing special characters, such as accented characters or japanese characters. This happens on my server, a storagebox from Hetzner, to which I am willing to share restricted access with moderators if need be. Other types of servers don't seem to be affected.

While this looks a lot like a server misconfiguration problem from Hetzner's part, everything works fine on FileZilla and even the SFTP client I use on Android, so WinSCP must be doing something wrong.

Attached is the full log of the session with my username and IP redacted.

I have tried changing the UTF-8 encoding session parameters, reinstalling WinSCP, and using the beta version to no avail.

I have also noticed that I am not the first one to have this problem: SFTP file name problems with foreign characters
Although this topic never went anywhere, the user's hostname also ends in your-storagebox.de, so they probably also used a Hetzner storagebox. As asked of this user, I have also included a log with UTF-8 encoding turned off.

After digging a bit in Hetzner's documentation I found what I think is the cause of the bug, and a workaround so that I can keep using WinSCP.

Apparently Hetzner runs two SFTP servers on their boxes, one on port 22 which allows restricted SFTP and SCP file transfers (notably, no SSH access, so rsync is unusable), and one on port 23, which is disabled by default and allows for rsync, borg-backup and other utilities (despite no proper SSH shell being available). Enabling this secondary SFTP server and switching to port 23 on WinSCP seems to fix the problem. To anyone having this problem in the future, you also need to change the remote directory to /home in your connection settings.

While this means the problem is at least worked around for me, I am not closing this bug report, as it still appears WinSCP does not work properly on "restricted" SFTP access like Filezilla or other clients do. Weird.

Please enable logging on "Debug 2" level and post both logs again. Also post a verbose log file from FileZilla.

Can you also try to restrict SFTP version to "3" in session settings?
https://winscp.net/eng/docs/ui_login_sftp

Thank you for your quick answer.

Here are the logs. It seems that whether or not I specify SFTP version 3, my server negociates v4 - I've tried disabling fallback to no effect too.

Also, if you want to try things yourself I can make a temporary subaccount limited to a test directory and send the credentials to you.

A test account would be great. Please send details to my email address.

Mail sent, good luck.

Issue 2247 – Interoperability issues with servers that have broken implementation of newer SFTP versions