SlrG

It is not enough to have the DefaultRoot directive on unRAID. You need to define ftp users in the unRAID user management. Please add the keyword ftpuser followed by a space and the path you want to restrict the created user to, into the comment field. e.g.: ftpuser /mnt/cache/FTP/user1 Afterwards make sure to restart proftpd. The given path must exist, or it won't work. Please read the first post of the plugin support thread and the readme file.

It should be possible. I'll have a look at it once I get some freetime. But please be patient, it will take time.

Yes. FTP is unencrypted by default. It's an old protocol and not very secure. If you search this thread you can find some tips to enable sftp or tls encryption. Both are not very easy to setup and might work or don't work depending on various factors. While I experimented with both methods, I'm still running unencrypted and I had not yet a problem, but thats a decision I made for myself.

Sadly I don't know what is going wrong. You should only try to connect to the main active port however. The passive ports will be used automatically by the server if needed. As user simpic reported above he also got it working correctly if he used the default port 21. Any other port did not work. I don't know if you want other users to have access to your server. If not and it is for yourself only, then I would recommend creating a vpn to your network instead and use that to connect to your server "locally".

Maybe these older posts will be helpful.

It might be, you need to define a passive port range in your proftpd.conf and forward those ports on your router to your unRAID too. Also it might be necessary to set a MasqueradeAddress and it could be helpful to change the SyslogLevel and DebugLevel to get more logging information on the error when connecting.

@FreeMan It doesn't look like a password what would cause problems. As I am from Germany, the only thing that could go wrong IMHO, would be if the letters y and z got somehow mixed up, as they are on our keyboards compared to US or British ones. But it should not happen normally. Creating an user me with your given password on my system works perfectly fine and access is working, too. I really don't know what is going wrong for you. A note on security. Please don't make the FTP available on a public network. Default FTP connections are unencrypted and very insecure. It is better to access your home network via VPN and only then use FTP for file transfers. If you really need to do it without VPN make sure your external port is not the default 21, as that will make you a target for possibly fraudulent login attempts very quickly.

@FreeMan Normally, if you didn't change anything in the proftpd.conf incorrect tries will not get you banned. If a short pass doesn't work, this is rather mysterious, as it clearly says incorrect password in your log. If you did change something, please post your changed proftpd.conf. If not, I'm somewhat out of ideas. Do you have enabled some kind of encryption in FileZille? Default FTP access is unencrypted, but it should not matter within your private network.

Try with a simple password for testing purposes. Maybe a special char breaks the login? Make sure you have restarted proftpd after changing anything user/config related. If it still does not work, check your syslog for ftp related messages. Maybe it will give more/another info, that helps solving the problem.

@halfelite As @itimpi already describes, that won't work. The lines in the mountscript each have two parts. Part one creates a directory and part two sets this directory to be a direct link to another one on your array. So if you create a directory /mnt/cache/FTP/Read/Movies and tell unRAID this is a link to /mnt/user0/Movies, you can't tell unRAID that the same directory should also link to /mnt/user/Movies, like you are doing in the read/write part of your mountscript. If you change your read/write part to look like this: #Read Write to cache folder for mover to handle later mkdir /mnt/cache/FTP/Write/Movies;mount --bind /mnt/user/Movies /mnt/cache/FTP/Write/Movies mkdir /mnt/cache/FTP/Write/TV-Shows;mount --bind /mnt/user/TV-Shows /mnt/cache/FTP/Write/TV-Shows the commands itself will probably work. But it will make no sense either, because once you write something to your write directory it should not matter if it is on the cache or the array. Why would you prevent the users using the read directory from accessing the files on the server until they are moved from cache to the array? I imagine you don't want the read directory user(s) to change/delete files. That's okay, but it works differently. See below. Also will probably not work. At least it will do nothing to make one directory read only and the other read/write. The comment field keyword ftpuser (lowercase) makes sure the user with this comment is only used as ftp user and not able to login to your server using other means like telnet or ssh. If an additional path is given, the user will only have access to this given path and directories mounted into it. But it will always be read/write access. If you want to limit it further, your will have to do so in the proftpd.conf file. What I think you want to do: Create a new user "readuser" and put "ftpuser /mnt/cache/FTP/" in the comment. Then in the proftpd.conf file you will have to make sure this user/directory gets only read access. Create a new user "writeuser" and put "ftpuser /mnt/cache/FTP/" in the comment. This one will have read/write access by default. The mountscript should look as follows: #Read Write to cache folder for mover to handle later mkdir /mnt/cache/FTP/Movies;mount --bind /mnt/user/Movies /mnt/cache/FTP/Movies mkdir /mnt/cache/FTP/TV-Shows;mount --bind /mnt/user/TV-Shows /mnt/cache/FTP/TV-Shows

