Я пытаюсь использовать Filezilla в Windows для подключения к экземпляру linux ec2, на котором запущен vsftpd 2.3.5 (также пробовал 2.3.2 с идентичными результатами), но сервер продолжает отвечать 500 OOPS: vsf_sysutil_bind, а затем вторичная ошибка, которая различается в зависимости от от того, использую ли я активный или пассивный режим (см. журналы ниже).
Эта установка работала нормально пару дней назад. Насколько я могу судить, в конфигурации сервера ничего не изменилось, но теперь вас выкидывают сразу после подключения. Я перезапустил vsftpd, но сам сервер еще не перезапустил. Что могло вызвать такое поведение, почему оно могло внезапно возникнуть и как это исправить?
Если я использую активный режим, журнал на стороне клиента выглядит следующим образом:
...
Response: 230 Login successful.
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PORT 192,168,1,101,250,178
Response: 200 PORT command successful. Consider using PASV.
Command: LIST
Response: 500 OOPS: vsf_sysutil_bind
Error: Failed to retrieve directory listing
Response: 500 OOPS: priv_sock_get_cmd
Error: Connection closed by server
Если я подключаюсь в пассивном режиме, журнал на стороне клиента немного отличается:
....
Response: 230 Login successful.
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: EPRT
Response: EPSV
Response: MDTM
Response: PASV
Response: REST STREAM
Response: SIZE
Response: TVFS
Response: UTF8
Response: 211 End
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Response: 500 OOPS: vsf_sysutil_bind
Command: PORT 192,168,1,101,249,253
Response: 500 OOPS: priv_sock_get_int
Error: Failed to retrieve directory listing
Error: Connection closed by server
В любом случае, журнал vsftpd просто говорит:
Tue Dec 27 23:32:18 2011 [pid 19875] CONNECT: Client "XXX.XXX.XXX.XXX"
Tue Dec 27 23:32:18 2011 [pid 19874] [username] OK LOGIN: Client "XXX.XXX.XXX.XXX"
Мой vsftpd.conf:
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
idle_session_timeout=600
data_connection_timeout=900
ftpd_banner=Welcome to FTP
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port=12000
pasv_max_port=12100
pasv_address=XXX.XXX.XXX.XXX
port_enable=YES
port_promiscuous=YES
user_config_dir=/etc/vsftpd/users
У меня были проблемы с этой проблемой в течение последних нескольких дней, сначала я следовал маршруту одного ответа установки proftpd. Это не сработало, как я надеялся, поэтому я попробовал pure-ftpd, в противном случае я вернулся к vsftpd, проблема решила для меня увеличение количества пассивных портов, я ранее разрешал только диапазон 10090: 10100, что всего 10 портов.
С тех пор я разрешил больший диапазон портов для vsftpd, и это решило мою проблему, я больше не получаю эту ошибку при загрузке длинных списков файлов с 10 файлами за раз.
Надеюсь, это поможет любому, кто столкнется с этой проблемой в следующий раз.
В итоге я избавился от vsftpd и переключился на proftd который отлично работает в активном и пассивном режимах без каких-либо изменений в настройках брандмауэра сервера. Я до сих пор не уверен, что вызвало проблему, но если это происходит с вами, ответом может быть изменение программного обеспечения FTP-сервера.
Это похоже на проблему с брандмауэром. Не могли бы вы дважды проверить, что на портах 20/21 больше ничего не работает, а пассивные порты разрешены?