unRAID Server Release 5.0-rc9 Available

[nars]

Basic tests seems all OK so far with my Realtek 8111F (Asus P8H77-M), same network speed as with rc8, will post again if I find some problem. Thanks.

[Dephcon]

I'm in the second run of pre-clearing a drive I have on advanced RMA from WD.  I'll be upgrading once the 3rd run completes.

[dgaschk]

Quick question:

 

Is running new permissions utility required when upgrading from 5-RC8a?

 

Or is that step only required when upgrading from 4.7?

 

Sent from my Nexus 7 using Tapatalk 2

 

Download | Release Notes

 

In particular, after installing this release, please re-run the "New Permissions" utility. 

[TheDragon]

In particular, after installing this release, please re-run the "New Permissions" utility. 

 

Thanks dgaschk. Apologies for what may seem a silly question. I had seen that in the original post, but I just wanted to check as I also spotted in the release notes:

 

Go to Utils/New Permissions and execute that utility to change file ownership and permission settings. This is necessary for proper operation of the 5.0 security model.

 

The reason for requesting confirmation was since I am running v5 already - thus I assumed (incorrectly it would seem) I would already be using the v5 security model?

 

Ultimately, I just didn't want to screw anything up!!

 

Sent from my Nexus 7 using Tapatalk 2

 

[savestheday]

Regarding the long lease time for DHCP....I've got my server set in my router for Static DHCP.  It's my understanding that this removes the lease time.  Should I still set it as static in unRAID if the router is instructed to give it just this IP?  Is is the mere presence of DHCP on the unRAID server side that causes the media playback glitch? 

[Dephcon]

Regarding the long lease time for DHCP....I've got my server set in my router for Static DHCP.  It's my understanding that this removes the lease time.  Should I still set it as static in unRAID if the router is instructed to give it just this IP?  Is is the mere presence of DHCP on the unRAID server side that causes the media playback glitch?

 

When the lease time expires the server still does a DHCP request to your router to negotiate for a new address.  It's not aware that your router is configured to always assign the same address.

 

Setting a static IP for a server is always a good idea

[mr-hexen]

yup!

 

i set my router to give out DHCP addresses in the 100-150 range. i then manually assign server IP to 1 above router

 

192.168.1.1 = router

192.16.8.1.2 = server

 

never have to worry about conflicts.

[Alex.vision]

Downloaded and testing right now!!

 

Thanks for the hard work Tom.

[SidebandSamurai]

Tom,

 

With out testing RC9 (a,b,c?) I read the release notes for RC9, but have not found any notes about addressing the ability to shut down unRAID from the command line.

 

If unraid is shutdown from the command line, it causes a parity check because the array was not dismounted before shutdown/reboot.  This should be addressed before final, as I would expect the array to be dismounted when a shutdown/reboot command is issued, without having to visit the web interface to shutdown the array first.

 

Thanks for the new RC.  Cant wait to go home and try it!

 

--Sideband Samurai

[dalben]

If you use the power down package from unmenu you can shutdown/start cleanly from the command line.

[madburg]

If you use the power down package from unmenu you can shutdown/start cleanly from the command line.

 

It should be a native behavior and not dependent on a plugin.

[mejutty]

If you use the power down package from unmenu you can shutdown/start cleanly from the command line.

 

It should be a native behavior and not dependent on a plugin.

 

Says who.  If you would like that to work you can request it but by what grounds do you have to say that it should be native.  I'm happy with the way that it works atm I am fully aware of the strartup/shutdown requirements if you can't be bother to follow the process or think it's to hard then don't and put up with the parity checks.

 

As far as I can tell Unraid was designed to be managed via the gui and not via commandline.  As such it is not native to be using a command line to restart/shutdown the system.

[dgaschk]

Command line shutdown is described in the wiki.

[garycase]

As noted above, the Wiki includes the details commands necessary to do a "clean" shutdown -- i.e. unmounting each of the drives (with the "umount" command);  then stopping mdcmd.   

http://lime-technology.com/wiki/index.php/Console#To_cleanly_Stop_the_array_from_the_command_line

 

Note that this is in the "How To's" section of the Unofficial Documentation in the Wiki.

The Official Documentation does NOT discuss any method of stopping the array except by using the Web GUI (as designed).

 

But the best technique is to install UnMenu and the Clean Shutdown package -- this will ensure the array is cleanly shut down whether from the Web GUI, the command line, or by merely pressing the power button on the server.

 

[madburg]

If you use the power down package from unmenu you can shutdown/start cleanly from the command line.

 

It should be a native behavior and not dependent on a plugin.

 

