FTP - The "File Transfer Protocol"

mail

FTP reply codes ( source : RFC 959 )

Reply Code Typical Reply Text Description
110 Restart marker reply. Used as part of the marker restart feature when transferring in block mode.
120 Service ready in nnn minutes. nnn indicates the number of minutes until the service will be available.
125 Data connection already open; transfer starting.
150 File status okay; about to open data connection.
200 Command okay. Sometimes the text indicates the name of the command that was successful.
202 Command not implemented, or superfluous at this site.
211 System status, or system help reply. Will contain system-specific status or help information.
212 Directory status.
213 File status.
214 Help message. Includes help information of use to a human user of this server.
215 NAME system type. NAME is the name of a type of operating system. Often sent as a reply to the SYST command.
220 Service ready for new user. Sent when the command channel is established before the USER command is sent.
221 Service closing control connection. A goodbye message sent when the session is closed.
225 Data connection open; no transfer in progress.
226 Closing data connection. Sent after a successful file transfer or a file abort.
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). Sent in reply to the PASV command, indicates the IP address and port to use for the data connection.
230 User logged in, proceed. Sent after successful USER and PASS authentication. Systems often include additional greeting or other information with this code after a login.
250 Requested file action okay, completed. The text description will provide more details about what was successfully done, such as confirming a change of directory or deleted file.
257 "PATHNAME" created. "PATHNAME" is replaced by the path created.
331 User name okay, need password. Intermediate result after sending USER but before sending PASS.
332 Need account for login.
350 Requested file action pending further information.
421 Service not available, closing control connection. Sometimes sent if the FTP server is in the process of shutting down.
425 Can't open data connection.
426 Connection closed; transfer aborted.
450 Requested file action not taken. File unavailable. The file is not available; for example, it may be locked by another user. Contrast to reply code 550.
451 Requested action aborted: local error in processing.
452 Requested action not taken. Insufficient storage space in system. The file system is full.
500 Syntax error, command unrecognized. Bad or excessively long command line was sent.
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
530 Not logged in. Sent if authentication fails due to a bad user name or incorrect password.
532 Need account for storing files.
550 Requested action not taken. File unavailable. File was not found or user does not have access to it. This error code may be sent in reply to any file transfer command if the user has not successfully logged in yet. Contrast to reply code 450.
551 Requested action aborted: page type unknown.
552 Requested file action aborted. Exceeded storage allocation.
553 Requested action not taken. File name not allowed.
10065 No route to host

Tips about the FTP reply codes ( source : RFC 640 )

number When used as 1st digit When used as 2nd digit
0 (not used)
Syntax
These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, unimplemented or superfluous commands.
1
Positive Preliminary reply
The requested action is being initiated; expect another reply before proceeding with a new command. (The user-process sending another command before the completion reply would be in violation of protocol; but server-FTPprocesses should queue any commands that arrive while a preceding command is in progress.) This type of reply can be used to indicate that the command was accepted and the user-process may now pay attention to the data connections,for implementations where simultaneous monitoring is difficult.
Information - These are replies to requests for information, such as status or help.
2
Positive Completion reply
The requested action has been successfully completed. A new request may be initiated.
Connections
Replies referring to the TELNET and data connections.
3
Positive Intermediate reply
The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The user should send another command specifying this information. This reply is used in command sequence groups.
Authentication and accounting
Replies for the logon process and accounting procedures.
4
Transient Negative Completion reply
The command was not accepted and the requested action did not take place, but the error condition is temporary and the action may be requested again. The user should return to the beginning of the command sequence, if any. It is difficult to assign a meaning to "transient", particularly when two distinct sites (Server and User-processes) have to agree on the interpretation. Each reply in the 4yz category might have a slightly different time value, but the intent is that the user-process is encouraged to try again. A rule of thumb in determining if a reply fits into the 4yz or the 5yz (Permanent Negative) category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server (e.g. the command is spelled the same with the same arguments used; the user does not change his file access or user name; the server does not put up a new implementation.)
(not used)
5
Permanent Negative Completion reply
The command was not accepted and the requested action did not take place. The User-process is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct his User-process to reinitiate the command sequence by direct action at some point in the future (e.g. after the spelling has been changed, or the user has altered his directory status.)
File system
These replies indicate the status of the Server file system vis-a-vis the requested transfer or other file system action.
6 to 9 (not used)
mail

The FTP protocol

FTP is a protocol designed to transfer files over TCP-based networks (LAN, WAN).
FTP uses separate control and data connections between the client and the server. FTP normally transfers data by having the server connect back to the client, after the PORT command is sent by the client. This is problematic when it comes to firewalls and NAT.

Data transfer modes :

  • PORT says Hey server, I'm opening this port, please connect to it for data connection. This would be done with :
    PORT a,b,c,d,4,1
    • The first 4 fields a, b, c and d represent the a.b.c.d IP address waiting for the data connection.
    • The following 2 fields are used to calculate the destination port of the data transfer. In our example : (4 * 256) + 1 returns 1025 (source).
  • PASV says Hey server, I want to open a data connection to you, which port should I connect to?, to what the server may answer :
    227 Entering Passive Mode (192,168,0,100,105,163)
    • The first 4 fields are the dotted quad IP address of the server accepting the requested data transfer.
    • The following 2 fields are used to calculate the destination port of the data transfer. In our example : (105 * 256) + 163 returns 27043 (source).

Active :

  1. The client opens the control connection from a random port to port 21 of the server.
  2. The client sends the PORT command to the server to instruct it to connect back to a specified IP address and port number.
  3. From its port 20, the server opens the data connection to the specified IP address and port of the client.
  4. Data transfer can begin.

Passive :

  1. The client opens the control connection from a random port to port 21 of the server.
  2. The client sends the PASV command to the server to ask for a port on the server side to connect to in order to establish the data connection.
  3. The client opens the data connection from an other random port to the port indicated by the server.
  4. Data transfer can begin.

With NAT and firewalls :

See : Why PASV Poses Problems for FTP Servers behind Load-Balancing Routers