SlrG

Yes. The problem is, that proftpd does not support writing logs to world writeable directories (on your flash) any longer. Please see here on how to setup a directory on your cache drive which should work.

I'm glad you liked it. Thank you. Conclusion from you description above is, you probably need no /mnt/cache/FTP directory. You could just point the home dir of the ftp user directly to /mnt/user/media and use the directory and limit rules to make it read only and prevent access to subdirs you don't want to be read at all. This should "solve" the fix common plugins error. Another way is to set the error to ignored in fix common problems. As for the cache running full, this is probably, because the mover runs on a shedule and not if the disk space gets low. If you have other questions, please let me know.

@soder Okay. Sorry. I was guessing wrong based on the ö in Söder. Lets forget the plugin and binding directories to the ftp side on the cache for a moment. Let's just look on the unRAID side. The question is, what do you expect from your media share. Security or speed. If you create it normally, it will not use the cache drive and reside only on the array. That has the advantage, that every file you copy to your media share will be stored directly on your parity protected array. The drawback is, it is rather slow due to the parity calculations and write operations on the number of drives involved. (e.g 35 MB/sec using normal desktop grade HDDs) If you set the share to use the cache drive any new file will be copied to the cache drive first. This doesn't involve parity calculation and is rather fast. (e.g. 115 MB/sec using desktop grade HDDs or faster using a single SSD or multiple Drive cache pool) The drawback is that the file will not be parity protected until it is moved to the array by the mover (which you should enable to run or new files will never get moved to the array and thus will never be protected). The speeds depend on your drives, network, memory and cpu, so they might be slower or faster. Please don't take them as fixed values. Now we come back to the proftpd plugin. Mounting directories or shares to the FTP directory of the cache doesn't physically double the files. This is just some kind of gateway to make it possible to access the files on both locations. Files copied to /mnt/cache/FTP/media will be saved on the array, if media is a mount of /mnt/user/media and the cache is not enabled for this share. If the cache is enabled for the share the files will be saved on the cache (but in /mnt/cache/media and not in /mnt/cache/FTP/media, though they will be accessible there, too) and later on moved to the array by the mover. I admit its a bit complex. I hope I was able to shed some light on it. edit: The problems with your torrents could be, because you set the destination to be the cache (/mnt/cache/...) but the files are moved to the array by the mover vanishing on the cache. Setting the destination to /mnt/user/... should solve those problems.

@soder Maybe you would like it better to explain in german language? Please send me a pm. What exactly is the problem with torrents? And why do you think you shouldn't bind the media share to the cache?

@soder You can't use it to bind other directories into your ftp root (that should be done using the plugins mount and unmount scripts), but yes, that's the way to protect your folders. If you want to make your FTP dir read only to all users, what you have should be enough. Please also have a look at http://www.proftpd.org/docs/howto/Limit.html.

@bonienl No problem. I'm glad you are willing to investigate. Take all the time you need. If I can help in any way, please let me know.

Me too and I really like the S3Sleep feature. I don't want to give up on it. If somehow possible please make it work again. Also we need a reliable way to detect the spinup status of the disks. Spinning up all disks on wakeup is only a stopgap solution and not working reliably for me. (The disks do spinup, but the state sooner or later gets unsynched and the plugin doesn't know anymore if the disks are running or not. I know S3Sleep is not officially supported, but maybe if @bonienl asked the unRAID devs to track the spinup state in some file, that plugin autors can access and take this info from, the problem could be solved reliably. As he/you are working with them so closely, they might be willing to listen to you. I would even be willing to pitch some money on the solution of this problem. Maybe others would, too?

@satdreamer The problem seems to happen when the internet connection of the server is problematic. I had it never happen on my system, so it is hard to troubleshoot. I'll try to improve the process of checking the connection. But it will take some time. I don't have much freetime at the moment. @soder Please check the first post of this thread. There is a short explanation and a link to the readme, which contains more info on how to setup the users through the unraid user configuration interface. The settings file is on your flash drive and is named proftpd.conf. It is symlinked on boot to /etc/proftpd.conf.

Cool. Just gave it a spin and it works fine, for me too.

@gaby-one The process to enable sftp is explained here.

@Vicktork 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. If you want to enable it anyway, you need to install the Apache Web Server Plugin, too (using a docker based webserver will not work). Make sure to set the same directory and port in both plugins or the plugin won't be able to setup and access the config editor correctly.

@quad For me it runs fine. I removed the plugin on my system, rebooted and installed it again without errors. The log shows it downloads the plg fine, which is hosted on the same server (github) as the plugin control files, that fail. So it must be some hickup in your connection, or on the github servers at the time you were trying to install. Please give it another try.

@jeffreywhunter 7% for the rootfs probably means there is no problem there. Is there any other size thats critical? 16GB flash should give you plenty of room to try proftpds debug logging, maybe it gives us a clue, what is going wrong. But as your parity check has errors, it IMHO means there is a more serious problem with your server. I would try to run unRAID in safe mode, without plugins, dockers and VMs to see, if it still hangs and crashes. If it still is, you might have faulty hardware. If not, I would reenable the plugins, dockers and VMs one by one to hopefully identify the culprit.

