unRAID Server Release 5.0-beta3 Available

[SSD]

...

Unfortunately something was going wrong with the last reboot. Because of lack of unMENU I tried to reboot via keyboard ALT-CTL-DEL. Didn´t worked instead the server came up with a parity check; still running and no webinterface access.

...

 

The clean shutdown on ctrl-alt-del (or pressing power button on some systems) is due to WeeboTech's (addon) powerdown script / package.  It is not standard feature.  If you press ctrl-alt-del on a stock unRaid install, it will do a dirty boot and come up with a parity check.

[tyrindor]

Has anyone tried 3TB drives with this beta?

 

Do they work yet?

[Benni-chan]

support for >2TB drives will probably come in one of the next betas, but isn't implemented yet. (check changelog and roadmap)

[BRiT]

The Roadmap has >2.1TB drives listed for the 5.1 series, not the 5.0 series.

[Benni-chan]

there is a small bug with the size compute on the webui user share site.

 

i have a share called "TV Shows" and it can't get the size, because it tries to compute for the Folder "TV". The space must be escaped.

[BRiT]

there is a small bug with the size compute on the webui user share site.

 

i have a share called "TV Shows" and it can't get the size, because it tries to compute for the Folder "TV". The space must be escaped.

 

This was also an issue in 5.0beta2 as mentioned here: http://lime-technology.com/forum/index.php?topic=7377.0

 

It looks like /usr/local/emhttp/plugins/webGui/scripts/share_size needs to use the typical shell script double-quote escaping around the variables.

 

In addition to that, the share needs to be escaped when passed to the update.htm page. There is a php function, "escapeshellarg" that can be used. The generation of the link is contained in /usr/local/emhttp/plugins/webGui/ShareList.php at line 59.

 

I attached the two fixed files as a zipfile.

ShareFixes.zip

[BRiT]

If anyone's feeling daring enough, they could try my fixes for computing share usage for shares containing spaces.

 

You need to unzip the attached file in the previous message to the root filesystem "/" of their running unRAID 5.0b3 system. It should overwrite your /usr/local/emhttp/plugins/webGui/scripts/share_size and /usr/local/emhttp/plugins/webGui/ShareList.php files. After that is done, you will need to refresh the web UI by clicking on the topmost "Shares" tab again.

[Benni-chan]

thanks, computing the size works now.

 

[EdgarWallace]

TimeMachine appears to be working well, just running a first backup now.

 

May I ask how you were setting this up? I have a TimeMachine share with 3 backup files for the respective Mac's from my previous 4.7 installation including TM support. This is the well known HOWTO: http://lime-technology.com/forum/index.php?topic=4521.0)

 

With 5.0-Beta3 I exported this same share via AFP (TM enabled) as Private and gave read/write permission for all 3 users.

 

The issue is that the TM volume is not showing up on the desktop, hence TM volume is not accessible.

[sacretagent]

Here's mine

 

http://pastebin.com/C3vfSvDk

 

What is the specific controller card you're using?  It appears like you have 8 hard drives, are they all attached to the LSI card?  Of the 8 drives, looks like 6 are SATA, are the other 2 SCSI?  In other words, I'm asking what drives you have and what ports are they connected to.

Yes, 8 random drives in this test machine, connected to a 1068e (6 drives) and 1064e (2 drives) card.  Two of the drives on the 1068e are SAS, the others are SATA.

 

Ahh, ok.  The two SAS drives show up as:

35000cca009414c54 and

35000cca00940c8f

 

Is that correct?  What actual hard drive model are these?  Can you correlate those strings with anything like the drive model number?  I'm guessing "0094xxxx" are the serial numbers?

 

Sorry for the questions, I haven't tried to use actual SAS drives (just SATA drives connected to SAS controller) - and wondering if it's worthwhile to support SAS drives  

 

Hi Tom,

 

i would continue the support for sas drives if it is not a big issue to add the code

it might be interesting for the people who buy like low end enterprise servers from HP or Dell which has SAS drives and don't have the $$ to go into dedicated storage solutions ...

might be a market there

 

 

edited as my responding ended up in the above quote  

