FTP reply code 350 is an intermediate response indicating the server received the first part of a two-command sequence and is waiting for the second part. The most common occurrence is during file renaming: the client sends RNFR (rename from) to specify the source file, receives 350, then sends RNTO (rename to) with the destination name. Code 350 also appears after the REST command when setting up a transfer resume — the server acknowledges the restart byte offset and waits for the subsequent RETR or STOR command. Without the follow-up command, the server will eventually time out and reset.
The client sent RNFR /path/oldname to specify a file to rename. The server verified the file exists and sent 350. The client should now send RNTO /path/newname to complete the rename operation.
The client sent REST with a byte offset to set up a transfer resume. The server accepted the offset and sent 350. The client should now send RETR (to resume download) or STOR (to resume upload) to begin the transfer from that offset.
After RNFR, send RNTO with the new filename. After REST, send RETR or STOR with the filename. The server is waiting for the second command to complete the operation.
If RNFR fails with 550 instead of 350, you do not have permission to rename the file or the file does not exist. Verify the path and your permissions.
Not all servers support REST for transfer resumption. Check the FEAT response for REST STREAM to confirm resumption is available.
curl -v ftp://ftp.example.com/ -Q 'FEAT'
The file or directory operation was completed successfully.
The file operation was not completed because the file is temporarily unavailable.
The file or directory operation failed. The path does not exist, or access is denied.
The file transfer completed successfully and the data connection is being closed.