Topic "450 Could not perform action on file"

Author Message
paultp12

Guest


Hello:

For the past few days this error kept on occuring: "450 Could not perform action on file ..."

Nothing was changed in any of the processes. I had to re-run the task several times, and then it went ok.

Can anyone please shed some light. Thanks!

Paul
log-1-27-15.txt (5.8 KB) Private file

Description: (none)

Advertisements
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
I do not see any "Could not perform action on file" errors in the log.
_________________
Martin Prikryl
paultp12

Guest


prikryl wrote:
I do not see any "Could not perform action on file" errors in the log.


Hi Martin,

Sorry. But here is the file. This is for the failure today.

When I re-run, it works ok.

Thanks for your help.

Paul
Winscp-Log-1-29-15.txt (12.98 KB) [Download]

Description: (none)

Guest




paultp12 wrote:
prikryl wrote:
I do not see any "Could not perform action on file" errors in the log.


Hi Martin,

Sorry. But here is the file. This is for the failure today.

When I re-run, it works ok.

Thanks for your help.

Paul


One additional thing: There is also a "Timeout detected, connection failed" in the log. Thanks.
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
What happens is that WinSCP has not received confirmation from the server, when upload finished. This is actually quite common problem. So WinSCP reconnected to the server, verified that the file upload was indeed complete and tried to update a timestamp of the uploaded file. That failed, with 450 error. Likely because the FTP server has the file still locked from the previous attempt. Do you get the timeout with every upload? If you are, can you please try the upload with any other FTP client (FileZilla) to check if it is a client- or server-side problem.
_________________
Martin Prikryl
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
Actually, I take it back.
I did test against brickftp.com myself.
They just fail every MFMT request. It's on their side. Please report it.

Btw, now I assume that you see the error in the log only, correct?
I'm not getting any error in GUI.
_________________
Martin Prikryl
Guest




prikryl wrote:
Actually, I take it back.
I did test against brickftp.com myself.
They just fail every MFMT request. It's on their side. Please report it.

Btw, now I assume that you see the error in the log only, correct?
I'm not getting any error in GUI.


Thanks Martin.

I only see the error in the log only. Just so that I understand when I report it, what is an MFMT request?
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put
Guest




prikryl wrote:
It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put


I have let the FTP site know of this.

But, thanks for the suggestion to turn it off. I will consider to put it in the script. So in doing this, the 450 error (or the timeout detected) will not be there anymore? And btw, I did change the timeout to 45 secs.

Thanks for your help Martin.

Paul
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
It helps with the 450 error only, not with the timeout. Btw, I was not able to reproduce the timeout issue, from my side.
Guest




Anonymous wrote:
prikryl wrote:
It's a request to modify file timestamp. WinSCP does that to update the remote file to match that of source local file. Otherwise the file will have timestamp of the upload.

If you do not need that, you can turn this off using put -nopreservetime ...
See https://winscp.net/eng/docs/scriptcommand_put


I have let the FTP site know of this.

But, thanks for the suggestion to turn it off. I will consider to put it in the script. So in doing this, the 450 error (or the timeout detected) will not be there anymore? And btw, I did change the timeout to 45 secs.

Thanks for your help Martin.

Paul


Martin,

I have communicated and got response from our FTP provider. Here is what they are saying:

****
We have looked at your logfiles, and there appear to be 2 separate issues you brought up
• The MFMT requests failing. Our server does not honor file date/time modification requests. The reason is because of how our virtual filesystem is implemented. We update date/time stamps when a file is uploaded. So when you see this
> 2015-01-27 18:32:16.267 MFMT 20150127182335 ****.bak
< 2015-01-27 18:32:16.455 450 Could not perform action on file ****.bak.
That means that our server understood the MFMT request, but it is just not honoring it. That shouldn't pose a problem, and is unrelated to the timeouts.
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

***


Please let me know your thoughts.

Paul
martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
Quote:
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:
Quote:
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.
Guest




prikryl wrote:
Quote:
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:
Quote:
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.



Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul
WinscpLog-2-215.txt (14.45 KB) Private file

Description: (none)

