up vote 1 down vote favorite
2
share [g+] share [fb]

Goal:

provide a 'no-software' method for 'less technical' users to access password protect ftp location from Windows 7 and Vista (existing approach for Windows XP works).

'No software' method to mean without installing additional software (e.g. FileZilla, WinSCP) - the solution is supplied to external non-technical users.

Windows XP (works):

Using Windows Explorer, Windows XP supports non-technical ftp access by pasting:

ftp://username:password@server.com

into the address bar.

The remote ftp site's files / directory structure becomes available and can be copied to / from easily (in the style of local file copy / paste) by a 'less technical' user.

Windows 7 / Vista (doesn't work):

Pasting the same URL into the Windows Explorer on Windows 7 or Vista causes an error:

An error occurred opening that folder on the FTP server. Make sure you have permission to access that folder.

Details: 
The connection with the server was reset.

Notes:

a) The same username/password/server typed from the (DOS) command line achieves access to the server, but this is a more 'technical' solution than desired. I am looking for a Windows XP equivalent solution.

b) Under 'Control Panel' / 'Internet options' / 'Advanced' tab - the boxes for 'Enable FTP folder view' and 'Use Passive FTP' are ticked (enabled)

c) Adding an inbound firewall rule for local port 20 (TCP) was attempted with no difference in results (I.e. failure)

link|improve this question
feedback

2 Answers

up vote 1 down vote accepted

Contrary to what you would expect, if you untick 'Use Passive FTP' (i.e. disabled) (under 'Control Panel' / 'Internet options' / 'Advanced' tab), then, after a couple of 'Approval' dialog boxes, the target FTP site will be accessible from both Internet Explorer and Windows Explorer.

Rules are auto-added to the Windows Firewall - these rules appear to be the same as one manually added (except they work...).

The same change enables Vista and Windows 7, and works for both anonymous sites and those requiring a username/password.

link|improve this answer
Further investigation indicates that the 'untick' forces use of Active FTP which the local intranet firewall (at work) supports - the command line FTP was using active FTP (and so worked based on the local (work) firewall). This indicates that the results elsewhere may vary based upon your local firewall settings and its capabilities. Short-term and temporary disabling of the Windows firewall (with passive FTP ticked) may be the option of last resort. – Stephen Jones Feb 11 '10 at 1:28
feedback
up vote 0 down vote

Passive FTP will initiate both connections from the client side. The ports are randomly chosen from 1023 and above usually, so opening port 20 doesn't really help much. You could try adding an exception for Windows explorer to the firewall temporarily. See if disabling it altogether will allow you to connect, if it does you know where your problem lies, then turn the firewall back on!

link|improve this answer
With the firewall off, Win7 Windows Explorer operates as per WinXP and presents the files on the remote server! Adding inbound (and outbound...) filter rules on the firewall for %windir%\explorer.exe (Windows Explorer) did not allow access when the firewall was on. – Stephen Jones Feb 9 '10 at 3:11
That would indicate it is not explorer itself initiating the connections, but another forked process. The netstat command should help you pinpoint that ;) – John T Feb 9 '10 at 3:42
Netstat seems to indicate explorer.exe is the one attempting the ftp connection. A technical chap performed a Wireshark capture of successful and unsuccessful attempts, and could not identify an explainable difference. The unsuccessful attempts seemed to perform a reset initiated from the PC end (i.e. local) after an otherwise good establishment. – Stephen Jones Feb 9 '10 at 5:57
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.