SlrG

@Karatekid Sadly no. You could try to enable debug logging in your /etc/proftpd.conf file, by adding: DebugLevel 10 Afterwards restart the ProFTPd server in the plugins settings and after trying duplicati again, check your syslog if it contains something more useful info on why it breaks.

@KoNeko Yes, only the white theme is supported currently. As the plugins settings are very much setup and forget and you have it running locally already, there is nothing in the plugins settings, you could change to make external connections work. The restart button is probably the most needed function after initial setup and that should be readable and usable in the black theme, too. Supporting the themes is still on my TODO list, but sadly I have no time to work on it for the foreseeable future. Sorry for the inconvenience. Regarding the external connection, do you have the default proftpd.conf file or have you made changes to use encrypted ftp? If you did not, it is probably solely a firewall problem as it is working locally already. Is the pfSense firewall the only one filtering external access to your home network? Nothing on your cable router (or whatever you are using to connect)? If port 21 is available properly, it might be, that you need to define a passive port range in your proftpd.conf and allow that too, in the firewall. I have no pfSense, so I can't tell you how to do it. p.s. Don't forget to restart the proftpd service, after changing the proftpd.conf, or the change will have no immediate effect.

@kricker It won't really help you, if I say it works for me, but maybe I can describe my setup a bit. I have a ssd drive outside my array which is mounted to /mnt/appdrive in my go file. So I'm not using unassigned devices, though I have that installed, too. I have it this way a long time, as it was the only way as the plugin did not exist then - but I don't think it matters in what way the disk is mounted - though the time of the mount could matter. I did not investigate if the go file or the plugin will mount earlier. When I put ftpuser /mnt/appdrive as comment and restart the plugin it works fine and jails that user into the appdrive folder. What I did notice however is, that it takes quite a bit of time for the jail to take effect. So maybe give it a minute after putting the comment and restarting the plugin and give it another minute, before trying to login.

@jareth I have no answer yet. I don't use sftp or ssl myself and need to setup it again, to test. Sadly my personal life is very busy at the moment. @jeffreywhunter If I would try at the moment, I would probably go with wireguard. I was using OpenVPN for a while. Other than that, I don't really know other solutions. @kricker This should be possible. Either define your user with ftpuser in description only, so it won't get jailed and has access to all unRAID, or use the mountscript to mount your outside disk into an folder your user can access.

