unRAID Server release 4.4.2 available

Download.

If it isn't one thing, it's another.

This patch release contains a bug fix for Windows reporting, "no network provider accepted the given network" when you try to browse a user share with user-level security enabled, after having first already browsed the share.  (Refer to problem reported in the 4.4.1 announcement thread.)

This appears to be a Samba bug.  What happened is this... Release 4.4 used Samba version 3.2.3 (and earlier unRAID releases used earlier Samba version).  We have been working on Active Directory support, and for that purpose we have been using Samba version 3.2.5.  Well there were a couple serious bugs in 4.4 which needed to be fixed, hence need for 4.4.1 release.  Somehow we built 4.4.1 with Samba version 3.2.5.  Well 3.2.5 causes this network security bug (but only when interacting with FUSE file system, ie, user shares).

So this release, 4.4.2, we restored Samba version 3.2.3 and it seems to solve the problem. 

unRAID Server 4.4.2 Release Notes
=================================

Changes from 4.4.1 to 4.4.2
---------------------------

Bug fix:
- Fix problem where windows reports "no network provider accepted the given network" when accessing user shares with user level security enabled. [fixed by reverting back to Samba version 3.2.3.]


Changes from 4.4 to 4.4.1
-------------------------

New feature:
- Added NFS share export controls.

Bug fixes:
- Fixed manual DNS Server IP address entry when setting "Obtain IP Address Automatically" is set to "yes".
- Fixed problem introduced in 4.4 where custom timezone is incorrect following boot.
- Fixed problem introduced in 4.4 which casued split-level to work incorrectly.
- Changed 'pseudo permissions' for the Flash device (hopefully got it right this time).


Upgrade Instructions (Please Read Carefully)
============================================

If you are currently running unRAID Server 4.2-beta1 or higher (including 4.2.x 'final'), please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot

If you are currently running unRAID server 4.0 or 4.1, please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot
    syslinux.cfg
    menu.c32
    memtest

This can be done either by plugging the Flash into your PC or, by copying the files to the 'flash' share on your running server.  The server must then be rebooted.

If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade:

1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later.

2. Shut down your server, remove the Flash and plug it into your PC.

3. Right-click your Flash device listed under My Computer and select Properties.  Make sure the volume label is set to "UNRAID" (without the quotes) and click OK.  You do NOT need to format the Flash.

4. Copy the files from the new release to the root of your Flash device.

5. Right-click your Flash device listed under My Computer and select Eject.  Remove the Flash, install in your server and power-up.

6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot.

7. Go back to the 'Main' page and your devices should appear correctly.  You may now Start the array.


If you are installing this release to a new Flash, please refer to instructions on our website at:

http://www.lime-technology.com/wordpress/?page_id=19

This 4.4.2 release seems to fix the issue that was broken in 4.4.1 when  connecting to a user-share from Windows with user-security is enabled.

Joe L.

Torrent Available

http://linuxtracker.org/index.php?page=torrent-details&id=57da82b44cd733774d62d21b932c2546edf430b8

This can be done either by plugging the Flash into your PC or, by copying the files to the 'flash' share on your running server.  The server must then be rebooted.

Copying the bzroot and bzimage files over from my XP box onto the running server, and I'm getting an "Access Denied, Make sure that the disk is not full or write protected and the file is not currently in use" error for the bzimage file.  The flash share is set to export read/write.

I'm upgrading from 4.4 to 4.4.2

Am I going to have to power down and put the flash in the PC for this, or am I doing something really stupid (again)?

I've found that the problem is only when copying over existing files. Delete them from the flash first. Then the copy should work.

Thanks for that.  Sorted.

I've been noticing that my browser is throwing up some javascript errors when performing some actions.  Appears to be down to the disabling of the form when refresh is triggered.  I'm guessing that it's nothing to worry about (as long as I don't click any other buttons whilst it's refreshing), but it's worth noting.

Tom -

I have a tool that enables me to selectively spin down any drive in my array.  This is handy for when I am going to bed or, like today, if I am running with an open case trying to fix a problem and don't want the drives to overheat.  With version 4.3.3, which depended on the drive to keep track of sleeping state, this worked great. 

I think that other users have similar tools that either spin up or spin down a disk so that it works with their media players.

But now with the 4.4 releases, I notice now that if I refresh the emhttp web site, that it spins all the drives up.  It presumably thinks they should be spun up because it is tracking their spun up status.  Is there a way that my tool can spin down a disk in a way that unRAID will know and not try to spin it back up?

Thanks

I've found that the problem is only when copying over existing files. Delete them from the flash first. Then the copy should work.

This is the bug fixed in 4.4.1 (4.4.2):

