Common FTP, FTPS & SFTP Error Codes and What They Mean

When working with file transfer protocols like FTP, FTPS, and SFTP, servers send and receive various return codes during sessions. Some codes indicate successful file transfers, while others signal errors and require further action. And when things go wrong, understanding the meaning behind the sever return codes can save you and your team time, money and frustration.  

Given the number of server return codes related to Managed File Transfer (MFT) falls well into the hundreds, we could easily spend all day deciphering them for you. Instead we’ve chosen to highlight the most common server return codes across FTP, FTPS and SFTP sessions, explain what they mean, and provide some best practises and top tips for resolving them. 

 

What are the most Common FTP and FTPS Error Codes?  

FTP and FTPS largely share the same server return codes. These codes are made up of three digits, with each digit serving a specific meaning. The first digit indicates the general category of the response, whether it’s a success, failure or further action is needed. The second and third digits provide more information on the status, helping to clarify the exact issue behind the server's return code.  

The table below highlights the most common server return codes that can occur during file transfers over secure FTP and secure FTPS. 

FTP & FTPS Server Return Code Number 

FTP & FTPS Server Return Code Name 

What does it mean? 

150 

File status OK, open data connection 

This return code indicates that the server is ready to initiate a file transfer but is awaiting a data connection. Make sure a PASV or PORT command has been sent before to make sure the application is sending it commands in the right order. 

226 

Closing data connection 

A positive code stating the data connection will close after the last successful command send, such as a file transfer. 

230 

User Logged in, proceed 

A positive server return code indicating successful user login. If troubleshooting connections look out for this to confirm the user credentials are correct. 

421 

Closing control connection 

This occurs when the server shuts down or undergoes maintenance. 

425 

Cannot open data connection 

 

The server failed to establish a data connection to the client. This can happen if the required firewall rules are not in place to allow traffic on the required port. 

452 

Requested action not taken 

A negative response to the usage of a data connection, it is considered a transient state and often due to when a connection is unexpectantly closed. Client software would be encouraged to retry the connection.  

500 

Syntax error 

 

This typically occurs due to a misspelled command. 

504 

Command not implemented 
for that parameter 

This sever return code is sent when any command uses a parameter that the server does not support. To resolve this, review the command being sent. 

530 

User is not logged in 

An authentication error, usually caused by incorrect username, password, or login method. 

550 

Requested action not taken 

The file either cannot be found, or the user does not have the necessary permissions to perform the action. 

 

Whilst FTPS shares many of the same codes with FTP, it also includes additional SSL/TLS server return codes that are unique to the protocol, which are outlined below. 

FTPS Server Return Code Number 

FTPS Server Return Code Name 

What does it mean? 

234 

Security negotiation successful 

This indicates that the server and client have agreed upon an encryption cipher and have started the handshake. 

431 

Unavailable resources for security 

This occurs when a required resource, such as a suitable SSL certificate or encryption method, is missing. 

534 

SSL not allowed 

This return code signifies that the server requires SSL/TLS for secure communication. It may also indicate that SSL/TLS is mandatory for login. 

 

What are the most common SFTP Error Codes?  

SFTP server return codes work differently and use 12 primary codes to describe issues. Traditionally in secure SFTP applications you are less likely to see the numerical codes themselves but the clear written text such as “OK” in the applications logs. 

The table below highlights the most common server return codes that can occur during file transfers over secure SFTP. 

SFTP Error Code Number 

SFTP Error Name 

What the error means and why it occurs 

0 

Ok 

The operation requested was successful. 

1 

End of file 

This response signifies that the end of the file has been reached. 

2 

No such file 

This SFTP server return code is given when the requested file or directory cannot be found. 

3 

Permission denied 

The user requesting the action does not have the necessary permissions to perform it. 

4 

Failure 

A generic response indicating that the requested operation has failed. Additional information may be sent to explain the issue. 

5 

Bad message 

This server return code is displayed when the client sends a request that is not part of the SFTP protocol syntax, and the server does not understand what to do. It could be formatted incorrectly. 

6 

No connection 

This occurs when the connection cannot be established. 