@jeffreywhunter I had it happen to me, that if the rootfs runs full I get unexpected results like slowdowns and hangs. Do you have the fix common problems plugin installed? This will do a lot of checks and warn you if there are common problems on your server. It will also check if /var/log or the rootfs in memory are running full and warn you accordingly. If this happens you can then look for the cause and fix it. If you don't have it installed yet, I would recommend giving it a try. Debug logging generates a lot of output, so how big the log will get, depends on how often you have backups or other ftp tasks running and how much data is transferred in the process. So I can't say if it would fill up your flash. It should not be too dangerous to try, however. Keep an eye on it and stop the logging if it gets too big, too fast.

@jeffreywhunter Hmm... emhttp is the unRAID webui. It should have no connection to the proftpd plugin. Googling the error, I find a post of yourself, where you solved it by making sure smb3 is enabled on the windows machine. So if you have multiple windows 10 machines, is it enabled on all of them? The proftpd side error is lacking information. I would guess Dec 3 12:45:17 is the moment you cancelled the backup job? If so, its no real error, but proftpd saying it was stopped by the user. If not you could try to get more information by enabling debug logging as described here.

@chillr88 No, any path on your shares should be okay. If you manually created it in the unRAID shell, you will need to check, that it has the correct permissions to be accessible for proftpd. Default is user nobody and group users. Maybe run the newperms script with your directory as parameter (e.g. newperms /mnt/user/testshare/testshare 01/) to set the unraid default permissions. Also make sure you restarted the proftpd service after setting the path for the user.

@jeffreywhunter Its a security precaution by proftpd in the newer versions. If you don't need the transferlog, please disable it in the proftpd.conf by setting it to NONE. If you need it, it can no longer reside on the flash drive, as that is world writeable. Kindly refer to this post, where I explain how to set it up.

@althoralthor No problem. I'm very happy it worked and you like the plugin.

@Kewjoe If it is internal, using pure FTP would be the simplest solution, yes. If you are set on SFTP you can go back in the thread, there are some infos on how to get this running. But be aware, that it is not so easy and as an user reported above, he gets an error witch implicates a crash of proftpd. That one I can't resolve and had to tell him to ask the proftpd devs instead. @althoralthor Okay no problem. I did the following on the unRAID console: mkdir /mnt/cache/Apps/proftpd chown nobody:users /mnt/cache/Apps/proftpd chmod 744 /mnt/cache/Apps/proftpd The first command creates the directory /mnt/cache/Apps/proftpd where the transferlog file xferlog will be created. The second command changes the user and group of that directory to nobody:users, which is the user and group of the default unraid user. The last command changes the access rights to 744 which means owner can do everything (7), group can do reads only (4) and world can do reads only (4). That solves the security problem proftpd hinders to use the log folder. In the next step you change the proftpd.conf: #TransferLog NONE TransferLog /mnt/cache/Apps/proftpd/xferlog So you comment the TransferLog NONE so it gets ignored and define the new TransferLog to be used. The xferlog is the name of the logfile, you can change it if you wish. The other is the path you prepared. Afterwards you restart proftpd and if a connection gets opened, the xferlog file in the folder will get created. It will be empty until a transfer is completed. The file will be owned by the user root, as that is running the proftpd service, but it will be readable by others.

@Kewjoe Setting up SFTP access requires changes in the proftpd.conf file too. By default the plugin only supports basic ftp access and only that gets tested. Also it is not tested on versions above 6.3.5. For security reasons I always recommend to use a VPN to access you home network and not expose unRAID to the internet. Doing it that way it doesn't matter, that basic FTP is unencrypted.

@althoralthor Checking the logfile shows that proftpd refuses to create the xferlog file in a directory, that is world writable for security reasons. Sep 9 15:53:33 lafiel proftpd[23554]: 127.0.0.1 (192.168.178.69[192.168.178.69]) - opening TransferLog '/boot/config/plugins/ProFTPd/xferlog' Sep 9 15:53:33 lafiel proftpd[23554]: 127.0.0.1 (192.168.178.69[192.168.178.69]) - error: /boot/config/plugins/ProFTPd is a world-writable directory Sep 9 15:53:33 lafiel proftpd[23554]: 127.0.0.1 (192.168.178.69[192.168.178.69]) - unable to open TransferLog '/boot/config/plugins/ProFTPd/xferlog': No such file or directory As the unRAID stick has the FAT filesystem, you can't change the security permissions on it. So you need to create a directory on your array or cache drive. There you can use the chmod command to change the permission to set the directory to something only the owner and group can access. Then proftpd will create the transfer log file in there and log transfers.

@Ruby-Rube Sadly this is way over my head. I don't know what is going wrong and what is causing your error. If it is my selfcompiled version of proftpd used for the plugin, or if it is unraid or something else entirely. I guess you will have to contact the proftpd devs using their forum or mailing list and ask them, if they can tell from the log what is going wrong. Sorry.

@Ruby-Rube Sadly I can't tell from the errors what the problem could be. Maybe it would help to up the logging level to a high debug by adding SyslogLevel DEBUG DebugLevel 10 to you ProFTPd.conf, as described here. Let's see what the error messages look like, if you try it with that enabled.

@isvein I'm glad you like it and find it useful. Thank you.

@jeffreywhunter Yes, the vacation was great. Thank you. IMHO the xferlog should be an empty file not a directory. Please delete the directory on the flash and replace it with an empty file.