- Changed 'pseudo permissions' for the Flash device (hopefully got it right this time).

Thanks for that.  Sorted.

 

I've been noticing that my browser is throwing up some javascript errors when performing some actions.  Appears to be down to the disabling of the form when refresh is triggered.  I'm guessing that it's nothing to worry about (as long as I don't click any other buttons whilst it's refreshing), but it's worth noting.

Which browser?

Tom -

 

I have a tool that enables me to selectively spin down any drive in my array.  This is handy for when I am going to bed or, like today, if I am running with an open case trying to fix a problem and don't want the drives to overheat.  With version 4.3.3, which depended on the drive to keep track of sleeping state, this worked great. 

 

I think that other users have similar tools that either spin up or spin down a disk so that it works with their media players.

 

But now with the 4.4 releases, I notice now that if I refresh the emhttp web site, that it spins all the drives up.  It presumably thinks they should be spun up because it is tracking their spun up status.  Is there a way that my tool can spin down a disk in a way that unRAID will know and not try to spin it back up?

 

Thanks

 

Right, emhttp thinks the drive is still spun up, so when it goes to read the temperatures, drives spin up.

What is the nature of your 'spin down' utility?  I think the way to solve this would be to add an individual disk spin down/up control in emhttp.  You could then use 'wget' to control disk spin up/down, eg, something like this:

'wget tower/diskSpindown=2' to spin down disk2,

'wget tower/diskSpinup=0' to spin up parity

Would this work for you?

I think that would work!  Might want to add an option to do them all.  (e.g., diskSpindown=*, diskSpinup=*).

The other option would be to check if they are already sleeping (via hdparm -C) before you decide whether to get the temperature.  (BTW, Western Digital drives (at least the ones that I have that are 500G+), do not have to spin up in order to get their temperature.)

This is part of the myMain plugin to the unmenu tool (See 2 screendhots below).  If you click the hyperlink in the "Spin" column, the drive's spin up state will toggle.  If you click the "Up" or "Dn"  in that column on the total row, it will spin them all up or spin them all down.

See here and here.

This screenshot is a little dated.  The current formatting is more similar to the screnshot above.

(BTW, Western Digital drives (at least the ones that I have that are 500G+), do not have to spin up in order to get their temperature.)

I've heard of a couple of others too.

I'm working on a monitoring application, and realized I had to add a checkbox for each drive, to "Get drive temperature when spun down."  You can also test it programatically with a spindown, wait, check to see if spundown, check temp, and then check to see if it spun back up.  It isn't perfect, but you will never get a false positive, only a false negative, as to the ability to turn temperature causing a spin-up.

Tom -

 

I have a tool that enables me to selectively spin down any drive in my array.  This is handy for when I am going to bed or, like today, if I am running with an open case trying to fix a problem and don't want the drives to overheat.  With version 4.3.3, which depended on the drive to keep track of sleeping state, this worked great. 

 

I think that other users have similar tools that either spin up or spin down a disk so that it works with their media players.

 

But now with the 4.4 releases, I notice now that if I refresh the emhttp web site, that it spins all the drives up.  It presumably thinks they should be spun up because it is tracking their spun up status.  Is there a way that my tool can spin down a disk in a way that unRAID will know and not try to spin it back up?

 

Thanks

 

 

Right, emhttp thinks the drive is still spun up, so when it goes to read the temperatures, drives spin up.

 

What is the nature of your 'spin down' utility?  I think the way to solve this would be to add an individual disk spin down/up control in emhttp.  You could then use 'wget' to control disk spin up/down, eg, something like this:

 

'wget tower/diskSpindown=2' to spin down disk2,

'wget tower/diskSpinup=0' to spin up parity

 

Would this work for you?

Tom,

We "read" a random block of data from the drive to spin it up.  Your tracking of the disk read statistics will catch that and know to reset its spin-down-timer.

In the unmenu web interface described by bjp999, we use the exact same command as you to spin down drives:

/usr/sbin/hdparm -y /dev/xxx

Problem is, emhttp is unaware we have spun them down, as it is only tracking the timestamp of the last "write" to the disk. It has no idea we have spun it down to eliminate extra power consumption/heat generation.

emhttp would be improved if it used "hdparm -C" first (or its equivalent), before re-reading disk temperature to verify if the drive is already sleeping.  If already sleeping, update its internal timer to show the sleeping state for that drive, and return "*" for the temperature.

Your "wget" suggestions would work well to let you know we want to spin down a drive, but it gets a tiny bit more complicated if a password is needed to access the web-management spin-up/spin-down URL links.  If you could not prompt for a password if the "wget" is invoked on "localhost" for those control links, it would work perfectly.    That way, no matter what the host name might be, and no matter if a name-server has been defined, and even if a "root" password is assigned, the "localhost"alias would still work without an additional prompt for login/password.

