unRAID Server Release 6.0-beta10-x86_64 Available

[JM2005]

jumperalex,

 

I am seeing the same thing.  I emailed gfjardim about the dockermanager issue.

 

 

[jonp]

Not sure if this is a bug or not: but after using the webgui to update I see a stale version of unraid listed at the bottom as expected.  What is not expected is that it lists itself as beta10.  Looking at the flash drive I see a new folder v6.0-beta9.  Not causing a problem, but it doesn't seem right.

 

Also, I'm showing dockermanager needs an update but when I press update it just refreshes the screen and does nothing.

 

The stale version reported at the bottom is correct, but I can see how it's a little misleading.  You can click delete on it when done to remove.

 

As for the dockerman update, I'm also having that issue.  The update is linked to the limetech repo on github which Tom did update the dockerMan plugin just a few hours ago, but I'm not sure what's preventing the update from being pulled right now.  I'll sync up with him later today to see what's what on that...

[JM2005]

Thanks jonp!

[dlandon]

I updated from beta9, using the plugin manager update.  Now my Xen VM doesn't autostart, although the setting is still showing as autostart 'Yes'.

 

This appeared on the console, but I'm not sure whether before or after I started the VM manually:

Can't get domid of domain name 'archVM', maybe this domain does not exist.

 

Also, the VM isn't shutdown when the array is stopped from the web gui, resulting in a 'lock out' condition - the nfs daemon can't stop because the VM has files open on an nfs share.  The VM can't shutdown because the shares have been taken offline.

 

Having the same issue.  Xen VMs are not auto starting or stopping with the array start and stop.

[dlandon]

I get an error when using plgman at the command line.  If I enter 'plugin check Apcupsd-x86_64.plg' I get the following error:

 

Warning: mkdir(): File exists in /usr/local/emhttp/plugins/plgMan/plugin on line 146
2014.09.28

 

I don't know if this error is causing a problem or not.  I had an issue with updating some plugins, but I cannot reproduce the problem.

[jonp]

I get an error when using plgman at the command line.  If I enter 'plugin check Apcupsd-x86_64.plg' I get the following error:

 

Warning: mkdir(): File exists in /usr/local/emhttp/plugins/plgMan/plugin on line 146
2014.09.28

 

I don't know if this error is causing a problem or not.  I had an issue with updating some plugins, but I cannot reproduce the problem.

 

Not a problem.  This isn't an error.  It's simply stating that the directory already exists because you're updating the plugin, not installing new.  You can disregard it.

[dlandon]

I get an error when using plgman at the command line.  If I enter 'plugin check Apcupsd-x86_64.plg' I get the following error:

 

Warning: mkdir(): File exists in /usr/local/emhttp/plugins/plgMan/plugin on line 146
2014.09.28

 

I don't know if this error is causing a problem or not.  I had an issue with updating some plugins, but I cannot reproduce the problem.

 

Not a problem.  This isn't an error.  It's simply stating that the directory already exists because you're updating the plugin, not installing new.  You can disregard it.

 

I believe there is a problem maybe not related to this error message.  After I install a plugin, do a check, and then update the plugin, it is installed properly but no longer shows in the plugins web page.  This is the reason:

total 0
lrwxrwxrwx 1 root root 31 Sep 28 16:32 Apcupsd-x86_64.plg -> /tmp/plugins/Apcupsd-x86_64.plg  <-- not the proper symlink?
lrwxrwxrwx 1 root root 49 Sep 28 02:07 dockerMan.plg -> /usr/local/emhttp/plugins/dockerMan/dockerMan.plg
lrwxrwxrwx 1 root root 45 Sep 28 02:07 indexer.plg -> /usr/local/emhttp/plugins/indexer/indexer.plg
lrwxrwxrwx 1 root root 39 Sep 28 15:11 ntfs-3g-x86_64.plg -> /boot/config/plugins/ntfs-3g-x86_64.plg*
lrwxrwxrwx 1 root root 43 Sep 28 02:07 plgMan.plg -> /usr/local/emhttp/plugins/plgMan/plgMan.plg
lrwxrwxrwx 1 root root 41 Sep 28 15:11 powerdown-x86_64.plg -> /boot/config/plugins/powerdown-x86_64.plg*
lrwxrwxrwx 1 root root 36 Sep 28 15:11 snap-x86_64.plg -> /boot/config/plugins/snap-x86_64.plg*
lrwxrwxrwx 1 root root 45 Sep 28 02:07 sysinfo.plg -> /usr/local/emhttp/plugins/sysinfo/sysinfo.plg
lrwxrwxrwx 1 root root 49 Sep 28 02:07 unRAID-OS.plg -> /usr/local/emhttp/plugins/unRAID-OS/unRAID-OS.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 vendor.plg -> /usr/local/emhttp/plugins/vendor/vendor.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 webGui.plg -> /usr/local/emhttp/plugins/webGui/webGui.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 xenMan.plg -> /usr/local/emhttp/plugins/xenMan/xenMan.plg

 

