May 8, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it.
May 8, 201610 yr Author With the multitude of options available for cloud storage and web hosting such as ownCloud, and other Dockers that can be made secure and are easier to use, is there really a need for FTP access to unraid?
May 8, 201610 yr With the multitude of options available for cloud storage and web hosting such as ownCloud, and other Dockers that can be made secure and are easier to use, is there really a need for FTP access to unraid? From a marketing standpoint, you need it. You won't be able to explain it to prospective users. All they will see is "unRAID can't do FTP?!?!"
May 8, 201610 yr Author There are Dockers that do FTP, so not a problem if it is taken out. LT will have to make the final determination. I'm just offering my opinion.
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default.
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default. Not at my system at the moment but if you have users entered in and ftp set to be disabled does it or does it not after a reboot say that it's enabled? And in that case this is a valid defect. Not a feature req regardless of what the help text says. Highly misleading at the very least. Sent from my LG-D852 using Tapatalk
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default. Not at my system at the moment but if you have users entered in and ftp set to be disabled does it or does it not after a reboot say that it's enabled? Sent from my LG-D852 using Tapatalk FTP is always enabled after a reboot (=FTP daemon is started), if you had users entered then FTP transactions are allowed too. Again this is intended behaviour. It will correctly show that the FTP server is "enabled" and "running" in the status bar.
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default. Not at my system at the moment but if you have users entered in and ftp set to be disabled does it or does it not after a reboot say that it's enabled? Sent from my LG-D852 using Tapatalk FTP is always enabled after a reboot (=FTP daemon is started), if you had users entered then FTP transactions are allowed too. Again this is intended behaviour. You might not be able to answer this, (and don't take any offense) but what is the justification for this design? Sent from my LG-D852 using Tapatalk
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default. Not at my system at the moment but if you have users entered in and ftp set to be disabled does it or does it not after a reboot say that it's enabled? Sent from my LG-D852 using Tapatalk FTP is always enabled after a reboot (=FTP daemon is started), if you had users entered then FTP transactions are allowed too. Again this is intended behaviour. You might not be able to answer this, (and don't take any offense) but what is the justification for this design? Sent from my LG-D852 using Tapatalk I can partly explain how it came about, which is not a justification as you are asking, but may give you more inside. The original design of unRAID - dating back to the 4.x versions - always starts the FTP daemon after a system reboot and the only way to allow or disallow FTP transactions is by entering or clearing the users field. This implementation hasn't changed over the 5.x and 6.x versions as far as I know. There is no "state" variable defined within unRAID to tell whether the FTP daemon should start or not upon a system reboot. I found it questionable to have a running FTP daemon (active ports), while not using the service, hence the possibility was added in the webGUI to at least stop the daemon when not needed, but since it can't be linked to a state variable, this setting won't survive a reboot.
May 13, 201610 yr unRAID OS Version: 6.1.9 and 6.2.0 b21 Description: Disabling FTP gets re-enabled on reboot. How to reproduce: Disable FTP and reboot. Expected results: FTP stays disabled. Actual results: FTP is re-enabled. Other information: FTP should actually default to disabled and only enabled when the user enables it. What you describe above is actually intended behaviour and not a defect report. See also the help which goes along with FTP (see attachment). The FTP daemon is always started upon system start up, but as long as no users are defined it is not possible to do any FTP transactions. Agreed, this is a debatable situation, hence the possibility to completely stop the FTP daemon from the webGUI. I would say, it is a feature request to get a different implementation. Read: FTP disabled by default. Not at my system at the moment but if you have users entered in and ftp set to be disabled does it or does it not after a reboot say that it's enabled? Sent from my LG-D852 using Tapatalk FTP is always enabled after a reboot (=FTP daemon is started), if you had users entered then FTP transactions are allowed too. Again this is intended behaviour. You might not be able to answer this, (and don't take any offense) but what is the justification for this design? Sent from my LG-D852 using Tapatalk I can partly explain how it came about, which is not a justification as you are asking, but may give you more inside. The original design of unRAID - dating back to the 4.x versions - always starts the FTP daemon after a system reboot and the only way to allow or disallow FTP transactions is by entering or clearing the users field. This implementation hasn't changed over the 5.x and 6.x versions as far as I know. There is no "state" variable defined within unRAID to tell whether the FTP daemon should start or not upon a system reboot. I found it questionable to have a running FTP daemon (active ports), while not using the service, hence the possibility was added in the webGUI to at least stop the daemon when not needed, but since it can't be linked to a state variable, this setting won't survive a reboot. Fair enough. Feature req it is... Sent from my LG-D852 using Tapatalk
May 13, 201610 yr Author I vote for just removing the built in FTP altogether and let people use a Docker instead. Configuring the built in FTP is very cumbersome and changes to the FTP script do not survive a re-boot.
May 13, 201610 yr I vote for just removing the built in FTP altogether and let people use a Docker instead. Configuring the built in FTP is very cumbersome and changes to the FTP script do not survive a re-boot. I vote for that as well. And if LT want to be able to advertise FTP as a feature then LT simply creates one in their base LT Docker Repository.
May 20, 201610 yr If the ftp daemon respected permissions I'd have a use for it but All user names entered above are permitted to access the server via FTP and will have full read/write/delete access to the entire server, so use with caution makes it almost entirely useless and quite a liability. I'd rather have a decent ftp daemon built-in than have to use a Docker - it wouldn't have to be especially configurable; just give the appropriate access to the registered users to the files in the appropriate shares, and certainly not give blanket access to private shares.
June 1, 201610 yr I can partly explain how it came about, which is not a justification as you are asking, but may give you more inside. The original design of unRAID - dating back to the 4.x versions - always starts the FTP daemon after a system reboot and the only way to allow or disallow FTP transactions is by entering or clearing the users field. This implementation hasn't changed over the 5.x and 6.x versions as far as I know. There is no "state" variable defined within unRAID to tell whether the FTP daemon should start or not upon a system reboot. I found it questionable to have a running FTP daemon (active ports), while not using the service, hence the possibility was added in the webGUI to at least stop the daemon when not needed, but since it can't be linked to a state variable, this setting won't survive a reboot. That actually explains some things, but IMO this is ridding the fence between being a Feature Request (Remove FTP or disable by default) and being a Defect (FTP is enabled by default, when this behavior is not desirable) Now that we know the background it makes some sense why the FTP is enabled by default but IMO this is an area where there was a Band-Aid applied and work needs to go into either making this fully featured (allowing per user permission levels) or removed, or disabled by default. Has anyone made the actual feature request for this?
Archived
This topic is now archived and is closed to further replies.