7 

Connection lost 

If the connection drops during a file transfer this will appear in the logs, which can happen due to several reasons. 

8 

No such handle 

This refers to an open file or directory that cannot be recognised. 

9 

File already exists 

The file or directory already exists, and you do not have overwrite permissions. 

10 

Write-protected 

The file is write-protected and cannot be modified. 

11 

No media 

This server return code typically occurs if removable storage is used as part of the server. 

12 

No space on the filesystem 

This server return code will appear if there is insufficient space on the filesystem to write new files. 

 

Understanding server return codes can be advantageous in diagnosing issues, helping to save both time and resources. It’s important to note that how the code is displayed in your software logs depends on how the software developer has implemented error handling. The codes we have discussed above are the core protocol server return codes which systems use to communicate back and forth. You might not see them if the software developer has designed it differently. Generally, if you don’t see a numerical code, you’re likely to see a written description, such as “unexpected disconnection”. Familiarising yourself with how your software approaches its logging and error-handling is highly recommended and can be helpful when working with third parties to resolve any issues as their system's logging may differ from yours. 

Armed with the knowledge of server return codes is the foundation for effectively diagnosing and resolving issues quickly. With that in mind, here are our tips and best practices for resolving file transfer server return codes both before and as they occur: 

 

  1. Keep your MFT solution up to date: Updating your MFT system not only ensures security but also provides access to the latest encryption libraries, which can resolve negotiation issues.

  2. Set a sensible log rotation and clean-up schedule: By regularly managing your logs, you make it easier to isolate relevant entries when an issue arises. 

  3. Test with a neutral third party: If you're experiencing connection issues, test the transfer with a neutral third-party server. This helps This helps isolate whether the issue lies with your side or the endpoint, allowing you to pinpoint the problem faster.

  4. Testing Environment: Try installing the base product of your managed file transfer on a fresh machine and try making the same connection, a lot of MFT products come with a trial period for testing and if you find the issue is still present you can rule out your own configuration as the root of the issue.

  5. Communicate with the other party: In a client-server model, you only see part of the picture if you encounter an issue with your file transfer exchanges. Always reach out to the person you're connecting to (or who is connecting to you) and request their logs. This way, you can capture the full scope of the issue and troubleshoot more effectively.

  6. Invest in a dashboarding and analytics solution for your MFT: Digging through logs and trying to work out exactly how or why a transfer has failed is time consuming and frustrating. And that’s assuming you know that the transfer has failed. A bespoke Dashboarding Tool will alert you to issues with your file transfers and make it easier to identify the root cause of your errors. You can read more about file transfer dashboarding and analytics here. 

 

Handling server return codes, not just over FTP, FTPS and SFTP servers, but across all file transfer protocols follows a similar approach. It is important to first isolate which side of the model the issue originates - whether on your side or the other party’s. At Pro2col we recommend working from the inside out. Start with your software to ensure it’s properly configured and up to date. Then, if the problem persists, test the connection using an alternative client from the same machine your MFT software runs on to rule out client-specific issues. If the issue stays unresolved, extend your troubleshooting outside of your network. Failing that, if the issue continues, it is likely the error is sitting at the other end of the connection. This order of testing can reduce the diagnostic time, helping you quickly pinpoint the root cause of the issue. 

If you try the above methods and still find you’re at a dead end, it’s time to reach out to your support partner. They will be able to leverage their extensive internal knowledge base to assist in resolving the issue. If your current solution lacks support or isn’t meeting your needs, we encourage you to reach out to us at Pro2col. As the leading file transfer experts, we can help you in finding a supported solution tailored to your business needs. We offer consultancy, managed services, hosting and training opportunities all designed to support you and your team on your journey to becoming secure file transfer experts. 

 

About the Author

  
sean-headshot-23

 

Sean Holdstock is the Technical Consultant at Pro2col. As a Technical Consultant Sean keeps up to date with trends and changes in the IT marketplace to give him a clear outlook on how technology evolves.

He’s not afraid to challenge his knowledge by learning new code languages and always looks for ways this could help his colleagues and customers. 

Find out more about Sean here.