SlrG

Community Developer
  • Posts

    584
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SlrG

  1. @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.
  2. @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.
  3. @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.
  4. @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.
  5. @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.
  6. @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.
  7. @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.
  8. @althoralthor No problem. I'm very happy it worked and you like the plugin.
  9. @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.
  10. @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.
  11. @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.
  12. @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.
  13. @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.
  14. @isvein I'm glad you like it and find it useful. Thank you.
  15. @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.
  16. @jeffreywhunter Sorry for the delayed answer, I was on vacation. The first error is because the config file for proftpd is stored on your flash drive for persistence. When the unRAID server is running, it is symlinked to the config folder in your RAM but it inherits the user and access rights from the flash. As the flash uses the old MS-DOS filesystem fat32, there are no user and access rights stored and thus the error is thrown. It is a possible security risk, that anybody who has access to your flash is able to edit the config files, but that if somebody has physical access to your server there are a lot more effective ways to harm you or your data. So it can be ignored. Sadly there is no way to disable the error. For the second one, please check your ProFTPd.conf. The default logging section looks like this: # 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 Please note the TransferLog NONE line and the # before the TransferLog /boot/config... line. The TransferLog NONE should solve your error. It won't log Transfers, but normally this is not necessary. If you want to log Transfers, it should be enough to create an empty xferlog file on the flash or different path. This should persist and will not require a go file entry. @killeriq Please read the first post and the readme. This should answer your questions. You need to configure an user to allow FTP access by editing the comments of this user in unRAIDs user management.
  17. @geonerdist Yes, that is the reason.
  18. @geonerdist There is someone trying to hack into your server. Mostly these are automatic scripts that someone setup, that crawl the net looking for servers on standard ports and trying known user and password combinations on them. Which port did you open on your router to forward it to your server? If you openend 21 I would ASAP change that to some other port above 49151 eg, 49221 or something. That will probably stop those login attempts. The port the proftpd server is running on, can stay 21. That does not matter. Just Forward from 49221 on the router to 21 on the server. Also make sure, you have secure usernames and passwords. No admin admin or something. If you want more security, don't open the ftp port on the router but use an vpn connection to connect to your private network from the outside and then you can access your PC's from there.
  19. @MickMorley The bug should be fixed now. Please update the plugin and delete the ProFTPd folder from your web server directory. Then restart the service and the fixed editor should be saved into your web server directory. Thank you very much for finding and reporting this bug.
  20. Okay. Thank you for the information. I'll try to fix the error and release a new version soon. It will still not work with the docker apache versions however, as I don't know how I could possibly fix that.
  21. @MickMorley I tried to use the docker apache when it was made available and I failed, too. I'm using the plugin version now and that works fine. I believe the reason why the dockers fail is, because they block access to files outside of the defined web folder for valid security reasons. Sadly this is something the config editor needs to work, as the proftpd.conf is in /etc/ on your unRAID. If you don't want to use the apache plugin instead, please disable the config editor. You don't really need it. You can always use nano in a console to edit the proftpd.conf or use winscp if you like a more graphical editor. Don't forget to restart the service afterwards for the changes to get applied. On a side note, you seem to be using an older version of my the proftpd plugin. The config editor has been renamed from proftpdce.php to ConfEdit.php. You should not get the old name with the newest version. If you are using the newest please tell me, I'll have to recheck the source code, then to make sure I did not miss some old reference in there.
  22. In newer versions of unRAID, the integrated FTP server is disabled by default, while the plugin expects it to be enabled. The installation doesn't work correctly and the plugin fails to work, too. Please remove the plugin, enable unRAIDs integrated FTP and then reinstall the plugin. I was not yet able to fix this bug, but I will in the future. For now this should get you going as a workaround.
  23. I'm glad the unRAID part works fine. Sadly I have no idea regarding WHMEasyBackup, as I have never used this.
  24. To enable sftp: open a shell on your unraid server and issue the following commands cd /etc/ssh ssh-keygen Enter the name of the keyfile (sftp_rsa_key) and no passphrase. You will get two files sftp_rsa_key and sftp_rsa_key.pub. The public key needs to be converted to another format to make it usable by proftpd: ssh-keygen -e -f sftp_rsa_key.pub | sudo tee sftp_user_keys You will get a new file sftp_user_keys. Now the owner and permissions will need to be changed: chown nobody:users sftp_rsa_key sftp_rsa_key.pub sftp_user_keys chmod 600 sftp_rsa_key sftp_rsa_key.pub sftp_user_keys Now to make your system restore the correct permissions of this keys on boot you will need to modify the mountscript: nano /boot/config/plugins/ProFTPd/mountscript.sh Insert the following lines: chown nobody:users /etc/ssh/sftp_rsa_key /etc/ssh/sftp_rsa_key.pub /etc/ssh/sftp_user_keys chmod 600 /etc/ssh/sftp_rsa_key /etc/ssh/sftp_rsa_key.pub /etc/ssh/sftp_user_keys Now edit your proftpd.conf file and insert: <IfModule mod_sftp.c> SFTPEngine on Port 2222 SFTPLog /var/log/sftp.log SFTPHostKey /etc/ssh/sftp_rsa_key SFTPAuthorizedUserKeys file:/etc/ssh/sftp_user_keys SFTPAuthMethods publickey SFTPKeyBlacklist none SFTPDHParamFile /usr/local/SlrG-Common/usr/local/etc/dhparams.pem </IfModule> Don't forget to restart the proftpd server to enable the changes. You need to copy the sftp_rsa_key and take it with you, to access your server. If you are using FileZilla to connect, the file needs to be converted to a usable format and stored in FileZillas settings.
  25. @mcleanap: It depends. On what you want. I found it would work using FileZilla when connecting from external sources. And it worked using FireFTP using internal ones. So using different clients for different access types could be a solution. Also you could set TLSRequired to off and then you will be able to connect without TLS internally, which should be much less a security risk. Also I would recommend setting up a vpn connection to your private network and use ftp within that to connect to the server and not make the ftp server freely accessible from the net. That depends on what you want to do however. Also the sftp connection is still possible. I was able to get it to work using the tips I gave you above. But I only tested it internally for now. I did not have the time to test it externally, too.