Hey there!
When I first try to start the FTP server I get this error:
When I try to start it the second time it somehow starts but TLS is not working. I get this error on login:
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) 
You've hit a bug. Will be fixed in openmediavault 5.0.9, see https://github.com/openmediava…9289fd93ea441c3e2758cdf53.
Note, i only got it running after i've enabled 'No session reuse required'. See https://stefankonarski.de/cont…te-nicht-empfangen-werden.
Oh ok! 
I thought I did something wrong.
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. 
I have to deactivate and re-activate to get the FTP server online.
Is there some reason you can not use SFTP instead?
I'm not talking about using the FTP server.
An SFTP server is already built into OMV via the SSH service.
My SSH tab doesn't say anything about a FTP server and gives me no options.
Sorry if I sound dumb but this is my very first time with Linux and OMV.
...I used SSH to connect with PuTTY and I installed OMV-Extras so SSH works at least.
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.
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
What should I look for in the syslog?
This here is the whole syslog:
Sep 20 00:00:01 Server3 rsyslogd: [origin software="rsyslogd" swVersion="8.1901.0" x-pid="1030" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
Sep 20 00:01:33 Server3 chronyd[1054]: Source 2a02:908:4b44:bbc0:e228:6dff:fe40:91ba replaced with fd00::e228:6dff:fe40:91ba
Sep 20 00:03:41 Server3 systemd[1]: /lib/systemd/system/smbd.service:9: PIDFile= references path below legacy directory /var/run/, updating /var/run/samba/smbd.pid → /run/samba/smbd.pid; please update the unit file accordingly.
Sep 20 00:03:41 Server3 systemd[1]: /lib/systemd/system/nmbd.service:9: PIDFile= references path below legacy directory /var/run/, updating /var/run/samba/nmbd.pid → /run/samba/nmbd.pid; please update the unit file accordingly.
Sep 20 00:03:41 Server3 systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly.
Sep 20 00:03:41 Server3 proftpd[11908]: 127.0.1.1 - ProFTPD 1.3.6 (stable) (built Tue Jul 23 2019 18:20:14 UTC) standalone mode STARTUP
Sep 20 00:08:43 Server3 postfix/postdrop[11957]: warning: unable to look up public/pickup: No such file or directory
I attached the omv-salt as .txt because is was over 10000
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.
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. The time it takes to boot is basicly instant. I don't think that the LAN chip can get a connection that fast.
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. 
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 .
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: 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
Thanks
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. 
Don’t have an account yet? Register yourself now and be a part of our community!
