Diagnose and fix the most common FTP errors, connection failures, authentication issues, and permission problems that stop file transfers in their tracks. From error 530 to passive mode mysteries, this guide gives you clear, actionable solutions for every scenario.
Before you can fix an FTP problem, you need to speak the language the server speaks. Every response from an FTP server begins with a three-digit numeric code that tells you exactly what happened, and learning to read these codes transforms troubleshooting from guesswork into a methodical investigation. The FTP protocol groups responses into five categories based on the first digit, and the second and third digits refine the meaning further.
Codes beginning with 1xx are positive preliminary replies, meaning the server has started an action but has not yet completed it. These appear during data transfers when the server acknowledges your request before the file actually moves. Codes starting with 2xx are positive completion replies, indicating a command finished successfully. You see 220 when you first connect, 230 after a successful login, and 226 when a transfer completes cleanly.
The 3xx family represents positive intermediate replies, meaning the server accepted part of your request but needs more information. The classic example is 331, which the server returns after receiving your username to prompt you for your password. Codes in the 4xx range are transient negative replies — temporary problems that may resolve themselves if you retry. A 421 code, for example, often means the server is overloaded and might work in a minute. Finally, 5xx codes are permanent negative replies that will not succeed on retry without changing something about your request, your credentials, or the server configuration.
Connected to ftp.example.com. 220 ProFTPD Server (Welcome) USER alice 331 Password required for alice PASS ******** 230 User alice logged in SYST 215 UNIX Type: L8
The second digit of each code adds detail: x0z signals syntax, x1z information, x2z connections, x3z authentication, x4z is unspecified, and x5z file system issues. Knowing this breakdown lets you narrow a problem to a category instantly — a 530 is authentication (5xx permanent, x3x auth), while a 550 is file system (5xx permanent, x5x files). Keep this mental model handy as you work through the remaining steps.
Error 530 is the single most common FTP error reported by beginners, and it means the server rejected the credentials you supplied. The literal text often reads 530 Login incorrect or 530 User cannot log in, but the underlying causes are varied enough that you need to work through a checklist rather than assume the password is wrong. Start by confirming the obvious: that you typed the username and password exactly as the hosting provider or administrator issued them, with correct capitalization and no stray whitespace copied from an email.
If the credentials look right, consider that FTP usernames on shared hosting are frequently a combination of a prefix and the account name, such as user_sitename or [email protected]. Hosting dashboards usually display the exact FTP username to use — do not assume it matches your control-panel login. Next, verify the account is enabled. Suspended accounts, trial expirations, and accounts flagged for abuse all return 530 even when the password is technically correct.
Many servers also enforce IP allowlists or geographic restrictions. If you recently changed networks, started working from a VPN, or traveled abroad, your current public IP may not be on the permitted list. Check your public IP with curl ifconfig.me and compare against the allowlist in your hosting control panel. Some providers add IPs on request; others require a self-service dashboard update.
# Confirm what the server actually sees curl ifconfig.me # Test credentials directly against the server curl -v --user "alice:secret" ftp://ftp.example.com/ # Look for 530 vs 230 in the output
Another frequent culprit is TLS enforcement. Some servers refuse plain-FTP logins and require FTPS; the authentication fails before the password is even checked. The response may still read 530 even though the real problem is the missing AUTH TLS command. Enable Explicit FTP over TLS in your client and retry. Finally, check the server configuration file /etc/vsftpd.conf or /etc/proftpd/proftpd.conf for directives like denied_users, userlist_deny=YES, or DefaultRoot that can silently block valid accounts.
Error 421 is a transient negative reply that signals the server is unwilling or unable to accept your connection right now. The most common wording is 421 Too many connections from this IP or 421 Service not available, closing control connection. Unlike 530, which points at your credentials, 421 points at concurrency and server load. The fix almost always involves closing unused sessions, lowering parallelism in your client, or waiting for the server to recover.
Modern FTP clients open multiple parallel connections to speed up transfers of many small files. FileZilla, for example, defaults to two simultaneous transfers but can be configured for up to ten. Each transfer uses its own data channel and, in some clients, its own control channel. A directory with hundreds of small assets can quickly saturate the per-IP limit most servers impose. Open your client's site manager and lower the Maximum number of connections setting to 1 or 2 for troublesome servers.
On the server side, administrators of vsftpd configure concurrency with max_clients and max_per_ip. ProFTPD uses MaxClients, MaxClientsPerHost, and MaxClientsPerUser directives. Pure-FTPd uses -c and -C command-line flags. If you administer the server and legitimate users keep hitting 421, raise these numbers carefully — ten is usually safe for a small team, but raising them too high invites denial-of-service abuse.
# Allow more parallel sessions when legitimate max_clients=50 max_per_ip=8 # Idle timeout in seconds idle_session_timeout=600 data_connection_timeout=120
Idle sessions that your client failed to close cleanly also count against the limit. If a previous transfer crashed, the server might still consider those sockets active until its idle timeout expires. Wait a few minutes, then retry. For scripted workflows, always close FTP connections explicitly in a finally block or try/finally wrapper so a crash does not leak sockets. Finally, 421 can occasionally mean the entire server process is restarting or hitting resource limits like file descriptors — check /var/log/vsftpd.log or /var/log/proftpd/proftpd.log for clues.
Error 550 is the FTP file-system catch-all. Its wording varies — 550 Failed to open file, 550 Permission denied, 550 No such file or directory, 550 Directory not empty, or 550 Quota exceeded — but every variant means the server could not perform the file operation you requested. The exact fix depends on which variant you see, so always capture the full error text instead of just the number.
The most frequent cause is a wrong path. FTP paths are case-sensitive on Linux servers even when they appear case-insensitive on Windows. Attempting to cd Public_html when the real directory is public_html returns 550 instantly. Use the pwd command to confirm your current directory, then ls -la to see exact names. Absolute paths starting with / are safer than relative paths because they do not depend on where the previous command left you.
Permissions are the second big category. Each file and directory on Unix-style servers has read, write, and execute bits for owner, group, and others. If your FTP account does not own the file and is not in its group, the other permissions apply. Upload the file to a directory where you have write permission, then move it, or ask the administrator to chown the target to your account. Directories need the execute bit to be entered, not just the read bit.
# Check permissions and ownership ls -la /home/alice/public_html # Make a directory writable by owner only chmod 755 /home/alice/public_html # Fix ownership on a stray file chown alice:alice /home/alice/public_html/index.html
Disk-quota exhaustion also triggers 550 when uploading. The connection succeeds, the file transfer begins, and then dies partway through with 550 Quota exceeded. Run df -h on the server or check your hosting control panel's usage report. Clean up old backups, logs, and cached files before resuming. On servers with per-user quotas enforced by quota, you can see your limits with quota -s.
/ actually means the user's home directory. Paths like /var/www fail with 550 because they do not exist inside the jail. Try /public_html or /htdocs instead.Finally, 550 appears when deleting a non-empty directory with RMD or renaming a file into an existing path. Delete contents first, or choose a different target name. For stubborn locked files, an SSH session with lsof or fuser can reveal which process still holds the file open.
A connection timeout is often the first FTP problem new users meet, and it is the most frustrating because the error message rarely tells you what actually went wrong. The client simply waits, counts down a timer, and reports Connection timed out or Could not connect to server. Behind the scenes, the TCP handshake never completed, meaning either the packets never reached the server, the server never answered, or a firewall silently dropped the response.
Start by verifying the hostname resolves. Run nslookup ftp.example.com or dig ftp.example.com. If resolution fails, DNS is the problem — check your DNS servers, try a public resolver like 1.1.1.1 or 8.8.8.8, and confirm the hostname is spelled correctly. If resolution succeeds but the IP looks wrong (an old server, a parked-domain placeholder, or your own router), the DNS record may be stale. Flush local DNS caches with ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS.
With DNS confirmed, test port 21 reachability using telnet ftp.example.com 21 or nc -zv ftp.example.com 21. A successful connection shows a 220 banner immediately. Silence or a refused connection points at firewalls. Corporate networks, hotel Wi-Fi, and some ISPs block outbound port 21 by default because plain FTP is considered insecure. If the test fails from your network but succeeds from a mobile hotspot, the local firewall is the culprit.
# DNS check dig +short ftp.example.com # Port reachability check nc -zv ftp.example.com 21 # Full connection trace curl -v --connect-timeout 10 ftp://ftp.example.com/ # Trace the route to see where packets stop traceroute ftp.example.com
If the server listens on a non-standard port — some providers use 2121, 2222, or 990 for FTPS implicit — your client defaulting to 21 will time out. Check documentation and update the port in your site profile. Server-side firewalls like ufw, firewalld, or AWS security groups must explicitly permit inbound traffic on the FTP port. Verify with sudo ufw status or by reviewing the cloud console's security-group rules.
Finally, if intermittent timeouts strike mid-transfer rather than at connection time, you may be hitting an idle-session timeout. Enable TCP keepalive in your client (FileZilla calls this Send FTP keep-alive commands) to send periodic no-op commands and prevent the connection from being reaped.
Passive mode is the single most misunderstood part of FTP, and misconfigured passive mode causes more mysterious failures than any other issue. FTP uses two channels: a control channel on port 21 for commands, and a separate data channel for file contents and directory listings. In active mode, the server opens the data channel back to the client, which fails whenever the client sits behind NAT or a firewall. In passive mode, the client opens the data channel to the server on a port the server chooses, which works in almost every modern network.
When passive mode is misconfigured, you connect, authenticate, and even issue commands successfully — but directory listings hang, file transfers never start, and the client eventually times out. The telltale symptom is a session that logs 230 (login OK) followed by silence after a LIST or RETR command. The server tried to tell the client to connect to a high port, but something blocked that follow-up connection.
On the server, you must define an explicit passive port range so firewall rules can be written. In vsftpd, set pasv_min_port and pasv_max_port to a range like 40000–41000, then open those ports in the host firewall. If the server sits behind NAT (common on cloud instances with public elastic IPs), also set pasv_address to the public IP; otherwise the server advertises its private IP, which the client cannot reach.
# Enable and bound passive port range pasv_enable=YES pasv_min_port=40000 pasv_max_port=41000 # Advertise the public IP for NATed servers pasv_address=203.0.113.45
On the client side, FileZilla, WinSCP, and lftp all default to passive mode but allow override. If you suspect passive mode is active but something is still wrong, force passive explicitly in the site profile. For curl, add --ftp-pasv — though it is the default — or -P - for active-mode testing. Running both modes and comparing results narrows down whether the issue is NAT, firewall, or client config.
If you cannot modify server configuration and passive mode still fails, FTPS with explicit TLS sometimes helps because middle-boxes stop trying to inspect encrypted data channels. SFTP (SSH File Transfer Protocol) avoids the problem entirely by multiplexing data and control on a single port 22 — if passive-mode pain persists, consider migrating.
FTPS adds a critical security layer over FTP by wrapping the control and data channels in TLS, but it also introduces a new family of errors tied to certificates. Clients validate the server's certificate against trusted root authorities, check its expiration, verify the hostname matches the certificate's Common Name or Subject Alternative Name, and confirm the cipher negotiation succeeded. Any failure stops the connection with a message that mentions SSL, TLS, or SEC_E_ codes on Windows.
The most common message is certificate verification failed, which usually means one of three things. First, the certificate expired — check with openssl s_client -connect ftp.example.com:21 -starttls ftp and look at the Not After date. Second, the hostname does not match: your client connected to files.example.com but the certificate was issued for ftp.example.com. Third, the certificate is self-signed or issued by a CA your client does not trust.
For self-signed certificates on development or internal servers, you can usually choose to trust them permanently in the FTP client's certificate dialog. In production, replace the self-signed certificate with one from Let's Encrypt. The certbot tool handles issuance and auto-renewal; copy the resulting fullchain.pem and privkey.pem into the paths your FTP server expects. For vsftpd, that is rsa_cert_file and rsa_private_key_file; for ProFTPD, TLSRSACertificateFile and TLSRSACertificateKeyFile.
ssl_enable=YES rsa_cert_file=/etc/letsencrypt/live/ftp.example.com/fullchain.pem rsa_private_key_file=/etc/letsencrypt/live/ftp.example.com/privkey.pem ssl_tlsv1_2=YES ssl_tlsv1_3=YES ssl_sslv2=NO ssl_sslv3=NO
Cipher mismatches surface as no cipher match or SSL23_GET_SERVER_HELLO errors. Modern clients disable TLS 1.0 and 1.1 by default; if your server only speaks those, enable TLS 1.2 and 1.3 as shown above. Conversely, legacy FileZilla builds and old scripts may not support TLS 1.3, so support both. Review /var/log/vsftpd.log for lines starting with SSL_accept to see which exact cipher the client offered.
timedatectl set-ntp true on Linux to keep system time accurate automatically.Finally, implicit FTPS listens on port 990 and encrypts the connection from the first byte, while explicit FTPS listens on port 21 and upgrades the connection with an AUTH TLS command. Mixing these — telling the client implicit when the server speaks explicit — triggers obscure handshake failures. Match the client mode to the server's configuration exactly.
You have logged in, you have passed the firewall, and your data channel works — but files still misbehave after uploads. Scripts return 500 errors, images display as broken, text files look like gibberish, or new uploads simply refuse to run. Welcome to the final frontier of FTP troubleshooting: file metadata, transfer modes, and server-side permissions. These problems are rarely dramatic enough to surface as a numeric error, which makes them the hardest to diagnose.
Default upload permissions depend on the server's umask setting. A umask of 022 produces files with mode 644 (readable by everyone, writable only by owner), which is correct for most web content. A stricter umask like 077 creates files mode 600, which the web server cannot read, producing 403 Forbidden errors on your freshly uploaded pages. Set local_umask=022 in vsftpd or Umask 022 in ProFTPD to make this behavior consistent across users.
For individual files, use the SITE CHMOD command through your FTP client to adjust permissions after upload. FileZilla exposes this as a right-click File permissions menu. Common patterns: 644 for HTML, CSS, JS, and images; 755 for CGI scripts, executables, and directories; 600 for configuration files containing secrets; 400 for read-only data that should never change.
# Normalize web content after bulk upload
find /var/www/site -type f -exec chmod 644 {} \;
find /var/www/site -type d -exec chmod 755 {} \;
# Secure a config file
chmod 600 /var/www/site/config.php
chown www-data:www-data /var/www/site/config.phpTransfer mode mismatches cause the second category of silent corruption. FTP has two modes: ASCII, which translates line endings between Windows CRLF and Unix LF, and Binary, which copies bytes verbatim. Uploading a JPEG in ASCII mode corrupts it; uploading a shell script in binary mode from Windows leaves Windows line endings that break the interpreter with bad interpreter: No such file or directory. Most clients default to Auto, which picks mode based on file extension — set it to Binary for everything if you ever see corruption, and manually convert line endings with dos2unix when needed.
utf8_filesystem or equivalent in your FTP server, and set UTF-8 as the client's remote-filename encoding.File locking causes the final class of mysteries. If a process on the server has the destination file open — a logging daemon, a running application, or a previous aborted upload — writes may silently fail or produce corrupted files. Use lsof /path/to/file on the server to find holders, stop them, and retry. For automated upload scripts, always upload to a temporary filename and rename atomically with MV to the final name; readers will never see a partial file. These disciplines turn file transfer from a frequent source of outages into reliable infrastructure.
Troubleshooting is faster when you understand the underlying protocols. Browse our other guides to deepen your knowledge of secure transfers, automation, and deployment workflows.