WinSCP Won't Load Data for Certain Directories

Hey, everyone!

Let's say I have a server with hostname myremotehost and a directory called /shared. /shared is an Amazon AWS Lustre directory mounted there at /shared.

Now, I can connect to myremotehost just fine with WinSCP. I can navigate to /shared and even /shared/directory, but it seems that some directories therein begin to cause WinSCP to timeout. This behavior has been persistent, and I don't know how to troubleshoot it. I can connect to myremotehost just fine with PuTTY and see all the files in the directory and all that, so I don't think it's an issue with the server or the directory itself.

Attached are some logs.

I appreciate any insight anyone is able to provide!

---

Edit
I was using an older version of WinSCP (6.1.1, I think) but I upgraded to the most recent (6.3.4) and I'm still seeing this behavior.

What protocol are you using to connect? Can you access those folders using any other client using the same protocol?

Please attach a full session log file showing the problem (using the latest version of WinSCP).

Thanks for much for the reply! I'm using SFTP protocol. Interestingly, it does look like similar behavior occurs when I use the sftp tool on the command line from another server. However, connecting to the server with SSH everything is fine. I'll admit to not being super familiar with the SFTP protocol – I'll be honest, I thought it was basically just SSH. If you have any insight as to why SFTP may be behaving differently than SFTP, I'd appreciate it.

Also, again, on the server this directory is a mounted Lustre share from Amazon AWS. I have a suspicion that that may have something to do with it, thought I'm not familiar with AWS to know the ins and outs of that either to know for sure whether that should affect SFTP.

As requested, I've included logs using the most up-to-date version of WinSCP.

SFTP and shell (not SSH) are very different interfaces to a remote server. While you rightly expect them to give you access to the same files, there might be subtle differences, as you see yourself.

I cannot tell why SFTP does not play well with Lustre (I've never heard about it).

But you can try to connect using "SCP protocol" in WinSCP, instead of SFTP. With SCP, WinSCP basically uses shell to work with the remote files.
https://winscp.net/eng/docs/scp

I actually had already tried using the SCP protocol instead of the SFTP, and I was seeing the same behavior. I tried again, since you suggested it, and this time I grabbed a log (attached). That actually I think clued me in a bit to what may be going on here.

You can see on line 244 of this log file that WinSCP, after changing directory to /shared/directory, tries to run the following command:
This caught my eye because I hadn't seen that switch for the ls command before, --full-time. So I SSHed into the server and tried to run that line myself, and indeed, it just hangs there. Not just ls -la --full-time, ls -la, ls -l, and ls --full-time all cause the shell to just hang there. Ctrl+C doesn't even get me out of it. (As a note, ls and ls -a both run fine in that directory).

So, my guess is it's something to do with the timestamps? For some reason the server can't find them or isn't grabbing them, and is just hanging there.

But please let me know if you have any other ideas or interpret what I'm seeing here any differently.

I would think that's a OS issue like with SSH itself on there, ls on there, or something else; or hardware issue like a file system problem.

I don't see how ls hanging is a WinSCP issue.

WinSCP can only do as well as what it's given. If it's given a problem it will also see a problem.

If you SSHed into it by not using WinSCP then the problem isn't here with WinSCP.

I don't know if that freeze will produce a system log entry somewhere (not a WinSCP log). It may very well though. That would probably be personally my next way to figure it out if I were dealing with it.

Hope it goes well for you.

@aarong: Indeed, it looks like the file system of the shared directory has some issues. Unfortunately, that's not my expertise.

@martin thanks! really appreciate you helping me look into this. it turned out it was an issue with the underlying file system.