Guest




Anonymous wrote:
prikryl wrote:
Quote:
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:
Quote:
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.



Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul



This is the response from the FTP server people for the log that I've attached:

***
Looking at this most recent log, the timeouts seem to happen at different phases of the process. i.e. it looks like it timed out during a transfer, then when it tried reconnecting, it could not even authenticate. Next time as soon as this occurs, can you try connecting to
http://test.brickftp.com and also http://www.speedtest.net

And see if it looks like you have lost internet connectivity at that particular point in time? Can you try to replicate the problem from a different physical network connection? Also I encourage you to try as many of the different Ports and Protocols as you can, from the troubleshooting document. For example I see you have PASV turned on, can you try it with that disabled? Can you try SFTP?

***
paultp2

Guest


Anonymous wrote:
Anonymous wrote:
prikryl wrote:
Quote:
• The general timeout issue you raised. I am going to attach our FTP connectivity troubleshooting guide. There is something in your logfile that definitely indicates a firewall issue:
2015-01-27 18:23:42.650 TLS connection established
2015-01-27 18:31:44.330 Timeout detected.
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed. The attached will give you some useful things to try.

We recommend that you try the following things in order and see if any of them resolve your issue.
1. Change active vs. passive mode. FTP clients and libraries have two modes of operation: Active mode and Passive mode. If the default doesn't work for you, try the other mode. As you try the other suggestions below, make sure to try each suggestion under both Active and Passive mode. Different firewalls work with different modes.
2. Try SSL. If you aren't using SSL, try switching to FTP-over-SSL on port 990 (implicit) or port 21 (explicit). In many cases, using SSL will get around any firewall blocking.
3. Try alternate ports. BrickFTP offers port 3021 as an alternate port for FTP. Often times, simply using port 3021 will allow your connection to work through your firewall.

Their analysis of the timeout issue is wrong.

Particularly this does not make any sense:
Quote:
This likely means after the initial handshake, the FTP client tried to open a new port for data transfer, and it failed.

The connection is obviously already opened. The TLS handshake occurs on the connection.
The timeout happended only 7 minutes (!) later, when the transfer completed and WinSCP timeouted waiting for the FTP server to acknowledge the transfer. So it's unlikely that any of his suggestion will make a difference (and you are using SSL/TLS already). It still can be a firewall (or router or proxy) issue though. If the firewall is stupid enough to close the FTP control connection due to an inactivity, during a long file transfer.



Thanks Martin. I have communicated this info to the ftp people.

I am attaching a log for today, as it failed todya with a similar but little different error. But, interestingly, in all of the timeouts, the file is eventually being ftped to the site -- Just my program is sending me error however (rightfully so). So the file is there in the ftp site. Is it because the Winscp is trying multiple times after the intial timeouts?

Thanks a lot for your help!

Paul



This is the response from the FTP server people for the log that I've attached:

***
Looking at this most recent log, the timeouts seem to happen at different phases of the process. i.e. it looks like it timed out during a transfer, then when it tried reconnecting, it could not even authenticate. Next time as soon as this occurs, can you try connecting to
http://test.brickftp.com and also http://www.speedtest.net

And see if it looks like you have lost internet connectivity at that particular point in time? Can you try to replicate the problem from a different physical network connection? Also I encourage you to try as many of the different Ports and Protocols as you can, from the troubleshooting document. For example I see you have PASV turned on, can you try it with that disabled? Can you try SFTP?

***


I have attached todays failure. As you can see there is that 10 min time gap where it detects a timeout. Interestingly, when I re-run the process, it executes fine. Thanks for your help.
FTP-Log-2-3-2015.txt (13.86 KB) Private file

Description: (none)

martin
[View user's profile]
Site Admin
Joined: 2002-12-10
Posts: 25015
Location: Prague, Czechia
There's nothing I can really help you with, atm. There's something with your/their network that breaks the connection.
Anyway, I have improved logging of WinSCP. What might help to understand the problem better.

Can you send me an email, so I can send you back a dev version of WinSCP to track the problem? Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

You will find my address (if you log in) in my forum profile.
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