@Gee1 <Directory /mnt/cache/FTP/test> <Limit WRITE> DenyAll </Limit> </Directory> <Directory /mnt/cache/FTP/test/movies> <Limit WRITE> AllowAll </Limit> </Directory> <Directory /mnt/cache/FTP/test/sf> <Limit WRITE> AllowAll </Limit> </Directory> Should give your users readonly access to the test directory and full access to movies and sf. Sadly I found no way to allow access to all subfolders. In theory there is the /* wildcard described in the link I gave you, but it does work too well and allows access in the root folder, too. @Squazz Using the first directory section only, will give you users readonly access and prevent them from writing. EDIT: Forgot to say, this needs to be put into your /etc/proftpd.conf.

@Squazz Don't mix Samba access rights you define in the unRAID web frontend with ftp access rights. Those need to be set independently. See the link I gave Gee1 above.

@Gee1 You can do this by defining directory clauses and limits within. Its also possible to allow or deny certain users. Read here.

@Gee1 Setting to cache only should be the solution. I have it setup this way myself. I just got the time to go online and post, sadly it already created trouble. But I'm glad you found the solution yourself. I hope you can successfully restore the corrupted data.

@Gee1 I'm sorry, I didn't know it was not free. 😱 I found it in the list of other FTP clients and saw a screenshot, of its statistics page and gui, which looked rather nice, so I thought it could be better. I'll try to release a new version which will hopefully fix ftptop. I'm curious how its output will look like, it will take me some days however.

@Gee1 If you enable the TransferLog in the /etc/proftpd.conf you should get a log file, which user logs in when and what and how much is transferred. In theory, I never did this myself, you can load that into Webalizer and get an aggregated report. Also there are the commands ftpcount, ftpwho, ftptop in /usr/local/SlrG-Common/usr/local/bin, though they give only realtime information and the ftptop command is broken, as I seem to have not included the ncurses development libraries when compiling ProFTPd for unRAID. I'm getting the feeling ProFTPd is not the right tool to suit your needs. While it is quite powerful it is also not very user friendly and hard to manage. I developed the plugin, when no other solution was available and integrated it into unRAIDs user management. I had and have not much need for "fancy" stuff like different access rights, many users, encryption and statistics. I understand it perfectly however, if one wants more. Maybe the CrushFTP9 docker from Community Applications would be better?

@Gee1 Well, its maybe not straightforward, but possible. Following the info given here one needs to use the tool ftpasswd to generate the AuthUserFile. This tool is located in /usr/local/SlrG-Common/usr/local/bin, so you need to cd into that path and run it. As it is a perl script, it will fail if you have no perl installed (default unRAID). To get it you will need to install the nerdpack plugin using APPS (Community Applications). After it is installed, go to its settings, search and enable the perl package. Afterwards ftpasswd will run. The usage is described here. This command will create a ftpd.passwd file. ftpasswd --passwd --name vu1 --home /mnt/cache/FTP/vu1 --shell /bin/false --uid 1005 vu1 is the placeholder username I choose and I used it to define the home directory of that user, too. Setting the shell to /bin/false should prevent this user from logging in using the shell and for the uid make sure this is not already existing and used on your system. I omitted defining a group id gid, so it will be set to be the same as the uid. Create the second user using the same command, too, but change those placeholders and uid. Now you move the ftpd.passwd file to the folder /boot/config/plugins/ProFTPd on the flash, so it will survive reboots of the system and add the following line to the /etc/proftpd.conf file. AuthUserFile /boot/config/plugins/ProFTPd/ftpd.passwd Afterwards you will have to restart the ProFTPd service in the plugins settings, to enable the change. Now your new user(s) should be able to ftp into their home directory. To mount content (one or more folders from other locations) to the homedirs use the the mountscript.sh and unmountscript.sh in /boot/config/plugins/ProFTPd/. Example commands how to use them are given in the comment headers of those files.

AFAIK there is no good web based control center for ProFTPd that does what you want. If you know one, please let me know. That would be the only way that could make it work in conjunction with this plugin. Using one of the graphical ones, would require a large number of packages, that are not supplied by a stock unRAID. As this is a plugin and directly integrated, each new package increases the risk of breaking something in the unRAID base functionality or adding unwanted vulnerabilities. So this is no solution I would be willing to implement. In your case I would recommend setting up a VM where you can install whatever you want, without the risk of damaging the base system. Or maybe there are docker containers, with your needed functionality. The CrushFTP one available under Apps looks promising - I did not test it though.

That's cool. Thank you very much for testing. I'll try to modify the patch to hopefully fix the overflows. Even if they are only graphical in nature, they could potentially unsettle people and need to be gone. I hope I'll able to fix them. It will take some time however.

Well, it might be hasty, but better save, then sorry. Until we know it does not damage data and how and if it can be changed to prevent this if it does, I wan't to minimize any risk as much as possible.

Sadly not with files that large. I guess it's better to withdraw the plugin then. I hope it did not corrupt files for you. Thank you for reporting the problem.

@JaY_III Thank you for posting an interim solution and notifying me of the problem and the underlying cause as well. 👍 As I use no mount/unmount scripts myself, I would not have noticed the problem otherwise. 😳 I released a new version of the plugin, that should fix the problem without having to depend on the user scripts plugin. Please test the new version and report any problems.

@danktankk Maybe I misunderstood. I thought you had a share /mnt/user/nextclound, where your nextcloud data is located. Now you want to upload to that folder but have it using the cache, as that is faster and having the mover moving the files in the night to the share. If you upload to /mnt/cache/nextcloud all files will be uploaded to the cache drive utilising its higher speed. In the night the mover will move the files to /mnt/user/nextcloud automatically. No need to move it yourself. The only problem is probably if you have subfolders in your share and want to upload your files to them. The mover will probably move the folders as well as the files so one would have to recreate them each time. I did not test this however.

@danktankk Sorry for the late reply. See above for the reason. What @itimpi told you should work in theory. I don't know, why I isn't. Might be it works only for samba connections and not ftp. What you can try however is to write directly to /mnt/cache/yourfolder which should place the files on the cache and they will be copied to the array by the mover. So if you want to read them after they are moved, you will have to use /mnt/user/yourfolder again.

@fatmaddin2000 Sorry for the late reply. Notifications did not work. It seems the naming of the file /etc/ssl/openssl.cfg has changed back to the default /etc/ssl/openssl.cnf. So the command is now: openssl req -new -x509 -config /etc/ssl/openssl.cnf -days 3650 -nodes -out /boot/config/plugins/proftpd/ssl/ftp.cert.pem -keyout /boot/config/plugins/proftpd/ssl/ftp.key.pem

@Kristijan Sorry for the late reply. Somehow I got no notification of the latest posts even though I have notifications enabled for this thread. I can't replicate your problem, as I am not able to enter "" in the comments field, unraid asks me to "Please match the requested format.", so I don't really know, what was going wrong for you. You can check the contents of /etc/shadow, which is the file that contains your unRAID users. A stock shadow file should probably look like this: root::17990:0:99999:7::: bin::14824:0:99999:7::: daemon::14824:0:99999:7::: adm::14824:0:99999:7::: lp::14824:0:99999:7::: mail::14824:0:99999:7::: news::14824:0:99999:7::: uucp::14824:0:99999:7::: ftp::14824:0:99999:7::: smmsp::14824:0:99999:7::: mysql::14824:0:99999:7::: rpc::14824:0:99999:7::: sshd::14824:0:99999:7::: oprofile::14824:0:99999:7::: usbmux::14824:0:99999:7::: sddm::14824:0:99999:7::: pulse::14824:0:99999:7::: avahi:!:14980:0:99999:7::: avahi-autoipd:!:14980:0:99999:7::: messagebus:!:14980:0:99999:7::: pop::14824:0:99999:7::: haldaemon::14824:0:99999:7::: polkitd::14824:0:99999:7::: nobody::14824:0:99999:7::: tss:!:17825:::::: Though I am not sure, you will have the same "numbers". If the file looks alright, to you, a reboot will probably fix your problem.

@jenga201 In theory this is of course possible. But It might be necessary to add a new dependency on the openldap package which is not default on unRAID. Sadly I don't have the time at the moment to check out possible negative side affects. The plugin is heavily integrated info the unRAID user management and intended to use only that. For a more ambitious setup it is better and far easier to setup a VM with a more flexible linux distro than unRAIDs Slackware. Within debian and ubuntu for example there are addon packages for proftpd with ldap that can be installed without compiling. Pointing to the shares on your unRAID for data storage should give you what you want without possible adverse effects.

Its a bit hard for me to understand, as I am not a native English speaker. How are the upload folders created? Through the shell console or through the ftp client? As they are both user, group and world writeable, there should be no problems uploading to both of them in theory. Can you give me the full paths of both users DCIM folders on your array? What is the error message, when trying to upload to the nobody users DCIM? Which ftp client do you use? Please try with FileZilla if it works and only then try another client. I'm guessing from your description you are trying to upload not a file, but a folder with 10000+ files within it. I have never tried to upload such a large number of files. I can only recommend trying with a single or a few files first and expanding from that. Also please enable debug logging as described in the link above, to maybe get more information on what is going wrong.

The functionality to edit the proftpd.conf file from the plugins settings page is sadly currently broken. You have to open a shell window and use nano (or any other editor of your choice) to edit /etc/proftpd.conf. If you have your log files on the flash, like your config file suggests, the server will propably run into problems and not start, as the file system of the flash doesn't support access rights and is therefore deemed insecure by proftpd. If you don't want to log into the syslog, I recommend to create a folder on the array to host the log files and set the correct access rights for that. (not world writeable) Make sure you can access the ftp by a normal client (e.g. FileZilla) first before trying more advanced stuff like trying to run some backup software. It might be necessary to enable Debug Logging, to maybe get more information on the problem. See here.

Something like this would have been my guess. It's great you found the cause of the problem yourself. And no, I don't think you should worry. 😉