- Remove From My Forums
-
Question
-
User639188962 posted
Okay I have tried all the articles, blogs, and posts but nothing seems to solve anything. I have iis7 with FTP 7.5 and a ftp site created. my router points all request on ports 20-22 to the server and the ports are open on the firewall (even tried disabling
the firewall) I’ve also gone thru the ftp firewall support. I have a network location to the ftp site and when opened it prompts for user name and password which I enter host|username it accepts and errors out with the 501 server cannot accept argument. How
do you get this to work? any help will be appreciated
I am running IIS 8.5 on Windows 2012 R2.
I created an FTP site to use port 8021 and when trying to connect using FileZilla (plain FTP), I get the error message «Connection timed out after 20 seconds of inactivity. Failed to retrieve directory listing». I am using Active mode in FileZilla, but in FileZilla connection window it shows that it automatically switches to Passive mode. Any idea why? Do I have to configure anything in IIS to not use Passive mode?
14:19:39 Status: Connecting to ip:8021...
14:19:40 Status: Connection established, waiting for welcome message...
14:19:41 Status: Logged in
14:19:41 Status: Retrieving directory listing...
14:20:02 Command: PWD
14:20:02 Response: 257 "/" is current directory.
14:20:02 Command: TYPE I
14:20:02 Response: 200 Type set to I.
14:20:02 Command: PORT 10,0,1,16,5,64
14:20:02 Response: 501 Server cannot accept argument.
14:20:02 Command: PASV
14:20:02 Response: 227 Entering Passive Mode (ip,250,68).
14:20:02 Command: LIST
14:20:02 Response: 150 Opening BINARY mode data connection.
14:20:02 Error: Connection timed out after 20 seconds of inactivity
14:20:02 Error: Failed to retrieve directory listing
Thanks in advance.
Update: Tried Passive mode and still no luck,
09:27:20 Status: Connecting to ip:8021...
09:27:21 Status: Connection established, waiting for welcome message...
09:27:22 Status: Logged in
09:27:22 Status: Retrieving directory listing...
09:27:42 Command: PWD
09:27:42 Response: 257 "/" is current directory.
09:27:42 Command: TYPE I
09:27:42 Response: 200 Type set to I.
09:27:42 Command: PASV
09:27:42 Response: 227 Entering Passive Mode (ip,193,17).
09:27:42 Command: LIST
09:27:42 Response: 150 Opening BINARY mode data connection.
09:27:42 Error: Connection timed out after 20 seconds of inactivity
09:27:42 Error: Failed to retrieve directory listing
Update: Solved!
https://www.iis.net/learn/publish/using-the-ftp-service/configuring-ftp-firewall-settings-in-iis-7
Added port range to IIS FTP Firewall Support for server node and opened port range in external firewall to allow Passive Mode. Thanks Martin for pointing out
- Remove From My Forums
-
Question
-
I have an error when trying to connect to a second FTP site. We have the first site on our server working fine. I had to create a second FTP site (assigned a different port — since it said port was already in use). I made the change on my firewall. I am
able to connect to the site, and logon. But cannot see any data — which makes sense due to the error 501 Server cannot accept argument. Error Failed to retrieve directory listing.I was hoping someone could help me resolve this. I tried accessing it via telnet and was able to repeat the error. Any suggestions or help on this would be greatly appreciated.
Thanks — SJMP
Answers
-
The problem was adding the specified ports on the root of the Server Site.
-
Marked as answer by
Wednesday, June 29, 2011 12:55 PM
-
Marked as answer by
Настроил на сервере 2008R2 FTP, прописал правила в брандмауэре на порты. Внутри сети все открывается, с внешних не хочет. Набираешь адрес, выскакивает окно запроса логинапароля, вводишь и появляется ошибка:
В ходе открытия папки на FTP-сервере произошла ошибка. Убедитесь, что у вас есть разрешение открывать эту папку.
Подробности:
200 Type set to A
501 Server cannot accept argument.
Прокси никакой нету, инет на сервер идет через шлюз TP-Link ER 5110. В нем через virtual server настроен проброс на сервер. Что это может быть и что мешает коннекту?
FTP server return codes always have three digits, and each digit has a special meaning.[1] The first digit denotes whether the response is good, bad or incomplete:
1xx
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-FTP processes 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. The server-FTP process may send at most, one 1xx reply per command.
2xx
The requested action has been successfully completed. A new request may be initiated.
3xx
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.
4xx
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 4xx 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 4xx or the 5xx (Permanent Negative) category is that replies are 4xx 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.)
5xx
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.)
6xx
RFC 2228 introduced the concept of protected replies to increase security over FTP communications. The 6xx replies are Base64 encoded protected messages that serves as responses to secure commands. When properly decoded, these replies fall into the above categories.
Below is a list of all known return codes that may be issued by an FTP server.
100 Series
110
MARK yyyy = mmmm
where yyyy is User-process data stream marker, and mmmm server’s equivalent marker (note the spaces between markers and «=»).
120
125
150
200 Series
202
211
212
213
214
215
220
221
225
226
227
228
229
230
232
234
235
250
257
300 Series
331
332
334
335
336
350
400 Series
421
425
426
430
431
434
450
451
452
500 Series
501
502
503
504
530
532
533
534
535
536
537
550
551
552
553
600 Series
631
632
633
10000 Series
10054
10060
10061
10065
10066
10068