Squid

/boot/config/plugins/user.scripts/scripts/.... You can do over the network.

Guess my not-so-secret postings actually are secret = =

At work so can't test, but I don't think that will work properly. Sure, plugin checkall won't look for updates against unRAIDServer-, but the perfectly normal chain of events I listed will still result in that file getting created and plugincheck will still look at all *.plg in /tmp/plugins and pop out the notification in the steps I've detailed. You need to check against /var/log/plugins/*.plg

plugin('checkall'); foreach (glob("/tmp/plugins/*.plg", GLOB_NOSORT) as $file) { $name = basename($file, '.plg'); $old = plugin('version', "/var/log/plugins/$name.plg"); $new = plugin('version', $file); // silently suppress bad download of PLG file if (strcmp($new, $old) > 0) { exec("$notify -e ".escapeshellarg("Plugin - $name [$new]")." -s ".escapeshellarg("Notice [$server] - Version update $new")." -d ".escapeshellarg("A new version of $name is available")." -i ".escapeshellarg("normal $output")." -x"); } } plugincheck (not oscheck) checks every .plg in /tmp/plugins. It doesn't care if its actually installed or not, and unRAIDServer-.plg is not installed It then compares the new version (in this case, 6.5.1rc-1 to a non existent old version). Since the version string is > null the notification is sent out. And you can also see this in any of dlandon's screenshots as they all state A new version of unRAIDServer- is available. I think my procedure is more akin to what a user would actually do. Check for next, then go on and do nothing or start switching tabs etc. There is no need to switch the branch back to "normal". And I did this on both 6.5.0 and 6.5.1rc-2

What error? The script states that if an error appears no dangling images were found.

I'm taking that back @bonienl Here's how to replicate @dlandon's problem without involving UA at all and in a perfectly acceptable manner: Fresh boot running 6.5.0 / 6.5.1-rc2 Plugins - Check For Updates (or wait for a scheduled plugin check to happen) - Probably not necessary step though Tools - Update OS. Switch from Stable To Next (when running 6.5.0) or Next to Stable (when running 6.5.1-rc2) User decides to not install and carries on with their life Next time a scheduled plugin check happens (and on all subsequent ones) (/usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck), a notification will be given for an update being available, even though they remained on stable Problem is that plugincheck assumes that any .plg in /tmp/plugins is installed, and nothing is ever deleting unRAIDServer-.plg dlandon running Update Assistant against the Next branch replicated the same steps as above, and simply accelerated the problem. Problem will only appear though during scheduled plugin checks. I'll pop in a PR tomorrow night...

You bastard. Perfect response LOL

You RDP into the VM's IP

lol We all know who's going to have to fix this. I'll make backups of the existing file(s) first and then restore.

Except that when you said that unRAIDServer.plg states "Next", that shouldn't happen, nor IIRC would an check for Updates using @bonienl's code change the .plg from Stable to Next. The fundamental thing the code does is simply download another .plg file (unRAIDServer-.plg) that has the branch set to be Next

This actually has been on the todo list for quite awhile, but it introduces a complication because by design to make life easier for the end-user, all scripts are not executed in place, but rather from /tmp after having their line endings normalized for linux. Because of that, any scripts already existing that may have other dependencies within their own directory may or may not work properly. Plus, you can simply make a script to cd and then execute the required script anyways.

If you checked UpdateAssistant against the "Next" release, then unRAIDServer-.plg may still exist. (I can't remember if I delete it after checking). But, I would think that when dynamix checks for updates it deletes everything in /tmp/plugins anyways (mobile so not in a position to also check). Either way, remind me to make sure that I delete the "next" version of the .plg in UA after I'm done with it.

chmod +x /mnt/user/appdata/binhex-sabnzbd/scripts/ComicRN.py

Since you mapping is correct right now, check that sab is storing completed downloads in /data and not /downloads

https://lime-technology.com/forums/topic/57181-real-docker-faq/#comment-564345

To edit the XML, switch to XML view at the top right. Not in front of the server at the moment, so can't easily comment on switching the port though via the form view (and I don't run VM's without passthrough)

I'm hoping that people will eventually figure out that Update Assistant should be run before upgrading (and not after). LT can only do so much to protect the user from themselves, and there's a ton of other things (mainly plugin compatibility) that I can take responsibility for that LT can't at this point in time.

Why when buddy originally posted his problem I asked for the diagnostics, as they also show (none), which automatically means invalid NetBIOS. He's not the first (I'm laying claim to that fame starting with 6.5.0-rc2), won't be the last I'm undecided though on whether it should automatically be changed at boot though. I think if anywhere if you're going to change it should be during install, in big bright letters to at least inform the user that this is being changed.

Side Note, that the Upgrade Assistant (ideally run before upgrading) does catch this. It's more than just spaces. An underscore will do the same thing. NETBIOS should be max 15 Characters, only contain A-Za-z0-9, dashes and dots, and has to start and end IIRC with alphanumeric

from the command prompt, ls -ail /mnt/user/...... should show you something there... if not, I'd need you to PM the output of that command ls -ail /mnt/user/.... > /boot/squidTest.txt

lol I didn't see any red, so didn't notice that

Its an issue for the odd person when doing somethings docker related from the webUI. Its a WIP by some other people.

yup