The plugin file for the Apcupsd plugin is not located in the /tmp/ directory, it is at /boot/config/plugins/.

[stottle]

FYI, the forum front page still lists Beta 9 as the latest.  I didn't look at the announcements and see beta 10 until I saw jonp's post about testing beta10 in the kvm section.

[jonp]

FYI, the forum front page still lists Beta 9 as the latest.  I didn't look at the announcements and see beta 10 until I saw jonp's post about testing beta10 in the kvm section.

Thanks for the heads up. We will fix.

[JM2005]

Ok it seems Docker Manager is now updating!  I rebooted to make sure it worked and it came back up just fine.

 

Thanks

JM

[jonp]

There definitely is a bug with Xen. We have tracked it down and are working to fix.  It affects autostart and shutting down the VMs at array stop.

[limetech]

I get an error when using plgman at the command line.  If I enter 'plugin check Apcupsd-x86_64.plg' I get the following error:

 

Warning: mkdir(): File exists in /usr/local/emhttp/plugins/plgMan/plugin on line 146
2014.09.28

 

I don't know if this error is causing a problem or not.  I had an issue with updating some plugins, but I cannot reproduce the problem.

Meaningless warning, removed in beta10a.

 

I believe there is a problem maybe not related to this error message.  After I install a plugin, do a check, and then update the plugin, it is installed properly but no longer shows in the plugins web page.  This is the reason:

total 0
lrwxrwxrwx 1 root root 31 Sep 28 16:32 Apcupsd-x86_64.plg -> /tmp/plugins/Apcupsd-x86_64.plg  <-- not the proper symlink?
lrwxrwxrwx 1 root root 49 Sep 28 02:07 dockerMan.plg -> /usr/local/emhttp/plugins/dockerMan/dockerMan.plg
lrwxrwxrwx 1 root root 45 Sep 28 02:07 indexer.plg -> /usr/local/emhttp/plugins/indexer/indexer.plg
lrwxrwxrwx 1 root root 39 Sep 28 15:11 ntfs-3g-x86_64.plg -> /boot/config/plugins/ntfs-3g-x86_64.plg*
lrwxrwxrwx 1 root root 43 Sep 28 02:07 plgMan.plg -> /usr/local/emhttp/plugins/plgMan/plgMan.plg
lrwxrwxrwx 1 root root 41 Sep 28 15:11 powerdown-x86_64.plg -> /boot/config/plugins/powerdown-x86_64.plg*
lrwxrwxrwx 1 root root 36 Sep 28 15:11 snap-x86_64.plg -> /boot/config/plugins/snap-x86_64.plg*
lrwxrwxrwx 1 root root 45 Sep 28 02:07 sysinfo.plg -> /usr/local/emhttp/plugins/sysinfo/sysinfo.plg
lrwxrwxrwx 1 root root 49 Sep 28 02:07 unRAID-OS.plg -> /usr/local/emhttp/plugins/unRAID-OS/unRAID-OS.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 vendor.plg -> /usr/local/emhttp/plugins/vendor/vendor.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 webGui.plg -> /usr/local/emhttp/plugins/webGui/webGui.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 xenMan.plg -> /usr/local/emhttp/plugins/xenMan/xenMan.plg

 

The plugin file for the Apcupsd plugin is not located in the /tmp/ directory, it is at /boot/config/plugins/.

 

I installed your plugin on a newly configured -beta10 server and do not see this issue - it installed correctly.  Tried remove and install again and it worked.  Did not try an 'update'.

 

BTW you can remove the checking for 'network up' at beginning of the plugin.

 

