Squid

I've made a test and it works. You need to put the statement: $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; In front of the require_once statements in your standalone scripts, and you are good to go. Once you have updated, I am going to remove the hard-coded path. FYI for anyone else interfacing with dynamix include files, that line needs to be added to just about everything. The above statement is not necessary anymore. I made a fallback mechanism in the modules themselves. Squid, you may want to revert your changes, sorry! Couple days. Living in hotel for a few Sent from my LG-D852 using Tapatalk

Since it looks like that sets up a cron to do it you would set that to run at startup Sent from my LG-D852 using Tapatalk

It's stored in RAM so it's lost with every boot Sent from my LG-D852 using Tapatalk

the space in the volume name is the issue, i'm not sure what the fix is for that regards unraid and docker other than don't use spaces in linux folder names. The original post got deleted, but the fix for spaces in volume paths under 6.1.9 is to check for plugin updates and install the webUI update available

I've made a test and it works. You need to put the statement: $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; In front of the require_once statements in your standalone scripts, and you are good to go. Once you have updated, I am going to remove the hard-coded path. FYI for anyone else interfacing with dynamix include files, that line needs to be added to just about everything.

Read the faq entry. Nothing to worry about Sent from my SM-T560NU using Tapatalk

At least you are going to have a very productive weekend. Good luck! When don't I.... I had my week or two off from updates, and now I'm back to my normal schedule of a new feature every other day

I've made a test and it works. You need to put the statement: $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; In front of the require_once statements in your standalone scripts, and you are good to go. Once you have updated, I am going to remove the hard-coded path. Side question: Does this have any side-effects on stuff called via the UI? I didn't notice anything with FCP since scan.php can be executed either way (kinda) but would drop my testing time significantly with CA since I have to do everything three times (with bleeding edge and without, and with 6.1.9) That's the whole point, when executing a script in CLI (standalone) mode it is not possible to pass on server settings, hence the statement to mimic. In other words there won't be any side-effect calling your script via GUI or directly. CA updated. Doesn't have the other thing we were talking about, but that'll be done tomorrow (tons and tons of testing required on it)

You guys leave me sleepless... The good news: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.bleeding.edge.plg This is version 2016.09.16 and works with unRAID 6.2 stable. Copy & paste the URL above into the install box of plugin manager. Minor nitpicks on bleeding edge: In tabbed mode, IMO its weird that the button to toggle views still appears on the Array Operations tab but does nothing (nothing for it to do but I just don't like it) With UD installed, the button is still there also, but you can't even click on it.

I've made a test and it works. You need to put the statement: $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; In front of the require_once statements in your standalone scripts, and you are good to go. Once you have updated, I am going to remove the hard-coded path. Side question: Does this have any side-effects on stuff called via the UI? I didn't notice anything with FCP since scan.php can be executed either way (kinda) but would drop my testing time significantly with CA since I have to do everything three times (with bleeding edge and without, and with 6.1.9)

Same exact issue w/6.2. I ended up getting a 1TB SSD as my cache, but now I can't do any docker items on Unassigned Devices (I had two, one for all apps except Plex (120GB) and one for Plex alone (480GB, so my metadata / thumbnails could take as much space as possible). I'm glad I can have multiple Cache drives now. After a previous update I had issues as well, so I'm just moving all my SSDs to Cache Drives and going from there. docker.img has to be on the cache. You should however be able to keep the appdata for whatever you choose on a UD device. Just change the Mounting Mode for the host path from RW to be RW:Slave

Man I got hit with this. Scared the crap out of me to find a fix since nothing would start up after this update. Fixed it now. Yeah, since everything was working properly under 6.2 beta/rc (with it not upgrading 6.1.9), everyone involved assumed there wouldn't be an issue with 6.2 final. But there was another change to the infrastructure of the 6.1.9 release that caused a snowball effect. Fixes are already being implemented to prevent it from ever happening again in the future.

I've made a test and it works. You need to put the statement: $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; In front of the require_once statements in your standalone scripts, and you are good to go. Once you have updated, I am going to remove the hard-coded path. FCP is done an updated (and tested on 6.2 / 6.1.9 with no apparent problems - Can't however easily test the docker stuff on my 6.1.9 box so I'll have to take your word for it that this won't have any repurcussions on 6.1.9) CA's testing is far more involved however before that ever gets released to the wild...

