FTP won't start/buggy start

  • Hey there!


    When I first try to start the FTP server I get this error:

    Code
    Fehler #0:
    OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; omv-salt deploy run proftpd 2>&1' with exit code '1': debian:
    ----------


    When I try to start it the second time it somehow starts but TLS is not working. I get this error on login:

    Code
    Status: Verbinde mit xxx.xxx.xxx.xxx:xxxxx...
    Status: Verbindung hergestellt, warte auf Willkommensnachricht...
    Antwort: 220 ProFTPD Server ready.
    Befehl: AUTH TLS
    Antwort: 500 AUTH not understood
    Befehl: AUTH SSL
    Antwort: 500 AUTH not understood
    Fehler: Kritischer Fehler: Herstellen der Verbindung zum Server fehlgeschlagen


    Also the FTP server doesn't start on it's own when I reboot OMV. The "running" dot stays red in the system info tab.
    The server is running 5.0.8-1 with all updates.


    Need help! Complete linux noob here.(first time ever) :/

  • Just installed the new version.


    TLS works now but the server still doesn't start on it's own.
    When I start it by hand it still gives me the same error on the first try. On the second try it starts.


    After OMV reboot the red button is still there in the dashboard and I can't connect. :huh: I have to deactivate and re-activate to get the FTP server online.

  • I'm not talking about using the FTP server.


    An SFTP server is already built into OMV via the SSH service.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Well, you aren't going to see anything about it in the SSH tab.


    You can configure SFTP by hand in the SSH tab under Extra options, this is how I do it, but it takes some experience or to be willing to learn this.


    Since the SFTP server is running automatically by default, you can connect to it using login credentials for any user on the system without doing any configuration in Extra options. This would allow you to navigate the entire filesystem, but not be able to read or write to large areas of it unless connecting as the root user - bad idea unless you have very good reasons and you know what you are doing.


    Or you can use the SFTP plugin, but that will still require some knowledge of what it is you are doing and it will restrict access to a specific shared folder only. I don't use this feature myself.


    It all depends on what you really want to do with this.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • I use the FTP server to share data with all my friends so I need to be able to set permissions for each user differently. I need to control bandwidth usage as well.


    When I can find a tutorial about that SFTP on SSH I give it a try and see if I can make that work. The last 16 years I only run Windows servers so all this linux console stuff is quite hard to learn. ^^

  • When I start it by hand it still gives me the same error on the first try. On the second try it starts.

    Can not reproduce this. Can you provide more information, e.g. syslog output or something else that might help to identify the problem.


    Can you please post the whole output of the command


    Bash
    # omv-salt deploy run proftpd
  • What should I look for in the syslog?
    This here is the whole syslog:

    I attached the omv-salt as .txt because is was over 10000 :D

  • Looks like there is issues at reboot, proftpd doesn't ship with a systemd unit, uses legacy init script so sometimes it might fail due to network not available. The approach upstream seems to be use activation on demand systemd socket.


    http://bugs.proftpd.org/show_bug.cgi?id=3661


    Debian is aware https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740177 that the packaging should ship with systemd unit


    Shipping with a custom systemd unit for standalone server won't work apparently(didn't for me) due to this https://github.com/proftpd/proftpd/issues/501 which says was backported to 1.3.6 but just to the tag in github but not released as tarball so doesn't make it to debian yet.


    I can reproduce the issue sometimes, not 100% sure.


    @TheBadFrag


    Can you test if installing inetd fixes the boot problem


    apt-get install inetutils-inetd


    Then reboot

  • Maybe it's because I installed OMV on a NVME SSD. :D The time it takes to boot is basicly instant. I don't think that the LAN chip can get a connection that fast. :huh:


    I can test that inetutils-inetd install tomorrow when I get back home. I don't want to mess up the server when I have no physical access to it. :saint: It's currently very busy pushing data.



    ...here are that hardware specs if that maybe helps:
    Intel i3-8100
    Gigabyte C246-WU4
    2x Kingston Server Premier 8GB DDR4-2400 ECC
    Samsung SSD 970 EVO Plus 250GB, M.2
    6x Western Digital WD Red 10TB 3.5" (WD100EFAX)

  • Hello
    OMV5.0.13
    Omv-extras with docker


    At reboot, same problem , FTP not started.
    need to lauch by hand to make it work .

    Code
    Proftpd –td10
    019-11-07 11:49:29,096 omvnas.localdomain proftpd[2565] 127.0.1.1: mod_lang/1.1: added the following supported languages: fr_FR.UTF-8, fr_FR
    2019-11-07 11:49:29,096 omvnas.localdomain proftpd[2565] 127.0.1.1: ROOT PRIVS at mod_ctrls.c:1208
    2019-11-07 11:49:29,096 omvnas.localdomain proftpd[2565] 127.0.1.1: mod_ctrls/0.9.5: error: unable to bind to local socket: No such file or directory
    2019-11-07 11:49:29,096 omvnas.localdomain proftpd[2565] 127.0.1.1: RELINQUISH PRIVS at mod_ctrls.c:1210
    2019-11-07 11:49:29,096 omvnas.localdomain proftpd[2565] 127.0.1.1: ROOT PRIVS at mod_rlimit.c:555
    2019-11-07 11:49:29,097 omvnas.localdomain proftpd[2565] 127.0.1.1: RELINQUISH PRIVS at mod_rlimit.c:558
    2019-11-07 11:49:29,097 omvnas.localdomain proftpd[2565] 127.0.1.1: set core resource limits for daemon



    Code
    root@omvnas:~# systemctl status proftpd
    ● proftpd.service - LSB: Starts ProFTPD daemon
    Loaded: loaded (/etc/init.d/proftpd; generated)
    Active: inactive (dead)

    Thanks


    Code
    systemctl restart proftpd.service
    Job for proftpd.service failed because the control process exited with error code.
    See "systemctl status proftpd.service" and "journalctl -xe" for details
  • I'm having the same exact problem.
    So the issue is reported on debian bug tracker since 2014 and still not fixed to this day?
    Can't we just delay this script that starts proftpd so it waits until the network connection is fully established?


    this is probably a hacky workaround that might not even work but I'll try to add a sleep 5 to the beginning of the script in /etc/init.d/proftpd


    update: didn't work.

  • It would be interesting if this is a hardware or software related bug. I wonder why it works for some users and not for others.


    It's pretty annoying too that the server can't do reboots without a babysitter.


    A workaround would be that the FTP gets shut down and restarted 1 minute after a boot/reboot happend. But I don't know how to do that, I'm not a programmer. :/ In Windows I would use a batch script and put it into autostart but thats not going to happen with Linux. X/

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!