Says who.  If you would like that to work you can request it but by what grounds do you have to say that it should be native.  I'm happy with the way that it works atm I am fully aware of the strartup/shutdown requirements if you can't be bother to follow the process or think it's to hard then don't and put up with the parity checks.

 

As far as I can tell Unraid was designed to be managed via the gui and not via commandline.  As such it is not native to be using a command line to restart/shutdown the system.

 

tisk tisk. Who said I am bothered? I have no issues in this area. I would like to know that should I lose the web gui for any reason I can properly shutdown/reboot via commandline though, without having to install anything other than unRAID itself.

[bonienl]

With "Spin Up" all drives in the array spin up nicely, doing a "Spin Down" after that all drives except the last one (disk9 in my case) are spun down.

 

It looks like the counter is one too short...

 

[SidebandSamurai]

@graycase, @dgaschk,

 

I agree with you but... I don't agree that this should be dependent on a Wiki or Unmenu.

 

@mejutty

The linux native mode is command line.  This operating system does not have a graphic Gui, it uses web services to execute command line commands to make the server software perform functions.  Since unRAID has a NATIVE command line mode, the SHUTDOWN / REBOOT script should accommodate the fact that the array needs to be shutdown and unmounted before shutting down the hardware or rebooting the operating system.

 

This is really important to understand, THIS is a distribution of a server operating system.  ALL server operating systems that I know of, including MICROSOFT WINDOWS provide a command line utility to shutdown / reboot the operating system WHICH includes properly dismounting the file system (in our case its the Unraid file system).

 

@mejutty, @graycase, @dgaschk,

 

Yes, we can fix it our selves using one of the suggestions above.  Lets face it, most people don't read the documentation (in this case the wiki) to make sure BASIC functionality is available to the operating system.  Its like buying an Iron (to iron cloths) only to find out no power cord was provided.  Yes we can install a new power cord, but should we be doing that?

 

I wonder if I reboot the server from the GUI WITHOUT shutting down the array if this will cause a parity check.  If it does cause the parity check, then that also should be fixed, and may be fixed if we can get the shutdown/reboot scripts fixed before release.

 

As it stands, we have had serveral issues which caused the web interface to be unresponsive with only a reboot to fix this problem.  It is only fixed from the command line by issuing a reboot command.  That command should not cause the array to shutdown dirty and cause lengthy parity checks.

 

--Sideband Samurai

 

[MyKroFt]

With "Spin Up" all drives in the array spin up nicely, doing a "Spin Down" after that all drives except the last one (disk9 in my case) are spun down.

 

It looks like the counter is one too short...

 

All of mine say they are spun down but my cache drive, it never spins down because of SAB and SB .....

 

Myk

 

[jaybee]

So to confirm, we had RC9 and RC9a, but are now waiting on an RC9b? What is the ETA for RC9b?

[jaybee]

My concerns are as follows.

 

1: An RC by definition is typically very close to final and should be pretty locked down, with only minor changes made specifically for fixes. I notice each RC we have a different Kernel version, different SAMBA version, different Realtek driver version. Final will never happen if a constant is not maintained as the introduction of new bugs will be forever ongoing.

 

2: What happened to the older bugs and issues talked about like NFS stability and parity speeds and file share problems?

 

3: Bugs have been fixed and further changes made of which we did not even know about until reading the release notes/OP. This does not inspire confidence and relates to point 1 above.

 

4: There is still apparently a requirement for further work with a bug that needs fixing (RC9b).

 

5: We instantly required an RC9a and then an RC9b despite that the hope was for this to relabelled "FINAL" after only a week. Again not inspiring confidence.

 

6: Despite points raised above, we still have no native ability to cleanly shut down the server from the command line. This seems odd to me that this would not be fixed to be native rather than via add ons, especially in light of issues with webgui's hanging and becoming unavailable.

 

7: The new permissions utility is required to be run after upgrading. This sounds like a bodge fix of an unknown underlying problem, or am I interpreting that wrongly?

[Helmonder]

My concerns are as follows.

 

1: An RC by definition is typically very close to final and should be pretty locked down, with only minor changes made specifically for fixes. I notice each RC we have a different Kernel version, different SAMBA version, different Realtek driver version. Final will never happen if a constant is not maintained as the introduction of new bugs will be forever ongoing.

 

2: What happened to the older bugs and issues talked about like NFS stability and parity speeds and file share problems?

 

3: Bugs have been fixed and further changes made of which we did not even know about until reading the release notes/OP. This does not inspire confidence and relates to point 1 above.

 

