Troubleshoot common FTP failures

Start with the symptom, then map it to a layer. Random setting changes hide the real fault and often create a new security problem.

I write the failing step number from the checklist in the ticket subject line. “Stuck at step 5” saves a round trip of questions.

No 220 greeting? DNS, routing, or the wrong port:

ftp files.partner.test
ftp: connect: Connection refused

530 on login? Bad credentials or account policy. Login OK but ls hangs? Data connection, almost always passive mode or a firewall.

Here is a data-layer failure I see often:

230 User logged in
ftp> epsv
229 Entering Extended Passive Mode (|||50021|)
ftp> ls
425 Can't open data connection

You reached the data steps in the checklist below and failed. Fix the passive port range before you touch usernames again.

Work from the outside inward:

1. Resolve the hostname and reach the configured TCP port.
2. Read the 220 greeting.
3. Complete TLS and validate identity when required.
4. Authenticate and reach 230.
5. Confirm PWD, transfer type, and features.
6. Negotiate a data endpoint.
7. Open the data connection.
8. Observe 150, bytes, and final 226.

A TLS error is not fixed by turning off certificate validation. Fix the hostname, chain, or clock.

550 after get usually means path or permissions:

ftp> get report.csv
550 Failed to open file
ftp> pwd
257 "/incoming/reports/2026" is the current directory

Run pwd and list the directory before you chmod anything world-writable.

Do not open every firewall port or disable TLS checks as a “quick test.” You will ship a hole and still not know what broke.

Take one verbose trace from a real failure. Write one sentence: the first failed layer, the exact reply code, and the next narrow test you will run.