SlrG

@jeffreywhunter Sorry for the delayed answer, I was on vacation. The first error is because the config file for proftpd is stored on your flash drive for persistence. When the unRAID server is running, it is symlinked to the config folder in your RAM but it inherits the user and access rights from the flash. As the flash uses the old MS-DOS filesystem fat32, there are no user and access rights stored and thus the error is thrown. It is a possible security risk, that anybody who has access to your flash is able to edit the config files, but that if somebody has physical access to your server there are a lot more effective ways to harm you or your data. So it can be ignored. Sadly there is no way to disable the error. For the second one, please check your ProFTPd.conf. The default logging section looks like this: # Control Logging - comment and uncomment as needed # If logging Directory is world writeable the server won't start! # If no SystemLog is defined proftpd will log to servers syslog. #SystemLog NONE #SystemLog /boot/config/plugins/ProFTPd/slog TransferLog NONE #TransferLog /boot/config/plugins/ProFTPd/xferlog WtmpLog NONE Please note the TransferLog NONE line and the # before the TransferLog /boot/config... line. The TransferLog NONE should solve your error. It won't log Transfers, but normally this is not necessary. If you want to log Transfers, it should be enough to create an empty xferlog file on the flash or different path. This should persist and will not require a go file entry. @killeriq Please read the first post and the readme. This should answer your questions. You need to configure an user to allow FTP access by editing the comments of this user in unRAIDs user management.

@geonerdist Yes, that is the reason.

@geonerdist There is someone trying to hack into your server. Mostly these are automatic scripts that someone setup, that crawl the net looking for servers on standard ports and trying known user and password combinations on them. Which port did you open on your router to forward it to your server? If you openend 21 I would ASAP change that to some other port above 49151 eg, 49221 or something. That will probably stop those login attempts. The port the proftpd server is running on, can stay 21. That does not matter. Just Forward from 49221 on the router to 21 on the server. Also make sure, you have secure usernames and passwords. No admin admin or something. If you want more security, don't open the ftp port on the router but use an vpn connection to connect to your private network from the outside and then you can access your PC's from there.

@MickMorley The bug should be fixed now. Please update the plugin and delete the ProFTPd folder from your web server directory. Then restart the service and the fixed editor should be saved into your web server directory. Thank you very much for finding and reporting this bug.

Okay. Thank you for the information. I'll try to fix the error and release a new version soon. It will still not work with the docker apache versions however, as I don't know how I could possibly fix that.

@MickMorley I tried to use the docker apache when it was made available and I failed, too. I'm using the plugin version now and that works fine. I believe the reason why the dockers fail is, because they block access to files outside of the defined web folder for valid security reasons. Sadly this is something the config editor needs to work, as the proftpd.conf is in /etc/ on your unRAID. If you don't want to use the apache plugin instead, please disable the config editor. You don't really need it. You can always use nano in a console to edit the proftpd.conf or use winscp if you like a more graphical editor. Don't forget to restart the service afterwards for the changes to get applied. On a side note, you seem to be using an older version of my the proftpd plugin. The config editor has been renamed from proftpdce.php to ConfEdit.php. You should not get the old name with the newest version. If you are using the newest please tell me, I'll have to recheck the source code, then to make sure I did not miss some old reference in there.

In newer versions of unRAID, the integrated FTP server is disabled by default, while the plugin expects it to be enabled. The installation doesn't work correctly and the plugin fails to work, too. Please remove the plugin, enable unRAIDs integrated FTP and then reinstall the plugin. I was not yet able to fix this bug, but I will in the future. For now this should get you going as a workaround.

I'm glad the unRAID part works fine. Sadly I have no idea regarding WHMEasyBackup, as I have never used this.

