[Bug] FTP on Windows Explorer not work

[red7nikotin]

Description

Since there is no basic example in the documentation for setting up an elementary connection using basic protocols, including FTP, I had to spend a lot of time myself to write my instructions and check everything. As a result, I got an almost working solution, but there is one very important point - the graphical connection mode via the standard basic Windows Explorer does not work.

Steps to Reproduce

Steps to reproduce the behavior:

1. Follow my instructions for working with the attached file and follow all the steps in it sequentially
   ErrFTP.html

2. Error on step "7.4. Launch Windows File Explorer from cmd"

For convenience, I have shown a ready-made command that should launch the Windows Explorer window from Windows CMD, but in reality I will not do this, I immediately open Windows Explorer with the mouse in the desktop GUI and enter the connection command in its address bar. "ftp://192.168.0.81:10021 "

In general, the result is the same in both cases - I get an error, but the connection works without problems if I run it from Windows CMD in the step "7.1. Command line (cmd) – anonymous" and "7.2. Command line (cmd) – user1"

Expected Behavior

I expect to see a login and password prompt window and then the contents of my FTP, i.e. the Public and Private folders.

Actual Behavior

If I immediately use a command that adds a username, then I get a login and password entry window, but even if I enter all the parameters correctly and login and password, or select anonymous access, I get an error and as a result an empty window without folders and files.

Additional Context

I don't know what the mistake is, because you don't have any basic examples in the instructions, which I've already mentioned many times and asked you to add. Perhaps the problem is in the passive mode through which Windows FTP works, but I seem to have forwarded all the ports correctly. In general, I do not understand what the error is and ask for help to solve it, and also ask to add my instructions to your documentation after correction.

[ExTV]

Found it, and reproduced it on a device. You were right to suspect passive mode.

What is happening

Windows' command line ftp.exe uses active mode: it tells the server to connect back to the PC. That works, which is why steps 7.1 and 7.2 succeeded for you.

Windows Explorer uses passive mode: it asks the server where to connect, and the server answers with an address and a port. The guest sits behind a private network inside the VM, so it answers with its own internal address. Here is the exchange, captured on a real device with a client forced into that mode:

< 227 Entering Passive Mode (10,0,2,15,164,125).
*  Trying 10.0.2.15:42109...

10.0.2.15 only exists inside the VM. Explorer dutifully tries to open the data connection to it, reaches nothing, and you get the empty window. Nothing about your port forwarding was wrong.

FileZilla and most modern clients never hit this, because they use the newer extended passive command, which returns only a port and reuses the address they are already talking to. Same server, same rules, different result, which is what made this so confusing.

The fix

Tell the server which address to advertise, and pin the passive ports so you can forward a small range instead of hundreds:

pasv_enable=YES
pasv_min_port=42100
pasv_max_port=42109
pasv_address=<the phone's address on your network>
pasv_addr_resolve=NO

Then forward host 2121 to VM 21 for the control connection, plus 42100 to 42109 to the same numbers, and connect to ftp://<phone-address>:2121. With that, the same exchange becomes:

< 227 Entering Passive Mode (<phone-address>,164,116).
< 226 Directory send OK.

and Explorer works.

One caveat worth knowing: pasv_address is a fixed address, so it has to be updated when the phone moves to a different network. The Status screen lists the addresses the phone currently has.

Two other things from your instructions

Do not forward a large passive range. Your other report, #52, was caused by exactly that: a thousand saved forwarding rules, one of which could not bind, which stopped the VM from starting at all. Ten passive ports are plenty for a phone.

And if the client is yours to choose, SFTP is a better answer than FTP here: it rides the SSH port that already exists on 9922, needs no passive range and no extra rules, and is encrypted. The guest ships without the helper binary, so it is one package:

# apk add openssh-sftp-server

WinSCP and FileZilla both speak it. Windows Explorer does not, which is the one reason to keep FTP around.

The whole thing, both protocols and the working vsftpd configuration, is now written up in the networking guide, along with what cannot work at all and why. Thank you for the detailed instructions file: working from it is what made this quick to pin down.