Configure an FTP client deliberately

Vague client settings cause most of the FTP tickets I see. “FTP with encryption if available” still sends passwords in cleartext when the server allows it.

Write down exactly what you need before you click Save:

protocol: explicit FTPS
host: files.partner.test
port: 21
TLS: required
certificate validation: on
data mode: EPSV / passive
transfer type: binary

Then prove it from the command line:

curl --verbose --ssl-reqd --user "$FTP_USER" \
  ftp://files.partner.test/ -l

You should see AUTH TLS, PROT P, and 226 on a directory listing. If the GUI behaves differently, compare TLS mode, passive settings, and certificate handling line by line.

I screenshot the working curl trace and attach it to the client profile notes. That saves the next person from guessing which checkbox mattered. Notes beat memory every time.

Pick FTP, explicit FTPS, or SFTP before you touch host and port. SFTP wants SSH keys. FTPS wants a trusted TLS certificate. They are not the same form fields.

Use a narrow account rooted at the directory you need. Store passwords in a secret manager, not in the saved site name field visible to everyone on the laptop.

Retrying get into a temp file is safe. Retrying append, delete, or rename without checking remote state first is not.

If filenames use accents or non-ASCII characters, check whether your client sends OPTS UTF8 ON when the server advertises it. Mismatched encoding shows up as 550 on files that clearly exist when you ls.

Save the working profile as plain text in your runbook. When a partner rotates certificates or passive ports, you want the last known good settings in git.

Reproduce the GUI session with curl or the ftp client. Fix whichever step diverges.