That is an fingerprint md5 hash of a rsa key. You have to open the unRAID shell and issue the following command: ssh-keygen -E md5 -lf /etc/ssh/ssh_host_rsa_key It will show you the fingerprint md5 hash of the key stored in the file ssh_host_rsa_key. Change it if necessary to get the info it for the other keys.

@FreeMan I'm still on 6.5 on my server, so I did not notice the problems until now. Thank you for reporting. I'll have a look and try to fix it. The SSH key should be located in /etc/ssh, if the unRAID ssh key is used it is probably the file ssh_host_key.pub. If not, its probably one of the others located there.

AFAIK there is no client plugin. Most clients have a graphical interface and thus need a lot of additional packages, which would greatly increase the possibility of breaking unRAID base functionality and making the system unstable. So the only way is to use a docker one or run the client of your choice in a VM.

Well I'm not the developer of ProFTPd, I merely made it available on the unRAID platform. So I really can't answer you question. For me it is running fine, but I use it very seldom and for few and small files only. Maybe we can see something from the new debug logs. If not, I fear I can't help and you'll have to ask the ProFTPd developers themselves.

@jeffreywhunter As you don't crash without proftpd anymore it indeed seems to be a problem of proftpd in conjunction with your backup jobs. In my last post I gave you two links that will help you to increase the logging of proftpd. Maybe we will get some new information from that.

@jeffreywhunter I really want to help you solve your problem. But please do as I say and remove my proftpd plugin and see if the server still crashes. Then we will know for sure it is related to proftpd and can start digging in only that direction. Do you use ftp for other purposes as your personal backups? Because if only yourself are accessing your server, you don't need to jail users. In that case you could use unRAIDs internal ftp to keep your backup jobs running while the plugin is gone. Looking at your log and seeing it is hourly, the memory goes down, but in the last log entry before the crash it is back to 6.6 gig again. Maybe if you increase the logging interval to every 5 minutes or minute we will get a better view. Also it could be helpful to increase logging in proftpd as described here and reenable the transfer log as described here.

@jeffreywhunter The last time I tested the apache plugin it didn't start at all. I don't think it could be the cause of your problems, but I would recommend to uninstall it anyway. The plugin rmeaux suggested would probably be my recommendation for the time being. The other apache "plugins" you mentioned are probably dockers and not plugins. All of those I tested could not access the config files and didn't work for the purpose of my plugin. It makes sense from a security viewpoint, so I don't think it has changed.

@rmeaux Cool. I didn't know about this plugin yet. Thank you for posting. If I get the time I'll take a look at how it does things. Maybe I'll be able to get my the proftpd config editor working again that way. It has the benefit of syntax checking the proftpd.conf file and pointing out errors, so I was sad it stopped working.

@jeffreywhunter Normally the plugin disables the internal unRAID webserver automatically. It is reenabled, when the plugin is uninstalled. The reason is, that both use the default port 21 and proftp won't start, if the internal ftp already uses this port. Looking at your logs, the internal ftp seems to be disabled by the plugin. The fix common error plugin says the internal ftp is disabled, but ftp users are defined. Which is normal, as the proftp plugin uses them. So normally you should have no way to disable the internal unRAID webserver yourself, as the link to the settings page gets removed when my plugin is installed? If you still have both icons in your settings, its a bit odd. @rmeaux Your proftpd.conf looks fine and if you have opened the ports on the router everything should work in theory. Did you restart the proftpd server after making the change to the config? Otherwise changes will not get applied. If it still doesn't work, it might be you need to add a MasqueradeAddress, too. Either with your fixed IP or your dyndns name. The plugins config editor needs a running webserver with access rights to the config dir. All the docker ones doesn't have that and the apache plugin webserver stopped running with the latest versions and will get no update. So the functionality to edit the config from the plugins settings page is broken and I have no idea how to make it work again at the moment. It makes sense from a security point of view, however that it has been made harder to access the config files of the server.

