It seems that I have encountered a problem with the FTP/SFTP node. Maybe I just need a hint how to find out more information.
I am connecting to his SFTP server. This connection works with the saved credentials (public/private key). A file is then uploaded using the FTP node. This also works. However, it seems that this connection remains open. Specifically, the node is displayed as successfully completed and the workflow would continue (if there were other nodes) but the SFTP connection remains open in the background. The SFTP server then closes this connection automatically after approx. 10 minutes.
If I try to establish a new connection during this time, either via the credentials or the FTP node, I always get this error message:
Remote host has reset the connection: read ECONNRESET
If I do it via Linux Terminal I get this message:
kex_exchange_identification: read: Connection reset by peer
My guess is that the FTP connection is not closed with a “bye, exit or quit” and therefore remains open.
If I send it in the terminal, I can establish a new connection immediately after the connection has been closed.
Hence the question: is it possible to display a log or send a manual bye/exit in the FTP as in the terminal? Or can I transfer a file (binary/CSV) to the SFTP server in a different way and send the exit?
Many thanks for your support.
Information on your n8n setup
- n8n version: 1.14.2
- Database (default: SQLite): SQLite
- n8n EXECUTIONS_PROCESS setting (default: own, main): own
- Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
- Operating system: Linux
Hi @seljo-ch, I am very sorry you’re having trouble.
I just tried reproducing this behaviour with the below workflow:
However, n8n seems to close the connection as expected here:
This was using the below docker-compose.yml setup:
Can you perhaps share an example workflow using which this problem can be reproduced? n8n itself does unfortunately not log any details about the SSH connection when using the FTP node (not even with
Thanks for your tries. Here the Workflow. Looks similar to yours. Nothing Special.
For the First run I get this:
And in the Second run immediatly this:
Do you need some more informations?
Which SFTP / SSH server are you connecting to?
It’s from a external Company. I have no Access to the Server it self. What Information do you need?
The software version would be handy, If you have SSH access you might be able to get that from the handshake as most servers output the version before hand. I know we have some issues with Windows OpenSSH services.
As soon I’m able to reconnect I’ll give you the output of the bash
Finally: Found that:
Getting the same, if I connect via SSH (which I can’t successfully due to no access) or via SFTP. Same Protocol is clear but we will use Only the access for File transfer.
That is perfect, So I have done some testing against some other SFTP servers and we do close the connection so it could be that there is something special with the IPWorks implementation that may be similar to the Windows Server version that we need to work around.
If I was to provide you with a special version of n8n that has some extra debugging in it next week would be you able to give it a run?
That sounds great. I can test it at any time!
If you can give me some Ideas/Hints to create a Workflow with a Workaround. Something like as long I get the Error, it will wait to process. As in the Productive Workflow the Trigger will be a WooCommerce Order, we need to have a look at this as well (means, Trigger get started, if the error pops up we wait for X Minutes and try it again). If another Trigger starts at the same time, it should wait as well.
Thanks a lot.
Just for information: I have created a workaround via my server, a bash script and a CronJob that now takes over the uploading. So the whole thing is not urgent. But it really is the case that the SFTP server is very tricky, if no correct BYE is sent, then the connection hangs until it times out.
Same problem here. Any solution yet?
Which SFTP server are you using? We have verified that we are sending a bye request and this seems to be working for most SFTP implementations.
I guess it is the same question, Which FTP server are you using? We also send a disconnect for FTP as well.
@Jon It’s from a provider. I can’t find more information about the FTP server. If you have a tip on how to find out more please let me know.
If you know how to find out more, here’s the server name: dd47614.kasserver.com
Normally if you use an FTP client it can be seen in the initial connection unless the version information has been hidden. I did a quick check and it doesn’t appear to show anything for me. I will do some more testing with differnet ftp servers and see if I can reproduce the same issue.
@Jon I’ve been using the FTP node with the same credentials for at least 1 year. I’ve updated n8n to the v1 about a week ago and since then I’m facing this problem.
@Jon I’ve created a new FTP user and successfully connected through FileZilla. A connection through n8n is still not possible.
Which version of n8n were you running before the update? What does your workflows execution look like as well are you working with multiple items or just one?