GNOME Bugzilla – Bug 579851
ftp parser cannot read / directory, but command line ftp can
Last modified: 2009-04-22 20:23:57 UTC
Please describe the problem: TP works in the command line, but not in Nautilus or Firefox. The connection seems to be accepted, but both are unable to display the content of the directory. I'm using an up-to-date Jaunty distribution. The Nautilus error message is: --------- The folder contents could not be displayed. Sorry, could not display all the contents of "/ on xxx.xxx.xxx.xx": DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. --------------- This is the output of a command line ftp connection: leandro@xxxx:~% ftp xxx.xxx.xxx.xx Connected to xxx.xxx.xxx.xx 220 Bem Vindo XXX.XXX Name (xxx.xxx.xxx.xx:leandro): 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> pwd 257 "/" ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwxr-xr-x 54 997 100 4096 Jan 23 11:48 Documents drwxr-xr-x 4 997 100 4096 Apr 03 19:24 backup drwxr-xr-x 2 997 100 4096 Mar 09 2006 bin drwx------ 2 997 100 4096 Mar 21 2006 mail drwxrwxrwx 5 997 100 4096 Mar 26 19:00 public_html 226 Directory send OK. ftp> quit 221 Goodbye. ------------------------------------------------ Running /usr/lib/gvfs/gvfsd -r and then trying to connect using gvfs-mount provides, for the same connection: <-- 220 Bem Vindo XXX-XXX --> FEAT <-- 211-Features: <-- EPRT <-- EPSV <-- MDTM <-- PASV <-- REST STREAM <-- SIZE <-- TVFS <-- UTF8 <-- 211 End feature EPSV supported feature MDTM supported feature SIZE supported feature TVFS supported feature UTF8 supported --> OPTS UTF8 ON <-- 200 Always in UTF8 mode. --> USER leandro <-- 331 Please specify the password. --> PASS *** <-- 230 Login successful. --> TYPE I <-- 200 Switching to Binary mode. --> SYST <-- 215 UNIX Type: L8 ########## At this point no message appears until I open Nautilus and try to see the content ########## of the remote directory. Messages continue as folows, until nautilus provide the error ########### above system is 1 --> NOOP <-- 200 NOOP ok. --> NOOP <-- 200 NOOP ok. --> NOOP <-- 200 NOOP ok. --> NOOP <-- 200 NOOP ok. --> NOOP <-- 200 NOOP ok. --> CWD / <-- 250 Directory successfully changed. --> EPSV <-- 229 Entering Extended Passive Mode (|||40002|) Successful EPSV response code, but data connection failed. Enabling FTP_WORKAROUND_BROKEN_EPSV. --> PASV <-- 227 Entering Passive Mode (150,162,70,1,156,74) Successfull PASV response but data connection failed. Enabling FTP_WORKAROUND_PASV_ADDR. Steps to reproduce: 1. In Ubuntu (Jaunty or older), go to Places -> Connect to Server 2. Try to connect to ftp server with login 3. Wait for content to be displayed. Actual results: The contents are not displayed and the error message: The folder contents could not be displayed. Sorry, could not display all the contents of "/ on xxx.xxx.xxx.xx": DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. appears. Expected results: The content of the remote folder to be displayed. Does this happen every time? Yes. Other information: Ftp from command line works, as described above.
(In reply to comment #0) [...] > ftp> ls > 200 PORT command successful. Consider using PASV. > 150 Here comes the directory listing. You seem to be using Active mode in your command line ftp client. Could you please also test if it works when you switch to Passive mode? In lftp you could do something like: lftp :~> set ftp:passive-mode yes (in lftp it might also be interesting to see the information it will spit out if you run "debug".) For others I think it might be possible to set the environment variable like this: $ FTP_PASSIVE=yes ftp xxx.xxx.xxx.xxx The reason I'm asking is because gvfsd-ftp *only* supports passive mode. See bug 516704. [...] > --> EPSV > <-- 229 Entering Extended Passive Mode (|||40002|) > Successful EPSV response code, but data connection failed. Enabling > FTP_WORKAROUND_BROKEN_EPSV. > --> PASV > <-- 227 Entering Passive Mode (150,162,70,1,156,74) > Successfull PASV response but data connection failed. Enabling > FTP_WORKAROUND_PASV_ADDR. > Thanks for providing this log, it shows that both methods of initiating a passive mode transfer fails (probably because of a firewall on the server side not allowing the data channel connection to be established - ask the server admin to fix their firewall).
You are correct. Using passive mode it the problem occurs in the command line as well: leandro@farrapo:~% ftp -pd xxx.xxxx.xxx.xx Connected to xxx.xxx.xxx.xx 220 Bem Vindo XXX.XXX ftp: setsockopt: Bad file descriptor Name (www.enq.ufsc.br:leandro): ---> USER leandro 331 Please specify the password. Password: ---> PASS XXXX 230 Login successful. ---> SYST 215 UNIX Type: L8 Remote system type is UNIX. Using binary mode to transfer files. ftp> ls ftp: setsockopt (ignored): Permission denied ---> PASV 227 Entering Passive Mode (150,162,70,1,157,28) ftp: connect: Connection timed out ftp> So the problem is identified. The suggestion that the administrator fixes the firewall is to mean that the bug is not valid? Shouldn't it be possible to use gvfs with this type of connection, since other clients are able to do so?
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 516704 ***