Inspect FTP with curl

curl shows the FTP control conversation while it handles data connections for you. I reach for it when I want proof of what the server actually answered, not what a GUI claims happened.

GUIs hide the passive port, the TLS upgrade, and the difference between 150 and 226. Verbose curl prints all of that to your terminal. That makes it my first tool when a partner says “FTP works from FileZilla but not from our script.”

Pipe verbose output to a file when you open a ticket. Redact passwords, keep the numeric replies. Partners respond faster when they see 425 vs a vague “timeout.” I attach the trace before I ask them to open a firewall port.

Download with TLS required:

curl --verbose --user "$FTP_USER" --ssl-reqd \
  ftp://files.partner.test/incoming/report.csv -o report.csv

--ssl-reqd refuses cleartext. curl prompts for the password when you omit it. For scripts, read the password from a secret store, not from shell history or a committed .env file in git.

Verbose output labels control traffic:

< 220 FTP server ready
> AUTH TLS
< 234 AUTH TLS successful
> EPSV
< 229 Entering Extended Passive Mode (|||50021|)
> RETR incoming/report.csv
< 150 Opening data connection
< 226 Transfer complete

Lines with > went to the server. Lines with < came back. If you never see AUTH TLS, you are not on FTPS even if the URL starts with ftp://.

Upload to a temp remote name:

curl --verbose --ssl-reqd --user "$FTP_USER" \
  --upload-file ./report.csv \
  ftp://files.partner.test/incoming/report.csv.part

Check the exit code and look for 226 before you rename the remote file with a second curl call or an ftp session.

Use --ftp-pasv on ordinary networks. --ftp-port forces active mode and needs a reachable client endpoint. Match the mode to the failure you see.

Run one download with --verbose, redact credentials, and annotate the greeting, TLS upgrade, passive port, 150, and 226.