SlrG

@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.

@jeffreywhunter The path to the webserver needs to be a full path. I have /mnt/cache/Web. The plugin will copy the files of the config editor to a ProFTPd directory there. You need a webserver running on your unraid which serves files from that directory, or it won't work. You should be able to connect to the config editor by typing http://x.x.x.x:8088/ProFTPd/ConfEdit.php into your browsers url field. x.x.x.x should be the ip of your unraid server. Also the port 8088 needs to be the port the webserver is listening on. @StevenHB Please contact me again via PM. The forum upgrade seems to have killed you message in my inbox? I don't think the error messages you listed are related to this plugin. Please enable the TransferLog and check the output you get in this when trying to connect.

I just gave it a try on my 6.3.1 system. In both Chrome and Firefox it does work for me. What browser are you using?

Sorry for the late reply. Somehow I got no notifaction of your message. Sadly the log is not very telling. Did you try to remove the plugin completely and reinstall it again?

I know that feeling from some of my development projects. It works fine now. Thank you very much for the fix! It is a great plugin.

crontab -l shows: # If you don't want the output of a cron job mailed to you, you have to direct # any output to /dev/null. We'll do this here since these jobs should run # properly on a newly installed system. If a script fails, run-parts will # mail a notice to root. # # Run the hourly, daily, weekly, and monthly cron jobs. # Jobs that need different timing may be entered into the crontab as before, # but most really don't need greater granularity than this. If the exact # times of the hourly, daily, weekly, and monthly cron jobs do not suit your # needs, feel free to adjust them. # # Run hourly cron jobs at 47 minutes after the hour: 47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null # # Run daily cron jobs at 4:40 every day: 40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null # # Run weekly cron jobs at 4:30 on the first day of the week: 30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null # # Run monthly cron jobs at 4:20 on the first day of the month: 20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Anime" &>/dev/null 2>&1 /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Filme" &>/dev/null 2>&1 /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/FilmeMarco" &>/dev/null 2>&1 /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Multimedia" &>/dev/null 2>&1 /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/SecDrive" &>/dev/null 2>&1 The share verification shedules are set to never. If I change them to run again, the errors vanish. If I disable them (set them to never) the jobs seem to get added to the crontab without times instead of removing them completely. This causes the cron errors in the log. For now I'll manually remove them via crontab -e. This needs to be done after every reboot however. It would be cool if you can fix this in a future version. Take your time. I know you are not actively developing this anymore.

@Squid: Thank you very much for developing this great plugin. I'm still using it to get the corz compatible hash files directly without having to copy them every time I export from bonienls plug. I have little problem though: Nov 27 18:44:03 lafiel crond[1564]: failed parsing crontab for user root: /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Anime" &>/dev/null 2>&1 Nov 27 18:44:03 lafiel crond[1564]: failed parsing crontab for user root: /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Filme" &>/dev/null 2>&1 Nov 27 18:44:03 lafiel crond[1564]: failed parsing crontab for user root: /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/Multimedia" &>/dev/null 2>&1 Nov 27 18:44:03 lafiel crond[1564]: failed parsing crontab for user root: /usr/local/emhttp/plugins/checksum/scripts/verifyShare.php "/mnt/user/SecDrive" &>/dev/null 2>&1 I get this error messages in my log. And they seem to be related to this plugin. Is there any way to remove them? cheers Slrg

Cool. Thank you very much for sharing. I think this will be helpful for a lot of users of the plugin.

I agree this would propably be a good idea to secure the user data. But I fear it would generate a lot of support requests from users who don't know how to enable write support. I'll give it some thought however.

I never tried it myself, but I think you can do this using the <limit> directive. <Directory ~/site/backups> <Limit WRITE> DenyAll </Limit> </Directory> Adding this to your proftpd.conf will protect the given dir against all writes. If you want to protect your whole server your could add only the limit without the directory directive. It will block write access for all users however. It is possible to allow it for certain users and block it for others. Please check out the proftpd docs.

Please give the newest version of the plugin a try. It works on my system using your proftpd.conf. If not please report again.