To enable sftp: open a shell on your unraid server and issue the following commands cd /etc/ssh ssh-keygen Enter the name of the keyfile (sftp_rsa_key) and no passphrase. You will get two files sftp_rsa_key and sftp_rsa_key.pub. The public key needs to be converted to another format to make it usable by proftpd: ssh-keygen -e -f sftp_rsa_key.pub | sudo tee sftp_user_keys You will get a new file sftp_user_keys. Now the owner and permissions will need to be changed: chown nobody:users sftp_rsa_key sftp_rsa_key.pub sftp_user_keys chmod 600 sftp_rsa_key sftp_rsa_key.pub sftp_user_keys Now to make your system restore the correct permissions of this keys on boot you will need to modify the mountscript: nano /boot/config/plugins/ProFTPd/mountscript.sh Insert the following lines: chown nobody:users /etc/ssh/sftp_rsa_key /etc/ssh/sftp_rsa_key.pub /etc/ssh/sftp_user_keys chmod 600 /etc/ssh/sftp_rsa_key /etc/ssh/sftp_rsa_key.pub /etc/ssh/sftp_user_keys Now edit your proftpd.conf file and insert: <IfModule mod_sftp.c> SFTPEngine on Port 2222 SFTPLog /var/log/sftp.log SFTPHostKey /etc/ssh/sftp_rsa_key SFTPAuthorizedUserKeys file:/etc/ssh/sftp_user_keys SFTPAuthMethods publickey SFTPKeyBlacklist none SFTPDHParamFile /usr/local/SlrG-Common/usr/local/etc/dhparams.pem </IfModule> Don't forget to restart the proftpd server to enable the changes. You need to copy the sftp_rsa_key and take it with you, to access your server. If you are using FileZilla to connect, the file needs to be converted to a usable format and stored in FileZillas settings.

@mcleanap: It depends. On what you want. I found it would work using FileZilla when connecting from external sources. And it worked using FireFTP using internal ones. So using different clients for different access types could be a solution. Also you could set TLSRequired to off and then you will be able to connect without TLS internally, which should be much less a security risk. Also I would recommend setting up a vpn connection to your private network and use ftp within that to connect to the server and not make the ftp server freely accessible from the net. That depends on what you want to do however. Also the sftp connection is still possible. I was able to get it to work using the tips I gave you above. But I only tested it internally for now. I did not have the time to test it externally, too.

@mcleanap: The proftpd server is running as user nobody with the group users for security reasons. The ssh files you are trying to access are on the flash drive /boot/config/ssh/ where they are group and world accessible (fat filesystem), so proftpd will not use them for security reasons. If you use the files from /etc/ssh/, they belong to the user root. So proftpd running as nobody can't access them. Changing the owner of the files to nobody or changing the user the proftpd server is running as, is not advisable. Also on my system there is no /boot/config/authorized_keys file. Do you really have it on yours? Compression doesn't seem to work, as unraid is missing zlib, so you need to remove that commands for now. That is what I read from the warnings and errors proftpd gives, when testing the config like described above and by looking at the paths, ownership and permissions of the files. Sadly I'm running out of time for now, so just some quick tips: You will probably have to research how to generate your own keys to use for the sftp connection. If you put them on the flash in /boot/config/ssh they will be copied to /etc/ssh automatically, when the server restarts. But they will have the wrong ownership and/or permissions, which you will have to correct with chown and chmod when the server starts. To do it automatically, you can add the commands to the mountscript in the proftpd plugins directory on the flash.

@all: When trying things like encryption or other config changes, it essential to let proftpd check the config and report if there are problems. That helps a lot with troubleshooting. From the shell you can do it by giving the following command: /usr/local/SlrG-Common/usr/local/sbin# proftpd -t -c /etc/proftpd.conf Where -t means test and -c is the path to the config file you want to test. Under normal circumstances you will get one error and one warning: Checking syntax of configuration file 2017-05-04 09:56:13,359 lafiel proftpd[17595]: mod_ctrls/0.9.5: error: unable to bind to local socket: Address already in use 2017-05-04 09:56:13,361 lafiel proftpd[17595]: warning: config file '/etc/proftpd.conf' is world-writable Syntax check complete. The error usally means you have proftpd already running and thus the port is in use. Or you have another ftp server or process using the port, which means proftpd can't start and you have to fix it. The warning is because the config is saved on the flash drive to preserve it when rebooting and symlinked to the config dir. Sadly the flash has a fat filesystem, which is not able to store file ownership and permissions, like linux filesystems do. It normally is no problem and can be ignored. If you have setup a webserver to use the plugins config editor, it will do the above steps for you and show you if there are errors or warnings. If there are other errors or warnings, you will probably have an problem and what you are trying will fail until you correct it. Please search online for solutions. I'm in no way a proftpd expert and have to do the same thing, which takes a lot of my time.