4: There is still apparently a requirement for further work with a bug that needs fixing (RC9b).

 

5: We instantly required an RC9a and then an RC9b despite that the hope was for this to relabelled "FINAL" after only a week. Again not inspiring confidence.

 

6: Despite points raised above, we still have no native ability to cleanly shut down the server from the command line. This seems odd to me that this would not be fixed to be native rather than via add ons, especially in light of issues with webgui's hanging and becoming unavailable.

 

7: The new permissions utility is required to be run after upgrading. This sounds like a bodge fix of an unknown underlying problem, or am I interpreting that wrongly?

 

wrt 6: Unraid is meant to be shutdown over the webinterface, if you are confident enough in using the console then you should have no problem using ubuntu to shut down the system cleanly.

 

wrt 7: this is a storage system, the change means that security bits need to be changed, that means all files need to be touched and this is what the utility does.

[limetech]

My concerns are as follows.

 

1: An RC by definition is typically very close to final and should be pretty locked down, with only minor changes made specifically for fixes. I notice each RC we have a different Kernel version, different SAMBA version, different Realtek driver version. Final will never happen if a constant is not maintained as the introduction of new bugs will be forever ongoing.

All those changes: kernel (fix write speed slowdown with certain cpu's), samba (fix issue with 3.6.7), Realtek driver (ongoing cluster-f), are to fix bugs or incorrect behavior.  Other changes have to do with fixing issues not in your list.  It's kind of a cascade, replace one component to fix an issue and another issue pops up.  Nature of the beast.

 

2: What happened to the older bugs and issues talked about like NFS stability and parity speeds and file share problems?

All addressed.

 

3: Bugs have been fixed and further changes made of which we did not even know about until reading the release notes/OP. This does not inspire confidence and relates to point 1 above.

So it's better for me to leave bugs in so the whole community sees it?

 

4: There is still apparently a requirement for further work with a bug that needs fixing (RC9b).

Yes, Realtek driver.  Apparently you don't have a Realtek NIC so you don't care if this is fixed.

 

5: We instantly required an RC9a and then an RC9b despite that the hope was for this to relabelled "FINAL" after only a week. Again not inspiring confidence.

Shit happens man.

 

6: Despite points raised above, we still have no native ability to cleanly shut down the server from the command line. This seems odd to me that this would not be fixed to be native rather than via add ons, especially in light of issues with webgui's hanging and becoming unavailable.

The 'powerdown' script has been around forever.  I don't consider further functionality high priority since other methods exist for now.  But I agree this point is debatable, though 99% of users would never need it.

 

7: The new permissions utility is required to be run after upgrading. This sounds like a bodge fix of an unknown underlying problem, or am I interpreting that wrongly?

You are interpreting wrongly.  So what if you have to run the script?  Here's the issue: even though you configure to accept guest connections, and map the guest account to user 'nobody' of the 'users' group, samba insists on not permitting directory traversal for guests unless 'other' (or 'world') read and execute permission is set on a directory.  This is wrong behavior and there's no interest in samba team of fixing this because the workaround is to set 'other' read/execute permissions on directories, which is what the modified 'New Permissions' script does.

 

This kind of belly aching is not constructive.

 

 

[jaybee]

Thanks for the replies. You have put my mind at ease slightly. I am happy with all responses except point 1. I'm still not really feeling the whole "just use current stuff" mentality. As you say, you fix something and then something else breaks...

Anyway, ETA for RC9b? It sounds to me from the above - and I'm thinking this could be too good to be true - that the only current known bug/issue is the one which will be fixed in RC9b? Correct?

Good work. About time I have to say though.

 

EDIT1: Oh and I do have a realtek ethernet port. I have looked at getting an Intel card but never got round to it.

 

EDIT2: The point about you leaving bugs in so the whole community sees it... I didn't mean it like that. Of course I appreciate fixing new things is good, but on an RC number 9... it makes me feel like given enough time, you would go on spotting bugs indefinitely - which may be the case with any software - but it does not really inspire confidence when we are this close to 5 final and still newer stuff is being found. That is all I meant. Maybe it is time to be stubborn and change the minimum possible?

 

[speeding_ant]

Tom - I don't know what you've done.

 

I'm getting peaks of 45-50MB/s writes since this latest update. Previously I'd hit 30MB/s max.

 

Nice work.

[speeding_ant]

Confirmed average speed of writes (constant I/O, 4Gb plus files) has increase at least 5MB/s for me. Very interesting that CPU is working much harder during these writes, compared to any previous releases.

 

I should point out write performance has previously been patchy on my hardware since the 3.x kernel.