Edit: yes found the problem.  BTW here's what happened: just before final build of release I did some 'git' work - git add, git commit, etc. and I somehow messed that up and some edits got clobbered  :'(

 

I'll get a beta10a out asap - will be later this evening.

[archedraft]

How long would you say it takes to update from the webgui? I have a pretty fast internet connection so it should download rather quickly. I click update and after a few seconds the webgui went away. I have been clicking refresh every few minutes or so but nothing has changed (I am at about 15 min wait time so far)...

[dlandon]

I get an error when using plgman at the command line.  If I enter 'plugin check Apcupsd-x86_64.plg' I get the following error:

 

Warning: mkdir(): File exists in /usr/local/emhttp/plugins/plgMan/plugin on line 146
2014.09.28

 

I don't know if this error is causing a problem or not.  I had an issue with updating some plugins, but I cannot reproduce the problem.

Meaningless warning, removed in beta10a.

 

I believe there is a problem maybe not related to this error message.  After I install a plugin, do a check, and then update the plugin, it is installed properly but no longer shows in the plugins web page.  This is the reason:

total 0
lrwxrwxrwx 1 root root 31 Sep 28 16:32 Apcupsd-x86_64.plg -> /tmp/plugins/Apcupsd-x86_64.plg  <-- not the proper symlink?
lrwxrwxrwx 1 root root 49 Sep 28 02:07 dockerMan.plg -> /usr/local/emhttp/plugins/dockerMan/dockerMan.plg
lrwxrwxrwx 1 root root 45 Sep 28 02:07 indexer.plg -> /usr/local/emhttp/plugins/indexer/indexer.plg
lrwxrwxrwx 1 root root 39 Sep 28 15:11 ntfs-3g-x86_64.plg -> /boot/config/plugins/ntfs-3g-x86_64.plg*
lrwxrwxrwx 1 root root 43 Sep 28 02:07 plgMan.plg -> /usr/local/emhttp/plugins/plgMan/plgMan.plg
lrwxrwxrwx 1 root root 41 Sep 28 15:11 powerdown-x86_64.plg -> /boot/config/plugins/powerdown-x86_64.plg*
lrwxrwxrwx 1 root root 36 Sep 28 15:11 snap-x86_64.plg -> /boot/config/plugins/snap-x86_64.plg*
lrwxrwxrwx 1 root root 45 Sep 28 02:07 sysinfo.plg -> /usr/local/emhttp/plugins/sysinfo/sysinfo.plg
lrwxrwxrwx 1 root root 49 Sep 28 02:07 unRAID-OS.plg -> /usr/local/emhttp/plugins/unRAID-OS/unRAID-OS.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 vendor.plg -> /usr/local/emhttp/plugins/vendor/vendor.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 webGui.plg -> /usr/local/emhttp/plugins/webGui/webGui.plg
lrwxrwxrwx 1 root root 43 Sep 28 02:07 xenMan.plg -> /usr/local/emhttp/plugins/xenMan/xenMan.plg

 

The plugin file for the Apcupsd plugin is not located in the /tmp/ directory, it is at /boot/config/plugins/.

 

I installed your plugin on a newly configured -beta10 server and do not see this issue - it installed correctly.  Tried remove and install again and it worked.  Did not try an 'update'.

 

BTW you can remove the checking for 'network up' at beginning of the plugin.

 

Here's the problem I have and why the network check is in the beginnning of the plugin.  Apcupsd installs the powerdown plugin.  If Apcupsd is installed from plgman, Apcupsd installs and powerdown is installed.  If a user deletes the powerdown plugin from plgman and then does a re-boot, the Apcupsd will fail because it cannot download the powerdown plugin.  That's why I wait on the network.  If a user removes powerdown, both Apcupsd and powerdown will fail to install and there is no way a user knows except to look at the plugins page (They won't).  If they were to have a power failure, their server would never get the signal from the UPS and would not shut down, and I would never hear the end of how bad I am.

 

I'll implement another solution if you have a better suggestion.

[clowrym]

I seem to be getting these when I try and delete a file via OSX network share

 

The file does delete...

 

Sep 28 15:18:06 test shfs/user: shfs_rmdir: rmdir: /mnt/disk1/T_Media/.AppleDB (39) Directory not empty
Sep 28 15:18:30 test shfs/user: shfs_rmdir: rmdir: /mnt/disk2/.TemporaryItems (39) Directory not empty
Sep 28 15:19:40 test shfs/user: shfs_rmdir: rmdir: /mnt/disk1/T_Media/.AppleDB (39) Directory not empty
Sep 28 15:23:50 test shfs/user: shfs_rmdir: rmdir: /mnt/disk1/T_Media/Torrent/Formula.1.2014x11.Hungary.Race.SkyF1HD.720p (39) Directory not empty

[limetech]

Here's the problem I have and why the network check is in the beginnning of the plugin.  Apcupsd installs the powerdown plugin.  If Apcupsd is installed from plgman, Apcupsd installs and powerdown is installed.  If a user deletes the powerdown plugin from plgman and then does a re-boot, the Apcupsd will fail because it cannot download the powerdown plugin.  That's why I wait on the network.  If a user removes powerdown, both Apcupsd and powerdown will fail to install and there is no way a user knows except to look at the plugins page (They won't).  If they were to have a power failure, their server would never get the signal from the UPS and would not shut down, and I would never hear the end of how bad I am.

 

I'll implement another solution if you have a better suggestion.

 

I get that, but probably it's not great to have inter-plugin dependencies.  What if the user does not want the powerdown plugin but does want the apcupsd plugin?  Also I want to get away from the "unRaid-5" method of just plopping PLG files into /boot/config/plugins and then rebooting.  In fact I might add something to break this practice.

 

Anyway we can take up this discussion here:

http://lime-technology.com/forum/index.php?topic=35487.0

 

[sane]

There definitely is a bug with Xen. We have tracked it down and are working to fix.  It affects autostart and shutting down the VMs at array stop.

I assume you know, there is a suggestion that there is a big security bug with the Xen hypervisor, and that's why the AWS Elastic Compute Cloud is 'rebooting'.

 

https://aws.amazon.com/blogs/aws/ec2-maintenance-update/

 

A fix is due to be released 1 Oct, so might like to wait till then.

[jonp]

There definitely is a bug with Xen. We have tracked it down and are working to fix.  It affects autostart and shutting down the VMs at array stop.

I assume you know, there is a suggestion that there is a big security bug with the Xen hypervisor, and that's why the AWS Elastic Compute Cloud is 'rebooting'.

 

https://aws.amazon.com/blogs/aws/ec2-maintenance-update/

 

A fix is due to be released 1 Oct, so might like to wait till then.

Well since they haven't disclosed the details on the bug yet, we will just have to wait to see if we are even affected.  This could be limited to specific types of deployments and may not necessarily affect unraid...

[sane]

Well since they haven't disclosed the details on the bug yet, we will just have to wait to see if we are even affected.  This could be limited to specific types of deployments and may not necessarily affect unraid...

I refer the honourable gentleman to the legislative output of Messrs Murphy and Sons - and to this bug report that's thought to be related to the prob behind the patch.

 

http://www.openwall.com/lists/oss-security/2014/09/24/6

[gfjardim]

Well since they haven't disclosed the details on the bug yet, we will just have to wait to see if we are even affected.  This could be limited to specific types of deployments and may not necessarily affect unraid...

I refer the honourable gentleman to the legislative output of Messrs Murphy and Sons - and to this bug report that's thought to be related to the prob behind the patch.

 

http://www.openwall.com/lists/oss-security/2014/09/24/6

 

If this is the bug, EC2 is especially vulnerable, since it's a publicly available virtualization tool; home VM's shouldn't be easily affected.

[jonp]

Well since they haven't disclosed the details on the bug yet, we will just have to wait to see if we are even affected.  This could be limited to specific types of deployments and may not necessarily affect unraid...

I refer the honourable gentleman to the legislative output of Messrs Murphy and Sons - and to this bug report that's thought to be related to the prob behind the patch.

 

http://www.openwall.com/lists/oss-security/2014/09/24/6

 

If this is the bug, EC2 is especially vulnerable, since it's a publicly available virtualization tool; home VM's shouldn't be easily affected.

Generally speaking, most security bugs like this and heartbleed or otherwise are far less likely to affect unRAID users for a number of reasons.

 

While the bug is the same, the risk factor for an atypical user is exponentially smaller than say a cloud hosting company.  The exposure to the risk is just far less for many obvious (and some not do obvious) reasons.

[LateNight]

Most of my plugins now show up under Stale Plugins. They still work though.

[jbartlett]

I don't see any mention of it but I can't access my disk shares via SMB with beta10 or other shares in which the SMB security is set to Private and my Windows account user has R/W access - No issue with access on beta9.

[dlandon]

Most of my plugins now show up under Stale Plugins. They still work though.

 

It's a problem with Plgman updating plugins.  Tom is aware of it.  It you reboot the plugins will return to the plugin webpage.

[dlandon]

I don't see any mention of it but I can't access my disk shares via SMB with beta10 or other shares in which the SMB security is set to Private and my Windows account user has R/W access - No issue with access on beta9.

 

If you don't have a cache drive, check the shares and change the use cache drive to no.