Connecting to the ftp server used to work on a previous version of n8n (can´t recall which one). I tried connecting yesterday and the node returned “end: read ECONNRESET“. I also tried testing the credentials to the ftp server and it stayed on a permanent testing loop.
The flow is just a test flow:
Hey @Modasa hope all is good. Welcome to the community.
ECONNRESET means the TCP connection was forcibly closed by the remote side (the FTP server) or by something in between (firewall, proxy, NAT timeout, etc.).
Would you like to share more?
Hey @jabbson,
The ftp server is hosted in Lima, Perú.
I used to be able to connect to it using its IP address, Port, Username and Password
We can connect to it via CMD’s telnet client and winscp with no issue:
While I am based in Perú, that connection was achieved by a friend in germany, where I understand the current n8n hosting service is.
Ok, so to summarize, you are using cloud n8n and have an ftp server hosted somewhere in Peru (actually when I asked where, I meant the service - like in GCP, AWS, Azure, own VPS etc). Do you have access to the logs of this ftp server? If so does it reveal any insights about the nature of the disconnects? Can you try to list the files with FTP node? Something as simple as this:
Does FTP service have any sort of access rules? Firewall?
We don´t use a service, we use our own VPS. The logs are as follows:
showing a reset in the end.
The disconnects do not allow me to save the credentials and when I try to list the folder contents from the root, it returns error: read ECONNRESET.
Well, this isn’t really the ftp log, it looks like a traffic capture. While it is cool to see, we already knew that the traffic is reset by the ftp server. FTP logs (if enabled and set to be verbose) would indicate the FTP application level events, like - user attempted to connect, then what went wrong (permissions, folders that do not exist, …) etc…
Or it could indicate that FTP doesn’t even receive the packet - for example if the packet if blocked by the system firewall - you could see it in the packet capture, but not in the ftp logs.
Now, this looks like a firewall log, if I had to guess - a Fortinet device. We can see the packet comes through from the WAN interface and undergoes DNAT (new destination is 10.100.9.15 and port is 2122). We also see that the action is server-rst, which means that the FTP server reset that connection.
All of that we already new (well except that now we are certain that the reset is not coming from the Forti firewall).
I still encourage you to connect to the actual FTP server and look at the FTP application level logs. If you wish to create a user for me to test - I could test here, otherwise all I can tell without seeing those logs is that the service is really listening on 191.98.154.86:2122 - I also see successful TCP connect to the ftp server from my laptop), but since I have no credentials I obviously cannot proceed with checking if the ftp itself is functioning properly.
I looked at the image again and see that the banner that you get when telnet-ing to the server is SSH. Are you sure FTP is running on this port and not SSH? Is this for SFTP?
Which protocol are you choosing?
To recap out internal chat with @Modasa (for future generations and anyone with similar problem).
I tested their server and indeed there was a problem. sftp from my linux machine was a success, sftp from n8n docker container was a success, ftp node (with sftp mode) was a fail. We looked at the firewall logs and at the server logs. I then ran it against my own server and it worked fine.
I looked up which package n8n uses for sftp and it is ssh2-sftp-client.
I created a simple client and tested a few versions of the package against @Modasa’s Windows server
const Client = require('ssh2-sftp-client');
async function main() {
const sftp = new Client();
try {
await sftp.connect({
host: '<ip address>',
port: <port>,
username: '<user>',
password: '<pass>',
});
console.log('Connected to SFTP server.');
const fileList = await sftp.list('/');
console.log('Files on server:', fileList);
} catch (err) {
console.error('SFTP error:', err.message);
} finally {
await sftp.end();
console.log('Connection closed.');
}
}
main();
The outcome: versions above 10.0.3 produce ECONNRESET after producing the output
$ node client.js
Connected to SFTP server.
Files on server: [
<LIST OF FILES>
]
.../node_modules/ssh2-sftp-client/src/utils.js:69
const newError = new Error(`${name}: ${err.message}`);
^
Error: end: read ECONNRESET
at Client.fn (.../node_modules/ssh2-sftp-client/src/utils.js:69:22)
at Client.emit (node:events:519:35)
at Socket.<anonymous> (.../node_modules/ssh2/lib/client.js:805:12)
at Socket.emit (node:events:507:28)
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
code: 'ECONNRESET'
}
Node.js v24.2.0
But 10.0.3 or below do not result in ECONNRESET:
$ node client.js
Connected to SFTP server.
Files on server: [
<LIST OF FILES>
]
Connection closed.
The version installed in a self-hosted n8n docker contailer:
const version = require('ssh2-sftp-client/package.json').version;
return [{json: {"v": version}}];
[
{
"v": "12.0.1"
}
]
Which is likely to be the reason why sftp against SSH server running on Windows is not working.