[WingmanNZ]

Here's mine

 

http://pastebin.com/C3vfSvDk

 

What is the specific controller card you're using?  It appears like you have 8 hard drives, are they all attached to the LSI card?  Of the 8 drives, looks like 6 are SATA, are the other 2 SCSI?  In other words, I'm asking what drives you have and what ports are they connected to.

Hi Tom,

 

i would continue the support for sas drives if it is not a big issue to add the code

it might be interesting for the people who buy like low end enterprise servers from HP or Dell which has SAS drives and don't have the $$ to go into dedicated storage solutions ...

might be a market there

Yes, 8 random drives in this test machine, connected to a 1068e (6 drives) and 1064e (2 drives) card.  Two of the drives on the 1068e are SAS, the others are SATA.

 

Ahh, ok.  The two SAS drives show up as:

35000cca009414c54 and

35000cca00940c8f

 

Is that correct?  What actual hard drive model are these?  Can you correlate those strings with anything like the drive model number?  I'm guessing "0094xxxx" are the serial numbers?

 

Sorry for the questions, I haven't tried to use actual SAS drives (just SATA drives connected to SAS controller) - and wondering if it's worthwhile to support SAS drives 

 

Am I right in thinking that unRAID now supports the LSI1068E Br10i card with SATA HDD's connected? for instance, 8x WD 1.5TB EARS ? using the card just as extra SATA ports so to speak?

[astrobyte]

Here's mine

 

http://pastebin.com/C3vfSvDk

 

What is the specific controller card you're using?  It appears like you have 8 hard drives, are they all attached to the LSI card?  Of the 8 drives, looks like 6 are SATA, are the other 2 SCSI?  In other words, I'm asking what drives you have and what ports are they connected to.

 

Yes, 8 random drives in this test machine, connected to a 1068e (6 drives) and 1064e (2 drives) card.  Two of the drives on the 1068e are SAS, the others are SATA.

 

Ahh, ok.  The two SAS drives show up as:

35000cca009414c54 and

35000cca00940c8f

 

Is that correct?  What actual hard drive model are these?  Can you correlate those strings with anything like the drive model number?  I'm guessing "0094xxxx" are the serial numbers?

 

Sorry for the questions, I haven't tried to use actual SAS drives (just SATA drives connected to SAS controller) - and wondering if it's worthwhile to support SAS drives 

 

 

So, two sas drives, which are HP-branded Hitachi parts:

 

Disk1 -

HP/Hitachi Model: HUS154545VLS300

HP Part: 484992-001

WWN: 50000CCA009414C54

Hitachi Part: 0B234455

Hitachi Serial: JMW4X84C

 

Disk2 -

HP/Hitachi Model: HUS154545VLS300

HP Part: 484992-001

WWN: 5000CCA00940C8F4

Hitachi Part: 0B234455

Hitachi Serial: JMW4MHXC

 

From what I know, the WWN is their SAS address (like SCSI address, alternative to SATA port identifier).

 

Syslog for good measure:

http://pastebin.com/gqVCHeyZ

[jamesbaker]

Hi

Which version of Netatalk is being used?

is it 2.0.5 or 2.1.x?

 

also which version of Avahi?

 

Thanks

[Benni-chan]

netatalk is version 2.0.5 (i hope, there will be an update to the 2.1.x version in one of the next updates).

avahi is 0.6.25 as far as i can see (at least that is the version, avahi-daemon gives me back).

[peter_sm]

The share permission issues continue :-) Now on my Hackintosh, the share shows up in Finder, but I can't see anything inside those, so it's the same issue I have on Windows 7.

 

When I activate "New permission" its looks like is not working, if it dose, how can I verify that?

 

 

 

 

Attached a syslog

 

//Peter

syslog-2011-02-03.zip

[Benni-chan]

the "new permissions" script doesn't work for me either.

i used chmod 770 and chown nobody:users manually on my files and can access them just fine

[peter_sm]

the "new permissions" script doesn't work for me either.

i used chmod 770 and chown nobody:users manually on my files and can access them just fine

Did you do that from /mnt/user

