Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
FileZilla’s “Could not start transfer” message is a queue status, not a diagnosis. The useful error is usually in the log lines immediately before it. Expand the log, identify whether the job was an upload or download, and then check the local file, remote permissions, and FTP data connection in that order. Login can succeed while a transfer fails because FTP opens a second connection for directory listings and file data.
What “Could not start transfer” means
FileZilla uses “Could not start transfer” as a generic failed-transfer status in the queue. It does not tell you whether the cause is a missing local file, a protected destination, an account restriction, a blocked data port, or a server problem. Treat it as the final symptom rather than the diagnosis.
Recommended Free Tools
Before changing a setting, expand the message log and copy the complete sequence for the failed item. Record four details:
- Whether FileZilla was uploading or downloading.
- The local path and filename.
- The remote path and filename.
- The first explicit error before the queue reports that the transfer could not start.
A support example pairs the queue status with a local file-open/read failure. That pattern matters: changing FTP mode cannot repair a source file that no longer exists or cannot be read by your operating-system account.
#1 Best Overall
Use the log to classify the failure
Local-file errors
Messages mentioning opening, reading, writing, access, or a local path point to your computer. An upload needs FileZilla to read the source file. A download needs FileZilla to create or overwrite the destination file.
Remote permission or path errors
Messages returned after a command is sent to the server may indicate that the account cannot read the remote file, cannot write to the target directory, has reached a quota, or is restricted by server policy. A successful login proves only that the credentials were accepted; it does not grant access to every directory.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Data-connection or timeout errors
If login succeeds but the directory listing or transfer never starts, stalls, or fails after a delay, suspect the FTP data connection. Firewalls, antivirus products, NAT routers, and an incorrectly configured server passive-port range can block this second connection.
Certificate or encryption errors
When the log refers to TLS negotiation, certificates, or an encrypted session, the problem is different from a file permission failure. Keep the secure setting whenever the server supports it and investigate the certificate or compatibility issue shown in the log.
Rank #2
- Used Book in Good Condition
Step 1: Verify the local file and destination
For an upload
- In the local-pane file list, browse to the exact source path shown in the log.
- Confirm that the file still exists and that its size is what you expect. A file moved, renamed, deleted, or replaced by a temporary lock can leave a queued transfer pointing at an invalid path.
- Open the file’s operating-system properties and verify that your user account has read access.
- Close applications that may hold an exclusive lock, such as an editor exporting the file, a database utility, or a backup job. Retry only after the application has finished writing.
- Copy the file to a normal user-owned folder, such as your home or Documents folder, and try that copy. This distinguishes a protected-directory problem from an FTP problem.
For a download
- Confirm that the local destination directory exists. Create it before retrying if it was deleted or moved.
- Check that your account can create a small test file there and then delete it.
- Make sure another program is not locking an existing file with the same name. Choose a new filename for a test download if necessary.
- Avoid system-protected locations unless FileZilla and your account are explicitly permitted to write there. A user-writable folder is the safest diagnostic destination.
- Check available disk space. A destination that cannot accept the file can produce a local write failure even though the FTP connection is healthy.
If a local copy works but the original path does not, fix the operating-system permission, lock, or path issue rather than changing FTP settings.
Step 2: Check the remote directory and account
Confirm the intended path
Look at the remote-pane path before retrying. Accounts often open in a home directory, a web-root directory, or a chrooted view that is different from the path you expect. Navigate through the directories in FileZilla instead of relying on an old queued path.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsMatch permission to the operation
| Operation | Required remote capability | Typical symptom when missing |
|---|---|---|
| Download | Read permission on the remote file and permission to enter its directories | Listing may work, but opening or retrieving a file is refused |
| Upload | Write permission on the target directory; often permission to create a new file | Login and listing work, but the upload is refused at start |
| Overwrite | Write permission on the directory and permission to replace the existing file | New filenames work while replacing an existing file fails |
| Create directory | Directory-creation permission on the parent directory | File transfers to an existing folder work, but creating a folder fails |
Try a directory that the account is known to control. If a test upload or download works there, the original location is restricted. Server-side locks, quotas, account policies, and protected directories must be corrected by the server administrator or hosting provider; a client-side mode change cannot grant those rights.
Step 3: Use passive mode first
FTP uses a control connection for commands and a separate data connection for directory listings and file contents. In passive mode, the client sends the PASV command and the server responds with an address for the data connection. The client then makes the outbound connection. This is normally the best first choice for a computer behind a NAT router or firewall.
In FileZilla, open Edit > Settings, select FTP, and choose the passive-mode option under the transfer-mode settings. Apply the change, disconnect, reconnect, and retry a small file.
| Characteristic | Passive mode | Active mode |
|---|---|---|
| Connection direction | Client opens the data connection to the server-selected address and port | Server opens the data connection back to the client |
| NAT and firewall behavior | Usually easier for clients behind NAT; outbound connections still must be allowed | More sensitive to client firewalls, NAT, and incorrect external-address settings |
| Port handling | Server must advertise and permit its passive port range; the client may need outbound access to that range | Client must provide a reachable address and listen on a configured port or range; NAT forwarding may be required |
| When to try it | First choice for most desktop connections | Only when the server specifically requires it or passive mode cannot be made compatible |
Do not switch repeatedly without reading the log. If passive mode reports that the advertised address is unreachable or that a data port timed out, the server’s passive configuration or a network device may need attention.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Step 4: Run FileZilla’s Network Configuration Wizard
FileZilla includes a Network Configuration Wizard for diagnosing FTP connection behavior. Open Edit > Network Configuration Wizard (the exact menu wording can vary slightly by FileZilla build), follow each test, and save the resulting recommendations. The wizard is especially useful when login succeeds but listings or transfers fail.
Review the result alongside local security software:
- Allow FileZilla to make outgoing network connections in the operating-system firewall.
- Check antivirus or endpoint-security logs for blocked FileZilla processes or FTP data sessions.
- If your router has FTP inspection, strict outbound rules, or a configurable ALG, test with the relevant feature documented by the router vendor rather than disabling unrelated protection permanently.
- For active mode behind NAT, the external IP address and forwarded listening-port range must point to the FileZilla computer. A private LAN address is not reachable from the public internet.
- For passive mode, the server must advertise a reachable address and open its selected passive ports. The client cannot repair a server that advertises an internal address.
After each change, reconnect and test one small file. Changing one variable at a time makes the next log entry meaningful.
Step 5: Separate client, network, and server responsibility
When FileZilla is probably not the cause
If the control connection authenticates and the log shows a server refusal, permission error, quota message, or TLS error, the evidence points beyond the transfer queue itself. Send the administrator the complete log for the failed attempt, including the operation, local and remote paths, response codes, and timestamps.
Use another network as a controlled test
When policy and privacy allow it, repeat the same account and small file from another network, such as a trusted mobile hotspot. A transfer that works there suggests a local firewall, router, NAT, or network-policy issue. A failure with the same server response on both networks points more strongly to the account, remote directory, or server configuration.
This test does not prove that a network is safe or that the server is correct; it only changes one side of the connection. Do not expose an FTP service or weaken firewall rules merely to perform a test.
Best Value
Step 6: Handle encryption without creating a security problem
Prefer FTP over TLS when the server supports it. TLS protects credentials and file data from being read in transit and may be required by the server’s policy. Investigate certificate names, trust-chain messages, and protocol incompatibilities in the log rather than accepting an unexpected certificate blindly.
| Connection choice | Compatibility | Protection | Use |
|---|---|---|---|
| FTP over TLS | Requires a server and client that agree on TLS settings and certificate handling | Encrypts credentials and data in transit | Normal choice when offered and correctly configured |
| Plain FTP | Works with older servers that do not provide TLS | Credentials and data are sent without encryption | Only as a temporary, explicitly confirmed compatibility fallback on a trusted network |
If an administrator instructs you to use plain FTP, confirm why, for how long, and whether a secure alternative is available. Do not treat a successful unencrypted transfer as evidence that the setup is safe.
Step 7: Diagnose failures near the end of long transfers
During a transfer, the data connection carries the file while the control connection may remain idle. Some routers and firewalls drop an idle control channel even though the file is still moving. The result can be a large transfer that fails close to completion while small files consistently succeed.
- Compare a small test file with a large file and note where the failure occurs.
- Record the elapsed time before the disconnect and the exact timeout text.
- Check router, firewall, and antivirus logs for an idle-session timeout at that interval.
- Keep the computer awake and prevent network-interface power saving during the test.
- Ask the server administrator whether the server enforces control-channel or transfer-duration limits.
- Where supported by the server and policy, use a stable wired or otherwise reliable connection and retry; do not assume that repeated retries fix an idle-timeout rule.
If the same large file fails at a repeatable time on multiple networks, provide that timing and the full log to the server operator. It may be a server-side timeout or passive-port problem rather than a local file issue.
Common symptoms and the fastest branch to test
| Observed behavior | First check | Likely owner |
|---|---|---|
| Upload says the local file cannot be opened | Source path, read permission, lock, and existence | Your computer or the application holding the file |
| Download cannot create the local file | Destination folder, write permission, lock, and disk space | Your computer |
| Login works but directory listing times out | Passive mode, firewall, router, and server passive ports | Network path or server configuration |
| Listing works but upload is refused | Remote directory write permission, quota, and account policy | Server administrator or hosting provider |
| Listing works but download is refused | Remote file read permission and account restrictions | Server administrator or hosting provider |
| Small files work; large files fail late | Idle timeout, connection stability, and server transfer limits | Network device, client security software, or server |
| Only encrypted connections fail | TLS mode, certificate, and server compatibility message | Client/server encryption configuration |
A clean retry procedure
- Cancel the failed queue item and clear only stale entries; keep the log.
- Reconnect so that the session starts with a fresh control connection.
- Navigate manually to the intended remote directory.
- Use a tiny test file from a user-writable local folder, or download to a user-writable destination.
- Confirm passive mode and run the Network Configuration Wizard if the data connection is unclear.
- Retry once and capture the first explicit error, not just the queue summary.
- If the test succeeds, move to the real file. If it fails, follow the matching branch in the symptom table and give the administrator the complete log when the issue is remote.
What not to do
- Do not infer the cause from “Could not start transfer” alone.
- Do not repeatedly toggle active and passive mode without recording the resulting log.
- Do not grant broad operating-system permissions when moving the file to a user-owned test folder would identify the problem.
- Do not disable the firewall or antivirus permanently. Use a narrow, documented FileZilla allowance and restore protection after testing.
- Do not ask a server administrator to change permissions until you have confirmed the exact remote path and account.
- Do not downgrade to plain FTP merely because TLS produced an error; identify the certificate or compatibility issue first.
When to contact the server administrator or hosting provider
Escalate after local file checks, a permitted-directory test, passive-mode testing, and the Network Configuration Wizard still leave the transfer failing. Include the FileZilla version shown in your installation, connection type, operation, local and remote paths, the first explicit error, whether login and listing succeeded, and whether another network changed the result. Ask the administrator to verify remote permissions, quotas, account policy, passive-port configuration, advertised address, TLS requirements, and server timeouts.
Never include your password in the log or support ticket. Redact usernames, hostnames, and filenames when they reveal confidential information, but leave protocol responses and error text intact.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