Joe L.

Tom,

 

We "read" a random block of data from the drive to spin it up.  Your tracking of the disk read statistics will catch that and know to reset its spin-down-timer.

 

In the unmenu web interface described by bjp999, we use the exact same command as you to spin down drives:

 

/usr/sbin/hdparm -y /dev/xxx

 

Problem is, emhttp is unaware we have spun them down, as it is only tracking the timestamp of the last "write" to the disk. It has no idea we have spun it down to eliminate extra power consumption/heat generation.

   

emhttp would be improved if it used "hdparm -C" first (or its equivalent), before re-reading disk temperature to verify if the drive is already sleeping.  If already sleeping, update its internal timer to show the sleeping state for that drive, and return "*" for the temperature.

There's commented-out code in there now that does this left over from when we programmed the spin down in the drives themselves, which proved to be unreliable, hence emhttp monitoring of activity to do this.  In next beta, we'll add the 'hdparm -C' check in there & see if this causes problems with any other users.

Your "wget" suggestions would work well to let you know we want to spin down a drive, but it gets a tiny bit more complicated if a password is needed to access the web-management spin-up/spin-down URL links.   If you could not prompt for a password if the "wget" is invoked on "localhost" for those control links, it would work perfectly.    That way, no matter what the host name might be, and no matter if a name-server has been defined, and even if a "root" password is assigned, the "localhost"alias would still work without an additional prompt for login/password.

 

Joe L.

Yes, I see what you're getting at, but perhaps this is a security hole?  I'm thinking of exposing a whole range of commands executable via 'wget' method.

Tom,

 

We "read" a random block of data from the drive to spin it up.  Your tracking of the disk read statistics will catch that and know to reset its spin-down-timer.

 

In the unmenu web interface described by bjp999, we use the exact same command as you to spin down drives:

 

/usr/sbin/hdparm -y /dev/xxx

 

Problem is, emhttp is unaware we have spun them down, as it is only tracking the timestamp of the last "write" to the disk. It has no idea we have spun it down to eliminate extra power consumption/heat generation.

   

emhttp would be improved if it used "hdparm -C" first (or its equivalent), before re-reading disk temperature to verify if the drive is already sleeping.  If already sleeping, update its internal timer to show the sleeping state for that drive, and return "*" for the temperature.

There's commented-out code in there now that does this left over from when we programmed the spin down in the drives themselves, which proved to be unreliable, hence emhttp monitoring of activity to do this.  In next beta, we'll add the 'hdparm -C' check in there & see if this causes problems with any other users.

 

Your "wget" suggestions would work well to let you know we want to spin down a drive, but it gets a tiny bit more complicated if a password is needed to access the web-management spin-up/spin-down URL links.   If you could not prompt for a password if the "wget" is invoked on "localhost" for those control links, it would work perfectly.    That way, no matter what the host name might be, and no matter if a name-server has been defined, and even if a "root" password is assigned, the "localhost"alias would still work without an additional prompt for login/password.

 

Joe L.

 

Yes, I see what you're getting at, but perhaps this is a security hole?  I'm thinking of exposing a whole range of commands executable via 'wget' method.

Exposing commands to perform other tasks is a great idea, but not at the expense of security.   That is why I suggested "localhost"