and can you tell me the exact command :-)

 

 

[Benni-chan]

i used the commands at /mnt/diskX/SHARENAME/

/mnt/user should be fine, too.

 

chown -Rc nobody:users *
chmod -Rc 770 *

[limetech]

Is it going to be a new beta with a NFS fix soon? if not I can easily go back to 4.7.

 

BR

 

Peter

 

 

Yes later today.

 

Here's a status update.  -beta4 has a number issues corrected that have been reported in this thread.  In particular, to fix the main issue of most IDE drives not be detected, I had to use a different technique to store persistent "slot" identifiers.  This requires a change in the format of the file 'super.dat' (not a big deal).  But... in order to support drives larger than 2TB there will have to be another change to this file (because disk block counts in there are stored as 32-bit unsigned integers and they have to be changed to 64-bit unsigned integers), so I am doing that work now.  Full support for >2TB drives will not be in yet, but this is preliminary work that must be accomplished and this is the best time to do it.  Anyway bottom line is -beta4 is delayed and I'm trying my best to get it out today, but it might slip to tomorrow.

 

[BRiT]

Try the following command, it will take a while to finish.

 

/usr/local/sbin/newperms

 

It should also be noted that there's still a slight issue if it's invoked directly on a share or file with a space in the name. The fix is to place double-quotes "" around $1 on line 11 as such:

 

if [ -e "$1" ] ; then

[Joe L.]

But... in order to support drives larger than 2TB there will have to be another change to this file (because disk block counts in there are stored as 32-bit unsigned integers and they have to be changed to 64-bit unsigned integers), so I am doing that work now.

It sounds encouraging, but it also sounds as if reverting from 4.7+ to a pre 4.7 release of unRAID will be difficult unless you saved a copy of the old super.dat from the older release.

 

Can you perhaps change the name, leave the old super.dat file in place, and create a parallel new super64.dat for the 64 bit identifiers.  At least that way, reverting to 4.6 can use the old file.  

 

I had to run the newperms command at the shell prompt, and none of my shares has a space in their names.  It would only show in top for a fraction of a second.  It takes far longer than that to run on the command line.

 

Joe L.

[bertlmike]

Try the following command, it will take a while to finish.

 

/usr/local/sbin/newperms

 

This worked great for me! Thanks a lot!

[limetech]

But... in order to support drives larger than 2TB there will have to be another change to this file (because disk block counts in there are stored as 32-bit unsigned integers and they have to be changed to 64-bit unsigned integers), so I am doing that work now.

It sounds encouraging, but it also sounds as if reverting from 4.7+ to a pre 4.7 release of unRAID will be difficult unless you saved a copy of the old super.dat from the older release.

 

Can you perhaps change the name, leave the old super.dat file in place, and create a parallel new super64.dat for the 64 bit identifiers.  At least that way, reverting to 4.6 can use the old file.  

 

This only affects 5.0.  If you backed up 'config' directory on the flash then super.dat got backed up along with it.

 

[Stokkes]

Here's a status update.  -beta4 has a number issues corrected that have been reported in this thread.  In particular, to fix the main issue of most IDE drives not be detected, I had to use a different technique to store persistent "slot" identifiers.  This requires a change in the format of the file 'super.dat' (not a big deal).  But... in order to support drives larger than 2TB there will have to be another change to this file (because disk block counts in there are stored as 32-bit unsigned integers and they have to be changed to 64-bit unsigned integers), so I am doing that work now.  Full support for >2TB drives will not be in yet, but this is preliminary work that must be accomplished and this is the best time to do it.  Anyway bottom line is -beta4 is delayed and I'm trying my best to get it out today, but it might slip to tomorrow.

 

 

Looking forward to it!

 

I think the new udev system and my config is just screwy anyway. I installed 5.0b3 on a fresh USB and the same issue with missing drives (SATA) occurred.

 

Definitely looking forward to doing some AFP testing.

[peter_sm]

Try the following command, it will take a while to finish.

 

/usr/local/sbin/newperms

 

This worked great for me! Thanks a lot!

 

Great all my share is visible in my W7 

 

Thanks..

 

//Peter