@bonienl I'm having problems with the S3 sleep plugin. It does sleep the server, but it does not recognize the correct spindown state of the drives. It often happens, that the system goes to sleep, even if there are still disks that are not spun down. See here: Apr 18 20:39:46 lafiel s3_sleep: Extra delay period running: 33 minute(s) Apr 18 20:40:46 lafiel s3_sleep: All monitored HDDs are spun down Apr 18 20:40:46 lafiel s3_sleep: Extra delay period running: 32 minute(s) Apr 18 20:41:26 lafiel kernel: mdcmd (121): spindown 0 Apr 18 20:41:27 lafiel kernel: mdcmd (122): spindown 2 Apr 18 20:41:46 lafiel s3_sleep: All monitored HDDs are spun down Apr 18 20:41:46 lafiel s3_sleep: Extra delay period running: 31 minute(s) Apr 18 20:42:46 lafiel s3_sleep: All monitored HDDs are spun down I've also attached my diagnostics file with the full log. Its easy to see, the plugin thinks all disks are spun down, while 0 and 2 were still running and spun down later by the system. It was once working, then it stopped and needed a fix, where the user would need to add a command to spinup all disks on wakeup from sleep. Now it does not work any more even doing this. Is there a known solution or is the reason known, why it doesn't work? Is there anything I can do, to make it work again? lafiel-diagnostics-20170418-2031.zip

@dannygonzalez0861 Thank you for the confirmation of the problem. I'll have to take a look and probably change the disabling of the internal ftp. That seems to break everything if it is already disabled, as happens to be the default for the newest unraid version but was not on older ones. cheers SlrG

WTF. Now all of a sudden it stopped working for me, too. I'm not able to connect internally with FileZilla and TLS enabled. Externally with TLS works fine. And now the weird thing. Trying with FireFTP and TLS works internally but not externally. Sadly the logs don't show anything helpful. # Server Settings ServerName ProFTPd ServerType standalone DefaultServer on PidFile /var/run/ProFTPd/ProFTPd.pid # Port 21 is the standard FTP port. You propably should not connect to the # internet with this port. Make your router forward another port to # this one instead. Port 21 # Set the user and group under which the server will run. User nobody Group users # Prevent DoS attacks MaxInstances 30 # Speedup Login UseReverseDNS off IdentLookups off # Control Logging - comment and uncomment as needed # If logging Directory is world writeable the server won't start! # If no SystemLog is defined proftpd will log to servers syslog. #SystemLog NONE #SystemLog /boot/config/plugins/ProFTPd/slog TransferLog NONE #TransferLog /boot/config/plugins/ProFTPd/xferlog WtmpLog NONE # As a security precaution prevent root and other users in # /etc/ftpuser from accessing the FTP server. UseFtpUsers on RootLogin off # Umask 022 is a good standard umask to prevent new dirs and files # from being group and world writable. Umask 022 # "Jail" FTP-Users into their home directory. (chroot) # The root directory has to be set in the description field # when defining an user: # ftpuser /mnt/cache/FTP # See README for more information. DefaultRoot ~ # Shell has to be set when defining an user. As a security precaution # it is set to "/bin/false" as FTP-Users should not have shell access. # This setting makes proftpd accept invalid shells. RequireValidShell no # Normally, we want files to be overwriteable. AllowOverwrite on <Directory /mnt/cache/FTP> UserOwner nobody GroupOwner users Umask 000 </Directory> <IfModule mod_tls.c> TLSEngine on TLSLog /var/log/proftpd-tls.log TLSProtocol SSLv3 TLSv1 TLSOptions NoSessionReuseRequired TLSRSACertificateFile /boot/config/plugins/ProFTPd/proftpd.cert.pem TLSRSACertificateKeyFile /boot/config/plugins/ProFTPd/proftpd.key.pem TLSVerifyClient off TLSRequired on TLSMasqueradeAddress xxx.ddns.net </IfModule> PassivePorts 60000 60100

