SlrG

@Cessquill I'll have to check again. Do you have a stock proftpd.conf or a modified one? Can you please pm me the content if it is the latter?

@Ruthalas Do you have access to another linux system or vm? When I did a complete wipe of the plugin on my system yesterday I had to generate new certificates too and got the same error. Then I created them not on unRAID but on another system and they worked without password. I had not the time yet to investigate further.

Hmm... Thats puzzling. I did a complete uninstall on my system with RC4 and rebooted to remove all traces and did a clean reinstall of the plugin. It works without problems on my system. Anything in the log when installing the plugin or when trying to start in the plugins settings? What do you get, when you enter this in the shell?: sudo -u root /usr/local/SlrG-Common/usr/local/sbin/proftpd -c /etc/proftpd.conf

@H2O_King89 RC4 does not back up sftp certificates in /etc/ssh/ and only restores the unraid stock certificates. If you had a sftp setup, proftpd will fail to start as these files are missing now. The stock plugin without proftpd.conf modifications should start without problems and if you restore the certificate files, a sftp setup will work again, too. If you have no backups, you will need to create new ones.

@d2dyno Today I upgraded to 6.7.0-rc3 and other that after the upgrade I had to start the proftpd daemon manually after the installation I have no problems running the proftpd plugin. On reboot it starts automatically again and everything works, including sftp and tls, which should use openssl library. What exactly does not work for you?

Do you want this to support offsite backups? If you are only within your home network sftp would not be necessary IMHO. Proftpd can be setup to support sftp however. Here is an old post I did.

You are trying to use sftp. Which is a subtype of ssh and the proftpd is not configured to handle that, as you see the sshd responding in the syslog. An example ftp client is FileZilla but pure ftp connections are unencrypted. I recommend you never directly connect your unRAID server to the internet. Use a vpn to your home network and then there should be no problem using pure ftp. If you still need an encrypted connection, there are some examples of users setting up sftp or ftp with tls in this thread. This is however not very simple to setup.

Well let's try to solve the ftp part now. What does the syslog of your unRAID and what does the FTP client say, when you try to connect? Which ftp client do you try to use? Please make sure to have a simple starting password when trying to connect. (no special chars please) There was a user, who reported problems with complicated passwords some time ago.

I would recommend to delete the user restart, make sure it is gone from the /etc/passwd file and recreate the user, then restart the plugin and check if the line looks correct now.

Please post the line of the user test1 from the file /etc/passwd. It should look like this: michael:x:1000:100:ftpuser /mnt/cache/FTP:/mnt/cache/FTP:/bin/false The fifth field, ftpuser /mnt/cache/FTP is the comment field, which on restart gets scanned and the path is put as the users home directory in the sixth field. Also the users shell is set to /bin/false, which should result in this users no longer being able to login other than using ftp. edit: It might be, that logging in using ssh is still possible. I have no tried that yet. Also all users without the keyword ftpuser will be added to the file /etc/ftpusers, which should prevent them from logging in via ftp. The jail will only work if using ftp access however. If the passwd line is correct, we will have to check further.

The user is defined correctly but did you really restart proftpd (in the plugins settings) afterwards? An user defined as ftp user should have no shell and should not be able to login using telnet. The jail will only work when accessing from an ftp client.

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.