FTP server fails to list a directory's content even on LAN

  • Hello there. The thing is: I can log to my server with no problem, but it appears that the (chroot-ed) directory (folder) is always empty.
    For now I'm trying it via LAN, so there shouldn't be any firewall or something.


    Configuration:

    • Passive mode with the default port range.
    • SSL/TLS enabled. Explicit ("forced") SSL/TLS connection.
    • All necessary shared folders are set.
    • Group "users" chroot-ed to the root directory of the storage hard drive (/media/HDD).

    I tried to connect to it by using WinSCP, and successfully listed the directory's content. Well... until I finished to upload/download a file; then the problem occurs. Not tested yet with Filezilla.


    On the other hand, with my Android phone this always happen. I'm using the ES File Explorer app; and here, the remote folder still looks empty (even when already has something in it).


    I've tried the following (with an unsuccesfully result):

    • Disable SSL/TLS and it's request.
    • Remove the chroot jail.
    • "chown root:root" the root directory of the hard drive.
    • "chmod 755" all the shared folders (they've had the permission "700" before that).
    • Reboot the server machine.
    • Connect as plain FTP.

    Hope you understood my problem and any help will be appreciated.


    Best regards!

  • The configuration file currently looks like this:


  • That command throws me this:



    I think the results on the other shared folders and its files would be almost the same...

  • uhhhh... apparently I did. ?(
    I mean, the first one... yes; but the other one... is it a default option or is it generated by the web GUI administrator?
    I didn't even know of the existence of that line.
    So... shall I delete that "unused" line or what?


    Remember: the idea is to chroot any non-root FTP session.
    And don't forget the main problem: directory listing failure.

  • No, I didn't edited it "manually". I just typed that line in the "Extra options" text field (OMV web GUI).


    Ok, now I deleted it, and now only the default DefaultRoot line appears in the config file.
    Then rebooted the server... still no luck :(


    Why is this happening?

  • Zitat

    Disable and enable the gpt service


    What is the "gpt service"? Did you misspelled something?


    Anyway, I did all that, and... nice! Now directory listing works! (for both Filezilla and ES File Explorer)
    And also I realized that the chroot was made by default, so you are right: I shouldn't set it explicitly.


    What's more, I re-enabled passive mode and Explicit SSL/TLS, NOW DIRECTORY LISTING STILL WORKS EVEN AFTER THAT!!! :thumbup:
    What happened before? Why just deleting that extra option didn't fixed my problem? ?(


    PD: I don't know how to mark this thread as "Solved", otherwise I would have done that already.

    • Offizieller Beitrag

    What is the "gpt service"? Did you misspelled something?


    i meant ftp service i was in mobile browser to must be auto correct.


    What happened before? Why just deleting that extra option didn't fixed my problem


    Depends if you deleted the line and left the panel well it doesn't work. you need to save and apply. That should redo the proftpd.conf file and restart the server with the new configuration file. I just added more steps to ensure everything was clean, like delete the shares and re-add them, but it shouldn't be necessary on everyday use.

  • I'm going to do an update.


    I tried to reconnect to the server, over and over, using Filezilla; and it works like a charm every time.
    However, with some Android FTP clients, I got the problem again.


    So two questions:

    • Why some Android FTP clients simply can't display the directory's content? (even when all parameters are correct). It has to do with the certificate?
    • Once the working client couldn't connect to the server, even when both were in the same network. Was that something in the server or else? Hope this doesn't happen again.

    An extra question: how to ensure that any FTP connection is always secure? (encrypted). Since this service is meant to be accessed remotely (out of the LAN).


    Thanks once again! :D

    • Offizieller Beitrag

    Why some Android FTP clients simply can't display the directory's content? (even when all parameters are correct). It has to do with the certificate?


    Maybe, you can ask the app developer, it probably has to do with installing a rootCA in trusted section. I can try later in android app 4.4 if that one is not paid


    An extra question: how to ensure that any FTP connection is always secure? (encrypted). Since this service is meant to be accessed remotely (out of the LAN).


    Use SSL/TLS, i think is explicit mode the most common one, implicit involves redirecting port 990 at wan side, won't go into any further you can look up info in the internet

  • it probably has to do with installing a rootCA in trusted section.


    What does that mean?


    you can look up info in the internet


    I'm starting to worry about that. Just look at what Wikipedia says about Explicit SSL/TLS:


    If a client does not request security, the FTPS server can either allow the client to continue in insecure mode or refuse the connection.


    So, does this mean that the implicit/explicit mode is actually a server configuration?
    If so, how to make my FTP server reject any insecure connection? (which is what I need)

    • Offizieller Beitrag

    What does that mean?


    root certificate authority, haven't you ever use a self signed certificate? you type the web address and the browser gives you a big fat warning about this certificate not being issued by a trusted authority. In mobile devices sometimes the OS won't let you pass further until you install the CA cert that issued the self signed certificate, this is guessing since I am not sure how other protocols behave besides https, iOS for example gives you the option to continue anyway in mobile brwoser



    So, does this mean that the implicit/explicit mode is actually a server configuration?


    Yes server, and you select the option in the client if the server has TLS/SSL enabled


    If so, how to make my FTP server reject any insecure connection? (which is what I need)


    Haven't you read the FTP SSL/TLS options in the omv panel ? I am quoting here the options Required ON/OFF "This option requires clients to use FTP over TLS when talking to this server."


    If you don't feel secure with the options just switch to SFTP (SSH) using public/private keys, for users just add them to the ssh group. Tutorials can be found in the guide section for SSH and SFTP

  • haven't you ever use a self signed certificate?


    Using the generated by OMV itself, actually.


    If you don't feel secure with the options just switch to SFTP (SSH) using public/private keys, for users just add them to the ssh group. Tutorials can be found in the guide section for SSH and SFTP


    No no, that's ok. I have faith in that security mechanism (if I should).


    About SFTP, I tried that; but if I attempt to chroot an specific user, that user won't be able to connect. I don't know why. Futhermore, being honest, here I "manually" edited the sshd.conf file. No idea if it's a mistake of mine, or if is the version of the OpenSSH.

    • Offizieller Beitrag

    There is a chroot guide for sftp in the guides section. Is not easy, but should work as expected. of course ftp is much more easy with the omv web panel.


    also know is possible to have ssl certificates for free if you have a domain (which you can find for 6 dollars sometimes). Letsencrypt can issue certs that are trusted and you have green padlock icon in your browser. Should also work for ftps.

  • There is a chroot guide for sftp in the guides section. Is not easy, but should work as expected


    I will post a question in that thread then.


    also know is possible to have ssl certificates for free if you have a domain


    I guess with sub-domains won't work (?). For remote access, I will use a free DDNS service, and a free DDNS uses sub-domains, not a "high level domain" (sorry if I'm not explained myself in this part).


    If not, no problem. The idea is to protect, from malicious people in the world wide web (aka internet), the privacy of the users while they upload/download files.

    • Offizieller Beitrag

    guess with sub-domains won't work (?). For remote access, I will use a free DDNS service, and a free DDNS uses sub-domains, not a "high level domain" (sorry if I'm not explained myself in this part).


    yes, the tld has to authorized the subdomain. Most of these free domains services won't allow it. You can ask in the letsencrypt thread if someone has succeeded with a free service


    If not, no problem. The idea is to protect, from malicious people in the world wide web (aka internet), the privacy of the users while they upload/download files.


    You have the wrong concept about but SSL/TLS it will protect the transport (and ensure there is no MITM), but that doesn't prevent people sitting on other side trying usernames and passwords all day, and they usually have it automated. For me i don't leave open logins at the wan side, is either SSH or FTP over VPN.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!