Yes. TLS works internally and externally. These are the changes in my proftpd.conf: <IfModule mod_tls.c> TLSEngine on TLSLog /var/log/proftpd/tls.log TLSProtocol SSLv3 TLSv1 TLSOptions NoSessionReuseRequired TLSRSACertificateFile /boot/config/plugins/ProFTPd/proftpd.cert.pem TLSRSACertificateKeyFile /boot/config/plugins/ProFTPd/proftpd.key.pem TLSVerifyClient off TLSRequired on TLSMasqueradeAddress xxx.ddns.net </IfModule> PassivePorts 60000 60100 I'm forcing TLS and SSLv3, but I think security could be improved further. Also I'm forwarding the active port (xxx on my router to 21 on the unRAID server) and the passive ports from the proftpd.conf. In FileZilla I'm using explicit TLS both internally and externally. The snippet from the tls log looks normal. So I don't really know, why it fails on your system.

Hmm... it works fine for me. What does the /var/log/proftpd.tls.log show?

I was able to reproduce your problem. It happens because you have to use TLSMasqueradeAddress mydns.duckdns.org inside the TLS rule definition and not MasqueradeAdress for your whole server. The virtual host should be obsolete and is not necessary.

To restart the server from the commandline use: /etc/rc.d/rc.ProFTPd restart Otherwise I can't help you quickly. I'll have to try and setup this myself and that will take some time.

Hmm... Are you sure you have a webserver running and setup the path to point to the webservers directory for sites? The plugin creates a folder with the config editor there. If you pointed it to your "home" folder, that could explain the ProFTPd folder in there. If you have no webserver, please disable its usage in the plugins settings. You can always edit the proftpd.conf file in an unRAID console.

@xhaloz Hmm... I just upgraded my system to unRAID 6.3.3. and the plugin still works as expected. The question is if something fails if it is installed on a new system. Do you still have the complete syslog from installing the plugin? Please upload it on a sharing service and drop me a link. If not, could you remove it completely and reboot your server and try again capturing the syslog this time?

@jeffreywhunter If you are still set on using the ftpuser, please get me the logs I asked for. Maybe they contain clues what is going wrong.

Well normally it should not, but as you had it working before and now not, it somehow still might. A quick test on my system using the user name ftpuser and comment ftpuser /mnt/user works perfectly fine. And I am using the Apache plugin, too. So I doubt thats the reason it doesn't work. Did you restart the plugin after changing the users? That is absolutely necessary to make it work.

@jeffreywhunter Please try a different name for your ftpuser. As ftpuser is the catchword I am using in the description to identify ftpusers, it might create a problem in the script that Also for testing try it without any path and only the catchword ftpuser in the description. If it still fails, please look in the syslog if there are errors when you try to log in. If not, please enable the TransferLog in the proftpd.conf and try to check that file for errors when you try to log in. This should hopefully give us clues, what is going wrong for you.

@jeffreywhunter No it won't work with unRAIDs internal webserver. As webserver I recommend the Apache Web Server Plugin as I am using this myself. I tried the available dockers first, but somehow I was not able to get it to work there. I see you posted in the plugins thread already. I recommend running as user nobody and setting the permissions and group of the web folder accordingly. Most of the files on your unRAID will have this user and group. You can use the newperms script to achieve proper settings: newperms /mnt/cache/web And a side note: You don't need the config editor to change your proftpd.conf. You can always use nano or something and edit it in an unRAID console.