A FAR better method, in my opinion, would be something similar to the /proc interface.   Is it possible to have a user-space program with a /proc entry?   (I don't think so)

Fortunately, we're pretty open as to how we communicate with emhttp.   I'm fairly familiar with the old SYSV IPC of shared memory, semaphores, message queues...  But they would be a bit tricky to impliment any of those at the shell level for people just trying to spin up a drive.

Easier would just be a named pipe.  If emhttp opened up a named pipe, it could read it for instructions from users.  (with a non-blocking read)   We could even send a USER1 signal to wake emhttp up when we wrote something to get its attention. (as another possibility, instead of polling the "read" end of the pipe)

A simple parser could take the same diskSpindown=2

string and act on it.   From the shell, a simple

echo 'diskSpindown=2' > /tmp/unRAID_API_pipe

would do it.  This might be far easier than using wget, and way fewer security holes.

For the short term, I'm not sure there will be huge security issues with disk-spinup/disk-spindown through wget.  As long as the emhttp does reasonable buffer bounds, url length, and value checking and can't be crashed by a malicious URL the worst that will happen is somebody spins down a drive before the time-limit expires.  It will still spin back up on the next read of a block.   Other functions for "Stop Array", or "Format" would have a lot more potential for abuse.   Those I would not want accessible externally without going through the root login process (if a password has been set)

In any case, thanks for considering the problem and giving it some thought.  If enough of the commands were exposed, eventually, the core logic would be one process, and your web-server-interface another.  That way, a "php" look-alike for emhttp could call the underlying "API" (whatever it was) if somebody was so inclined.   The core-logic would do the same license check and impliment as needed the correct features for the license present.   

The hdparm code to know if a drive is already sleeping probably is a good thing.  It would prevent a drive from being spun up needlessly.

Also, please... in future releases, add in the missing /usr/lib/libstdc++.so.6.0.8 library needed by the 3.58 version of smartctl you are currently including.  A lot of users are getting "smarter" and using the SMART reports to track their drive's health.  it is a real nice feature of the myMain web-interface and VERY useful for everybody.  Without the library, the smartctl program just will not work, and it is currently broken in 4.4.2.

Joe L.

I second the notion that the wget method has security issues.  Checking source for localhost is one way to limit it, but as you know, source IP can be spoofed.

Perhaps an expansion to the /proc/mdcmd interface?

All of them, however, will have risks depending on the command set that is available to them.  One option is to not enable anything that could be destructive.  Another, is to allow some potentially destructive commands, but have them disabled by default, and they have to be enabled by a config option in unRAID for users that want to enable them.

That way, a "php" look-alike for emhttp could call the underlying "API" (whatever it was) if somebody was so inclined.

Me would be so inclined! ;D

In next beta, we'll add the 'hdparm -C' check in there & see if this causes problems with any other users.

Excellent!  I do not think this will have a downside but I guess we'll find out for sure.

... I'm thinking of exposing a whole range of commands executable via 'wget' method.

This would be really useful!  I will leave it to you Linux gurus to debate the best mechanism, be it wget or something else.

I've found that the problem is only when copying over existing files. Delete them from the flash first. Then the copy should work.

I also get that the file is currently in use in 4.4. The bzimage and bzroot files seem to be hidden on all of my machines. Are there any commands that let me see the hidden files on the flash drive from an XP machine over the network so I can upgrade?

The bzimage and bzroot files seem to be hidden on all of my machines. Are there any commands that let me see the hidden files on the flash drive from an XP machine over the network so I can upgrade?

If I understand you correctly you would just need to:

1. On your XP machine, in Windows Explorer, browse to the flash share on your unRAID box.

2. Select tools / folder options / view / show hidden files & folders - Apply

For what it's worth, Wget supports username/password Basic authentication on the command line or via .wgetrc

HTTP options:
       --http-user=user
       --http-password=password
           Specify the username user and password password on an HTTP server.
           According to the type of the challenge, Wget will encode them using
           either the "basic" (insecure) or the "digest" authentication
           scheme.

           Another way to specify username and password is in the URL itself.
           Either method reveals your password to anyone who bothers to run
           "ps".  To prevent the passwords from being seen, store them in
           .wgetrc or .netrc, and make sure to protect those files from other
           users with "chmod".  If the passwords are really important, do not
           leave them lying in those files either---edit the files and delete
           them after Wget has started the download.

The bzimage and bzroot files seem to be hidden on all of my machines. Are there any commands that let me see the hidden files on the flash drive from an XP machine over the network so I can upgrade?

 

If I understand you correctly you would just need to:

 

1. On your XP machine, in Windows Explorer, browse to the flash share on your unRAID box.

2. Select tools / folder options / view / show hidden files & folders - Apply

 

 

The option you want to turn off is tools / folder options / view / Hide protected operating system files

Cheers,

Ronin

The bzimage and bzroot files seem to be hidden on all of my machines. Are there any commands that let me see the hidden files on the flash drive from an XP machine over the network so I can upgrade?

 

If I understand you correctly you would just need to:

 

1. On your XP machine, in Windows Explorer, browse to the flash share on your unRAID box.

2. Select tools / folder options / view / show hidden files & folders - Apply

 

 

 

The option you want to turn off is tools / folder options / view / Hide protected operating system files

 

Cheers,

Ronin

That worked. Thanks!

Thanks for that.  Sorted.

 

I've been noticing that my browser is throwing up some javascript errors when performing some actions.  Appears to be down to the disabling of the form when refresh is triggered.  I'm guessing that it's nothing to worry about (as long as I don't click any other buttons whilst it's refreshing), but it's worth noting.

 

Which browser?

IE7

Besides the problem i wrote about here - http://lime-technology.com/forum/index.php?topic=3114.msg26053#msg26053 there is something else i consider a bug. When the array is stopped and the disks are spun down and you try to start the array it will show some of disks unformatted (i guess it won't manage to spin them up in time and think the filesystem is broken).

I saw this same behavior as well the very first time I booted into 4.4.2 last weekend.  I has not happened since then.