@jeffreywhunter In this post the instructions to monitor shfs usage should be pretty clear. You create a file on your flash containing the given line and restart the array. Afterwards it will start logging shfs problems to your syslog. So if you tail that, problems should get visible, if there are any. The process to stop the logging is also described. The syslog from the diagnostics file IMHO doesn't show a reason for your crashes but again, I'm no expert in reading them. The root file system is not running full, thats good. The top info could be a bit suspicious: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24715 ftpacco+ 20 0 237632 204152 4456 R 81.2 1.3 17:11.28 proftpd 8150 root 20 0 947424 354676 764 S 6.2 2.2 45:31.78 shfs Sadly it doesn't show the exact time it was taken. If it was at the time of the crash, shfs is probably not responsible, as its memory usage is low. My plugin could be responsible as it is the top process at the time the info was saved (probably a file transfer in progress). To be fully sure it is/is not my plugin, I can only recommend again to remove it fully and see if the system still crashes or not. If it not crashes any longer, we could try to increase the logging of the plugin to get more clues what is going wrong. If it still does with the plugin removed, it would be better to post your diagnostics file to the official bug reports forum, so more people and people with more knowledge than me can have a look at your problem. If nothing is visible from the diagnostics file, the recommendation will be to start with a minimal system and expand from that. I know this isn't ideal, as it takes a lot of time while the system is not fully functional, but it is the only way to troubleshoot those problems. If a basic install without plugins, dockers and vms still crashes, it is probably some kind of hardware problem or a bug limetech needs to fix for your system. If that runs fine, you can start reinstalling things one by one. Install one plugin at a time and monitor if the system still crashes. If it is still stable, reinstall the next one. Enable docker. Monitor your system. Install the first docker. Monitor your system. Install the next. Enable VMs. ... That way you will find out, what exactly is responsible for your problems and then can contact the responsible developer to check it out.

@jeffreywhunter The diagnostics file is "old" from 0507 while the FCPsyslog_tail.txt is from 0510 when your system crashed. The newer syslog shows no real problems going on before the crash. At least it seems not to be an classical out of memory problem now, as both values are below 10%. For now, I would reset the values you changed to their original settings. Then I would monitor the shfs usage like described here and a syslog tail like you did before. If this doesn't show anything unusual you will really have to uninstall the proftpd plugin and see if the system still crashes without it.

For FTP to work, you need additional passive ports. In the local network they won't be blocked by your firewall and everything will work. From the WAN some routers allow the automatic opening of passive ports while others don't. So you might need to define a passive port range for proftp to use in the proftpd.conf and define the same range of open ports in your router. Make sure to really change the port to something other as 21, as that will get constantly scanned with malicious intent.

@jeffreywhunter Well do you really need the transfer log? It doesn't seem to be correctly configured on your system anyway, so why not disable it completely by setting it to NONE? That should stop the message from spamming your log. I can't imagine the ProFTP plugin being responsible for your lockups, but to be absolutely sure, you will have to uninstall and run some time without the plugin. If the system still crashes, there is another underlying problem. Looking at your log (but I am no expert in this and might be wrong) there seems to be a memory leak and you are running out of memory and thus the system crashes. Maybe you could follow the tips from here and check your shfs usage and try to change the disk cache ratio?

@quad It seems to be the same problem, you reported one page back. The plugins check for a working internet connection seems to be very flaky on your system. Sadly I still had not the time to look into it. You fixed it by modifying the checks else condition so it always reports yes and then installing the plg manually. This will probably work again.

How do you web? The correct way is: ftp://ip:21 The system should ask for username and password and allow you access to the folder you designated in the description of the user you created. ftp://user@ip:21 is also possible. Then, the system should only ask for your password. Using web based ftp will only allow browsing and downloads AFAIK. So you might want to take a look at dedicated FTP client programs like FileZilla, which will allow for uploads, too.