dlandon

Yeah that is the correct command Does this work with the stock powerdown? I thought it only worked with the powerdown plugin. It should work in the stock powerdown, but it isn't working for me. It is working from the webgui that issues that command though. I mixed up two things. powerdown -r is indeed only available from the powerdown plugin. The stock powerdown script calls emhttp with the "shutdown" command. A reboot from the GUI calls emhttp with the "reboot" command. Not thru powerdown. So it would be 'powerdown reboot'?. There is no command for reboot?

Yeah that is the correct command Does this work with the stock powerdown? I thought it only worked with the powerdown plugin. It should work in the stock powerdown, but it isn't working for me. It is working from the webgui that issues that command though.

I've done a reboot. It only occurs when I do a powerdown from the webgui and the command line. Not on reboot. Just as an aside. What is the command line reboot? I thought it was 'powerdown -r'?

After installing dynamix bleeding edge I am getting a console error when shutting down: /mnt has been successfully unmounted. /var/log has been successfully unmounted. umount: /boot unmounted Warning: file_put_contents(/archive/unRAID_Server_Alert_1474225393.notify) fail ed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/scripts/notify on line 192

server didn't power down last night ;( from cli /usr/local/sbin/powerdown or just powerdown powerdown or /usr/local/sbin/powerdown does NOTHING .... going to install the package again after i find this restriction and delete the restriction At the cli: root@MediaServer:~# whereis powerdown powerdown: /usr/local/sbin/powerdown root@MediaServer:~# The powerdown script is there. I suspect that there is an issue in your server preventing the shutdown that the plugin may have helped with. The plugin was deprecated for several reasons. The main reason is that it was not really necessary because the builtin powerdown is more robust. Another is that v6.2 presented some challenges that I didn't overcome so it was not ready for v6.2 release. Rather than getting all dramatic and overcoming the restriction to install a deprecated plugin, why don't you spend a few minutes and find out the problem with the built in powerdown. At the command line type powerdown and then troubleshoot the issue(s). EDIT: Take a look at this post: http://lime-technology.com/forum/index.php?topic=31735.570#lastPost We are back to the reason the powerdown plugin was created in the first place. The webgui shutdown gets stuck in a loop waiting for an event that will never happen because the powerdown script is relying on the webgui to perform a shutdown. I think it's time for LT to finally solve this nagging problem. I'm going to post a defect report.

server didn't power down last night ;( from cli /usr/local/sbin/powerdown or just powerdown

Don't thank me yet. There's going to be a couple hundred posts now about why powerdown is listed as incompatible. ( I've already got your explanation post bookmarked ) I expect some feedback. It's been around a long time and some will not like it going away.

ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Should probably change it then Done. Set to 6.1.9. As I understand, that is the max version CA will allow and FCP will check. Correct. And CA is already flagging it as incompatible on my 6.2 system and my 6.1.9 system its ok. Just have to reconfigure FCP and we're good to go. Thank you.

ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1. Should probably change it then Done. Set to 6.1.9. As I understand, that is the max version CA will allow and FCP will check.

ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary. Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2) Just read it a bit closer. Did you set it to 6.1 or 6.1.9 Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs) 6.1.

ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. Powerdown will not install on v6.2 any more. I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install. It is no longer necessary.

I you have a Smart or Managed Switch, you will find that the switch has set up a default VLAN that includes all ports in the switch. It is probably VLAN 1. You should set up the unRAID network to be a member of that VLAN. I found a lot of dropped packets before I set up a VLAN on unRAID. Maybe one of the network experts here can offer some explanation.

ok. This what I'll do then. I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all) If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1) Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it. That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error. That's a plan. I know some people still want to use it, but it has become increasingly difficult to chase down the changes in the shutdown scheme LT implements in each version and for me to try to keep up. LT has also improved the shutdown in 6.2 and does not rely on emhttp for the shutdown which is where the process would get stuck waiting for something to happen/complete. In 6.1 dockers and VMs were shutdown by the unmounting events. In 6.2 the dockers and VMs are shut down with explicit calls for a shutdown. I've suggested a few changes to the built in shutdown and if they do those, there is not much need at all for the powerdown script.

If you don't want the drive to spin up, be sure you do not have a script defined. If you do then delete the script. The second post describes this and some other good practices.

Very nice.

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop. The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs. Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin. It's not as necessary now as on earlier versions. As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin. I am thinking that I'll block its install on versions later than v6.2. I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

If you really want to do a deep dive into bonding check this out: https://wiki.linuxfoundation.org/networking/bonding#Switch_Configuration

There are some limitations to some modes. Mode 1 requires nothing special in the NICs or your switch. I use the tlb (mode 5) because it requires nothing special in the NICs and no switch support. The 802.3ad mode requires ad support in the switch. The alb (mode 6) requires NICs that can have their MAC address changed on the fly. You generally have to go to a full managed switch to get ad support. A full managed switch in a home network is probably overkill. I use a smart switch that does not support ad, but I have some control of QOS, flow control, etc. I would stay with Mode 1, or 5. Using the other modes don't really gain you a lot unless you go to the 802.3ad (mode 4) and have a managed switch. In my opinion the cost of the managed switch isn't justified to gain 2GB speed in a home network.

You are writing the mariadb config files directly to a share. If the "Config" share is used by other Dockers, you have a mess on your hands. The idea is Docker files go to /mnt/cache/appdata with a unique folder for each Docker. In this case it should be: /mnt/cache/appdata/mariadb/ and the config folder is created there for mariadb. Try to stay with the standard nomenclature so we can offer you help. Your non-standard configuration is very confusing and hard for us to support.

In the Docker setup, the Docker config path/config should be: /mnt/cache/appdata/mariadb/config. Change it to this and see if the problem is not solved.

Shouldn't that be /mnt/cache/appdata/Configs?

I thought about that but decided against it for the following reasons: Telnet is not necessary and SSH should be used instead. Putty works with SSH. The built in FTP is very difficult to configure because the configuration file has to be edited by hand and moved to the tmp file system once unRAID has started. As you recommend in the wiki, an FTP docker or plugin is a better choice. I would like to see LT remove both of these as they are potentially not secure, and other better answers are available.

Yes, but it turns back on after a reboot and I forget to turn it off. The Tips & Tweaks plugin would turn off FTP and telnet on each reboot when the plugin is loaded and would not require interaction if it is set by the user to turn off in the plugin. As Ron Popeil would say "Set it and forget it".

I'll add the disable of ftp and telnet to the tips and tweaks plugin.

Having a problem with the owncloud docker. I am getting this error: "This server has no working Internet connection. This means that some of the features like mounting external storage, notifications about updates or installation of third-party apps will not work. Accessing files remotely and sending of notification emails might not work, either. We suggest to enable Internet connection for this server if you want to have all features." It has come up before and was solved here: http://lime-technology.com/forum/index.php?topic=33891.msg401859#msg401859 NOTE: Never mind. The www.owncloud.org certificate expired yesterday so the connection cannot be made.