Topic "upload to NetApp sftp server fails-cannot close remote file"

Author Message
MNielson
[View user's profile]

Joined: 2013-03-22
Posts: 3
Using WinSCP 5.1.4 to access SFTP server hosted on a NetApp vfiler. Authentication is fine, downloads are also fine. Upload of very small file is also fine. However, upload of file that contains more than 409 bytes results in this error when closing remote file:

No such file or directory.
Error code: 2
Error message from server: No such file
Request code: 4

Data on remote side appears to be intact in spite of ugly error message. However, if large enough to be transferred in chunks then "*.filepart" remote file is not renamed.

Though the error message is different, my situation appears very similar to this: http://winscp.net/forum/viewtopic.php?t=8197

WinSCP log file for failed run:

. 2013-03-22 14:45:00.983 Copying 1 files/directories to remote directory "/vol/engr_ddrepo01/sftp/Misc/"
. 2013-03-22 14:45:00.983 PrTime: Yes; PrRO: No; Rght: rw-r--r--; PrR: No (Yes); FnCs: N; RIC: 0100; Resume: S (102400); CalcS: Yes; Mask: *.*
. 2013-03-22 14:45:00.983 TM: M; ClAr: No; CPS: 0; InclM:
. 2013-03-22 14:45:00.983 AscM: *.*html; *.htm; *.txt; *.php; *.php3; *.cgi; *.c; *.cpp; *.h; *.pas; *.bas; *.tex; *.pl; *.js; .htaccess; *.xtml; *.css; *.cfg; *.ini; *.sh; *.xml
. 2013-03-22 14:45:00.983 File: "C:\Junk\410b.txt"
. 2013-03-22 14:45:00.987 Copying "C:\Junk\410b.txt" to remote directory started.
. 2013-03-22 14:45:00.988 Ascii transfer mode selected.
. 2013-03-22 14:45:00.989 Opening remote file.
> 2013-03-22 14:45:00.989 Type: SSH_FXP_OPEN, Size: 62, Number: 18179
< 2013-03-22 14:45:00.989 Type: SSH_FXP_STATUS, Size: 24, Number: 17924
. 2013-03-22 14:45:00.989 Discarding reserved response
< 2013-03-22 14:45:00.990 Type: SSH_FXP_HANDLE, Size: 13, Number: 18179
> 2013-03-22 14:45:00.991 Type: SSH_FXP_WRITE, Size: 435, Number: 18694
> 2013-03-22 14:45:00.991 Type: SSH_FXP_CLOSE, Size: 13, Number: 18948
> 2013-03-22 14:45:00.991 Type: SSH_FXP_SETSTAT, Size: 58, Number: 18441
< 2013-03-22 14:45:01.088 Type: SSH_FXP_STATUS, Size: 24, Number: 18694
< 2013-03-22 14:45:01.088 Type: SSH_FXP_STATUS, Size: 29, Number: 18948
< 2013-03-22 14:45:01.088 Status code: 2, Message: 18948, Server: No such file, Language:
* 2013-03-22 14:45:01.088 (ETerminal) No such file or directory.
* 2013-03-22 14:45:01.088 Error code: 2
* 2013-03-22 14:45:01.088 Error message from server: No such file
* 2013-03-22 14:45:01.088 Request code: 4
. 2013-03-22 14:45:01.089 Asking user:
. 2013-03-22 14:45:01.089 Cannot close remote file '410b.txt'. ("No such file or directory.
. 2013-03-22 14:45:01.089 Error code: 2
. 2013-03-22 14:45:01.089 Error message from server: No such file
. 2013-03-22 14:45:01.089 Request code: 4")
* 2013-03-22 14:45:04.251 (EScpSkipFile) Cannot close remote file '410b.txt'.
* 2013-03-22 14:45:04.251 No such file or directory.
* 2013-03-22 14:45:04.251 Error code: 2
* 2013-03-22 14:45:04.252 Error message from server: No such file
* 2013-03-22 14:45:04.252 Request code: 4
. 2013-03-22 14:45:04.255 Listing directory "/vol/engr_ddrepo01/sftp/Misc".
> 2013-03-22 14:45:04.255 Type: SSH_FXP_OPENDIR, Size: 37, Number: 19211
< 2013-03-22 14:45:04.256 Type: SSH_FXP_STATUS, Size: 24, Number: 18441
. 2013-03-22 14:45:04.256 Discarding reserved response
< 2013-03-22 14:45:04.257 Type: SSH_FXP_HANDLE, Size: 13, Number: 19211
> 2013-03-22 14:45:04.257 Type: SSH_FXP_READDIR, Size: 13, Number: 19468
< 2013-03-22 14:45:04.261 Type: SSH_FXP_NAME, Size: 687, Number: 19468
> 2013-03-22 14:45:04.261 Type: SSH_FXP_READDIR, Size: 13, Number: 19724
< 2013-03-22 14:45:04.262 Type: SSH_FXP_STATUS, Size: 28, Number: 19724
< 2013-03-22 14:45:04.262 Status code: 1
> 2013-03-22 14:45:04.262 Type: SSH_FXP_CLOSE, Size: 13, Number: 19972
Advertisements
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 24530
Location: Prague, Czechia
This does not look like a problem of WinSCP. Please contact the server vendor first.
_________________
Martin Prikryl
MNielson
[View user's profile]

Joined: 2013-03-22
Posts: 3
prikryl wrote:
This does not look like a problem of WinSCP. Please contact the server vendor first.


Well I have in fact engaged NetApp level 2 support. They have pointed me back at you Sad

Actually, I tend to agree with you that the problem is likely to be on the server side but it's been very difficult to debug. I have demonstrated the problem on three separate NetApp instances here within my own organization. In addition, NetApp was able to reproduce the problem on a variety of NetApp server and WinSCP client version combinations. So at least we have established that the issue is not unique to my specific server instance. Frankly, I believe this problem has existed for years but nobody has pursued it until now.

Any suggestions on how we might go about debugging this problem? Packet traces are useless since SFTP traffic is encrypted. Is there a way to get more detailed logging from WinSCP without building a debug executable?
MNielson
[View user's profile]

Joined: 2013-03-22
Posts: 3
Martin,

NetApp support has provided detailed information strongly suggesting the problem to be on the client side. Basically, the client is closing the file before the server acknowledges completion of the write request based on timestamps found in the WinSCP logs. I have PM'd the full details to you.

-Mike
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 24530
Location: Prague, Czechia
I belive SFTP specification in section 4.1 (Request Synchronization and Reordering) specificaly requires server to allow this behaviour.
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-4.1

Quote:
The protocol and implementations MUST process requests relating to the same file in the order in which they are received. In other words, if an application submits multiple requests to the server, the results in the responses will be the same as if it had sent the requests one at a time and waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same file in parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on the server for processing requests from two different file transfer connections. The server may interleave and parallelize them at will.


The above is reference to the latest version of the specification, but the section dates to the very first version of the specification back in January 2001:
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-00#section-6.1
informatica@cog.es
[View user's profile]

Joined: 2013-08-12
Posts: 3
Location: Corunna, Spain
MNielson wrote:
Martin,

NetApp support has provided detailed information strongly suggesting the problem to be on the client side. Basically, the client is closing the file before the server acknowledges completion of the write request based on timestamps found in the WinSCP logs. I have PM'd the full details to you.

-Mike


I'm also experiencing this problem. Please, could you explain how you finally managed this issue?

Thank you.

PD: sorry about reopening an old conversation.
informatica@cog.es
[View user's profile]

Joined: 2013-08-12
Posts: 3
Location: Corunna, Spain
prikryl wrote:
I belive SFTP specification in section 4.1 (Request Synchronization and Reordering) specificaly requires server to allow this behaviour.
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-4.1

Quote:
The protocol and implementations MUST process requests relating to the same file in the order in which they are received. In other words, if an application submits multiple requests to the server, the results in the responses will be the same as if it had sent the requests one at a time and waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same file in parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on the server for processing requests from two different file transfer connections. The server may interleave and parallelize them at will.


The above is reference to the latest version of the specification, but the section dates to the very first version of the specification back in January 2001:
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-00#section-6.1


I understand the server should queue the close request, and process it after the write operation ends. However, are there any preference options that allow to change this behaviour in WinSCP? Something like "serialize requests to server"...
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 24530
Location: Prague, Czechia
informatica@cog.es wrote:
I understand the server should queue the close request, and process it after the write operation ends. However, are there any preference options that allow to change this behaviour in WinSCP? Something like "serialize requests to server"...

No, there no preferences option for this, nor any workaround. Please push your server vendor to fix the server.
_________________
Martin Prikryl
informatica@cog.es
[View user's profile]

Joined: 2013-08-12
Posts: 3
Location: Corunna, Spain
OK, Martin. Thank you for your prompt answer. I'll try to contact my vendor.

However, I was hoping that MNielson could tell us how NetApp level 2 support reacted to your reference to SFTP specification.
Advertisements

You can post new topics in this forum






Search Site

What is WinSCP?

It is award-winning SFTP client, SCP client, FTPS client and FTP client integrated into one software program for file transfer to FTP server or secure SFTP server. [More]

And it's free!

Donate

About donations

$9   $19   $49   $99

About donations

Recommend

WinSCP Privacy Policy

WinSCP License