There's an entry in the docker FAQ about this Sent from my LG-D852 using Tapatalk

I've also posted in the CA thread about this. Pointless for me to update CA to disallow this, because most users would get the CA update via auto-updates at which point the UI will update also. Easiest solution is to pull the update for dynamix

An update for Dynamix webUI is / was being offered up to 6.1.9 users without updating to 6.2 Unfortunately, this update is incompatible with 6.1.9 (its the 6.2 webUI). You will need to disable auto-updates on the dynamix webUI. I would offer up a CA update to try and mitigate this problem, but most users would get the CA update through auto-updates, at which point the UI is going to update itself to, so there's no much point.

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 ) It's all CHBMB's fault, right ... Think I'll bookmark this post instead

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 )

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.

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

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)

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)

Now that 6.2 is final that is going to be deprecated. Updated... With 6.2 dropping the RC-x suffixes, my existing test that was ignoring those tests during the RC stage wound up executing under 6.2 final Sent from my LG-D852 using Tapatalk

- Fixed minor compatibilty issues with 6.2 Final - Changed: Only log maximum 10 rsync errors in backup module - Fixed: disallow faster rsync option if days to keep backup sets is disabled (or set to 0) - Fixed: backup to flashdrive setting (entry could have been possibly corrupted under 2016.09.03) - Added: Script to delete old dated backups in addition to ALL backups and error backups only * - Changed: Update Apps now called Legacy Mode. Selecting again goes back to appFeed mode - Removed: Private Repositories via a GitHub repo. ** - Added: Selectable notifications on autoupdates of plugins - Added: XML Branch support while in Legacy Mode - Fixed: Display aberrations while in legacy mode if some repositories didn't download - Added: Legacy mode will now display any XML's which failed to parse Now with 6.2 final released, I will shortly be completely deprecating the ability for the backup module to put backups onto a disk share, and will instead rely upon the user to appropriately set included / excluded disks & split levels for any destination share. When running 6.1, disk shares are still the only method that CA backup will support. * Because of how the backup module works, if the disk / share used for a backup destination winds up full, old dated backups (that may be scheduled to be deleted) will not get deleted (in order to always preserve a completed backup set). This kind of leads into a catch-22 situation because at that point no further backup will succeed, and no old backups will ever get deleted in order to make room for the new ones. Manually deleting the old backup sets is a PITA due to the varying permissions involved, so a new script under the Misc Tab within the backup module exists which will delete all backup sets which meet the criteria on days to delete, in addition to the original scripts of deleting ALL backup sets, and deleting the errored out backup sets only. ** Really doubt anyone ever used this option, because after looking at the code again, CA was reverting back to Legacy mode to accomplish this support, so ultimately it is more trouble than its worth. CA still supports private repositories via creating a folder under /boot/config/plugins/community.applications/private/REPOSITORYname/ and placing the xml's within it.

If you can come up with a way for me to still be able to access DockerClient via standalone scripts, then I'm ok with making necessary adjustments to both CA and FCP. But, as it stands now, both of those plugins 100% require access to DockerClient via standalone scripts. (and looked at CA and there is other scripts contained that would probably fail since its a php script of a bash script called via the webUI) But, for me to redo those scripts as pure bash is pretty much not going to happen due to the complexities of recreating them in bash. It is certainly not my intention to let you rewrite your scripts into bash (do a lot of PHP myself too). I have changed scripts to query the webserver to get the root path which is then prepended to make a full path. I haven't tried it yet, but a standalone script can set the variable which is normally done by the webserver. I.e. $_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp"; DockerClient.php will read the above variable to construct the necessary paths. If all of this doesn't work, last resort stays of course hard-coding... Well, since you've already hardcoded it back, you can try it out as I am unable to with your release.