An FTP connection must reach the server, negotiate the selected security mode, and authenticate before it can transfer files. FTP then needs a separate data connection. Start with the stage named by the client's error so connection failures, rejected credentials, and file-operation problems receive the right checks.

The Connection Times Out

Confirm the site hostname, security mode, and command port against the connection profile. If a corporate network blocks the standard port, test the alternate port for the same security mode. A client set to Implicit FTPS needs the Implicit port; changing only the port without matching the mode does not establish a compatible connection.

Check the network's hostname and address rules, including the source network used by the actual partner or integration. A successful workstation connection does not verify the path from a hosted system. Shared Cloud Environments explains the effect of shared or changing source addresses.

Certificate Warnings

FTPS uses the certificate configured for the site's web address, for both Implicit and Explicit connections. Use the configured hostname rather than an IP address, and confirm that DNS resolves it correctly. A hostname mismatch means the address used by the client does not match the name in the presented certificate.

Some clients display a first-connection prompt such as The server's certificate is unknown even for a trusted certificate. Inspect the displayed certificate and the expected hostname before recording trust in the client. A first-use prompt is different from a certificate reported as expired, self-signed, or invalid.

For certificate-chain or TLS negotiation failures, review the site's certificate configuration and TLS connection troubleshooting. Correct the certificate, DNS, or client compatibility problem rather than enabling plain FTP to bypass it.

Authentication Is Rejected

Check the credential actually used by the FTP client. A normal password login uses the user's username; an API-key login uses the key-specific login name described in Credentials. SSH keys cannot authenticate FTP. Accounts set to None have no password, and most browser SSO providers do not accept their browser credentials over FTP.

A disabled user cannot connect. Check the user's FTP protocol access and the applicable group grants. If the site manages protocol access through groups, an individual user's setting does not replace the required group membership.

For password sign-in, Require password change on next login blocks use of the original password until the change is completed through the web interface. FTP cannot display that password-change prompt. A browser login can help test a password or SSO sign-in when the account supports it and has web access; it does not test the API key used by an FTP connection. An account without browser sign-in has no equivalent web-login test.

For human accounts with 2FA, confirm that the client supports the selected 2FA method. Parallel connections can fail when an appended code reaches a different server or uses a different source address. FTP performance explains that interaction and the API-key option for unattended transfers.

Site Access Policies Block the Connection

An IP whitelist or country restriction can reject an otherwise valid connection. Check the public source address seen from the client network and the applicable site and user policies. A VPN can change both the apparent address and its detected country.

Files.com does not recommend these restrictions for most customers because they can block legitimate access. Country detection is approximate; use the controls when an explicit organizational requirement calls for them. Diagnose the rule that applies to the actual connection rather than treating valid credentials as proof that all access checks passed.

A successful login confirms the command connection, not the separate data connection. With Passive mode, verify that the client's network permits the full Files.com data-port range 40000–50000. Allowing only the command port does not permit file contents to pass. With Active mode, verify that the client's advertised data endpoint accepts the return connection from Files.com. Data Connections explains both paths.

Zero-Byte Files

A failed upload can leave an empty destination when the command connection requests the file but the data connection cannot deliver its contents. If failed transfers produce zero-byte files, check the data-channel firewall rules before changing file permissions or upload processing.

Folders or File Operations Are Unexpected

Check the user's actual folder permissions and FTP root and home settings. Those presentation settings do not grant access. A newly empty root may be a deleted path recreated at login, rather than the original folder restored with its contents.

If an upload targets a missing parent folder, check whether the client expects Files.com to create it. The site's automatic folder-creation setting determines that behavior and can also turn a misspelled path into a new folder.

An Upload Is Incomplete or Cannot Resume

Identify the client's temporary filename and completion behavior. Moving, renaming, or processing a partial file can prevent the client from resuming it. A scheduled delay does not prove the transfer completed. Partial Uploads explains the safe pickup pattern and the limits of filename exclusions.

If a completed file's contents changed during transfer, check ASCII and Binary transfer modes. ASCII conversion is appropriate only when plain text needs line-ending changes.

The Client Disconnects While Idle

Files.com closes sessions idle for more than 60 seconds. Configure the client's keepalive or reconnection behavior when it needs to remain available between commands. A slow transfer has different causes; Performance covers parallelism, latency, and regional routes.

Troubleshooting