unRAID Server Release 5.0-rc11 Available


limetech

Recommended Posts

  • Replies 354
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

RC11a is up.  I guess this should say, 'Changes from 5.0-rc11...'

 

"

Changes from 5.0-rc10 to 5.0-rc11a

----------------------------------

- shfs: return correct extended attribute value length

- webGui: for 'FTP user(s)', permit multiple usernames separated by spaces

"

This is NOT a good idea, mentioning this in a release thread.  It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue.  It would NOT be a good idea for others to use this unofficial version, and then want support for it.  Please wait for an official statement from Tom.

Link to comment

RC11a is up.  I guess this should say, 'Changes from 5.0-rc11...'

 

"

Changes from 5.0-rc10 to 5.0-rc11a

----------------------------------

- shfs: return correct extended attribute value length

- webGui: for 'FTP user(s)', permit multiple usernames separated by spaces

"

This is NOT a good idea, mentioning this in a release thread.  It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue.  It would NOT be a good idea for others to use this unofficial version, and then want support for it.  Please wait for an official statement from Tom.

 

Man nothing gets past you guys!  Right this is just -rc11 with a couple bug fixes.  Didn't want to start another multi-page post fest of, "damn another -rc, when's final???"  I have to have some way to distribute these test releases for problems I can't readily reproduce in a timely manner.  Once 5.0 has been released, I am going to adopt a different release scheme where I can quickly post releases that have only one or two changes, and get away from the -beta/-rc suffix scheme.

Link to comment

Yesterday i had 2 more drives redball yesterday.

I was unable to do anything with it since I am out of town. I had the server reboot from and older flash backup (RC5). it came right up all errors went away. I performed a parity check. zero errors. I copied a few GB to each individual disk, verified the copy and then deleted the data. zero errors.

 

I need to upgrade the server again and see if i can recreate the issues.

this will have to wait until i get back in a week or two..

Link to comment

wow Johnm - sounds scary to me.  I would think it's not a hardware issue if you rollback and everything checks out ok.  You list a few systems in your sig, which hardware had this issue with rc11?  What mb, type of ram, sata cards?  It sounds like a driver issue that was changed in recent releases.  In any case, I hope you return soon with a syslog so it can be confirmed.  redball drives are like the plague in unraid world.

Link to comment

Hardware was

X9 SCM

Xeon 1240

RAM (4 GB when a VM and 32 when bare metal)

1x M1015 (with 4 drives)

2x SASLP-MV8 (with 8 drives each)

 

Original crash was under hypervisor. all subsequent reboots were as baremetal.

 

Not having my original syslog is huge. that is the missing key to the issue. i swore i downloaded it to my laptop but i cant find it and it is not on my flash. hopefully there is a clue in the second reboot syslog.

Link to comment

Yesterday i had 2 more drives redball yesterday.

I was unable to do anything with it since I am out of town. I had the server reboot from and older flash backup (RC5). it came right up all errors went away. I performed a parity check. zero errors. I copied a few GB to each individual disk, verified the copy and then deleted the data. zero errors.

 

I need to upgrade the server again and see if i can recreate the issues.

this will have to wait until i get back in a week or two..

 

This is extremely unlikely to have anything to do with a particular OS release!  Disabled drives are caused by hard disk issues or cable issues or controller issues or power issues, almost never by software issues.  It is extremely probable that your RC11 flash drive would have had the same positive results.

 

Two red-balled drives is generally a problem with the controller card that both are connected to, or one had issues and is on an IDE channel (emulated or real) and took down the other, or there was a power issue such as an electrical spike of significant size, or someone was messing with the cables or they were bad or loose.  About the only time I can remember when it was software related, was because of a lost interrupt, which could be because of a motherboard or card BIOS problem or a buggy driver, and this has been extremely rare.

 

The most important syslog is the one that covers the period where the issue happened, so I really hope you do find it.  Now that it is working OK, I suspect we won't be able to see anything in new syslogs.

 

Fellow users, please don't cause panics unnecessarily, before anyone has had time to investigate.  Hard disk issues are just hard disk issues, and happen with every operating system (that accesses hard disks!).

 

This is why I have stayed on rc5. Rc6 and rc8 have reballed one drive for no reason.

Without more information, I would respectfully but strongly recommend you upgrade to RC11, not go back to RC5, not that any of these releases would have anything to do with your red balls.  If we could see the syslogs relevant to those red balls, perhaps we could determine what is happening to that drive.  At this point, I cannot think of any way that there is a connection to any particular release.

 

At some point, it might be best to take this support issue to its own thread, as it is very unlikely to be related to RC11.

Link to comment

Is it intended behaviour the FTP service does not honor user rights and/or share settings ?

Yes that is a limitation at present.

 

Everything gets published and everything is available to each account.

That should not be true in -rc11.  Only the user specified in the "FTP user(s)" field should be allowed access (though that user will have full access as mentioned above).  In -rc11a you can enter a list of users separated by spaces.

 

Prior to -rc11 any user could access via FTP.  The FTP app on the Network Services page along with this functionality was added in rc11 precisely to "lock down" FTP so that only a specific user could access via FTP - otherwise known as a "bandaid solution"  ;)

Link to comment

Everything gets published and everything is available to each account.

That should not be true in -rc11.  Only the user specified in the "FTP user(s)" field should be allowed access (though that user will have full access as mentioned above).  In -rc11a you can enter a list of users separated by spaces.

 

Prior to -rc11 any user could access via FTP.  The FTP app on the Network Services page along with this functionality was added in rc11 precisely to "lock down" FTP so that only a specific user could access via FTP - otherwise known as a "bandaid solution"  ;)

 

You're right, only the ftp specific users get all rights. I circumvented my problem with using it by changing the local root to the desired user share.

 

With all its limitations it's actually exactly enough for what I wanted to do with ftp.

Link to comment

 

 

This is extremely unlikely to have anything to do with a particular OS release! 

 

In general this is the case, but we have seen more then once it was a driver error (or driver error with a certain hardware firmware)  taking out an entire controller. this very system was plagued with the same errors back in 5B6 was it? It did turn out to be a bug.

changing of kernels and drivers can had odd unpredictable (and sometimes hard to replicate) effects.

 

the fact that all of the drives showing issues were on a single SAS plug would make me think bad backplane or loose wire (hard to say wire on system thats been racked for months). the flashdrive passed windows scan disks.

 

the fact that i have now run 2 parity checks (correct off) after the downgrade  with no hardware errors (but yes there are sync errors) has me thinking it is not a hardware issue.

 

this is not my main concern. my concern was that unraid appeared to be correcting parity AFTER a failed Drive/controller. (and yes i could be very wrong about , i need the log files)

 

After downgrading. i have run parity checks twice and will a third time. every time it is showing the same 500ish sync errors each pass

 

the question i have; are these sync errors because unraid adjusted parity after a dropped controller or because files were written to the redballed system and it lost track of them after the system unflagged the drive.

 

Link to comment

This is extremely unlikely to have anything to do with a particular OS release! 

 

In general this is the case, but we have seen more then once it was a driver error (or driver error with a certain hardware firmware)  taking out an entire controller. this very system was plagued with the same errors back in 5B6 was it? It did turn out to be a bug.

 

You are right, that is rare, but possible.  Usually though, it's a known quantity, a specific driver/controller/etc combination, known to be suspect.  You would know if you have a suspect condition.  The other issues you mention do concern me, but I believe they are being reported/discussed elsewhere, so I won't touch them here.

Link to comment

I did the following for this upgrade (after first backing up the flash drive)

 

Copied the files bzimage and bzroot from the zip file to the root of your flash device

Deleted config/passwd

Deleted config/shadow

Deleted config/smbpasswd

Delete the file config/super.dat

Booted up server

re-assign hard drives to their correct device location

The cache disk was already assigned to its correct location

I am not seeing "Stopped Configuration Valid" but rather "Stopped. Initial configuration"

I do not see "MBR: error", or "MBR: unknown"

I have attached a syslog

 

I am getting Blue Balls next to each of the devices (except for cache and flash... they are green)

 

Do I need to check the box "Parity is Valid" and then click "START" next to "Start will record all disk information, bring the array on-line, and start Parity-Sync (if parity is present). The array is immediately available, but is unprotected until Parity-Sync completes."?

 

I did not click on "Identify"

 

tower2_syslog.txt

Link to comment

I did the following for this upgrade (after first backing up the flash drive)

 

Copied the files bzimage and bzroot from the zip file to the root of your flash device

Deleted config/passwd

Deleted config/shadow

Deleted config/smbpasswd

Delete the file config/super.dat

Booted up server

re-assign hard drives to their correct device location

The cache disk was already assigned to its correct location

I am not seeing "Stopped Configuration Valid" but rather "Stopped. Initial configuration"

I do not see "MBR: error", or "MBR: unknown"

I have attached a syslog

 

I am getting Blue Balls next to each of the devices (except for cache and flash... they are green)

 

Do I need to check the box "Parity is Valid" and then click "START" next to "Start will record all disk information, bring the array on-line, and start Parity-Sync (if parity is present). The array is immediately available, but is unprotected until Parity-Sync completes."?

 

I did not click on "Identify"

You didn't need to delete 'super.dat', but no mater.  If you are certain parity is assigned correctly click 'Start'.

Link to comment

I did the following for this upgrade (after first backing up the flash drive)

 

Copied the files bzimage and bzroot from the zip file to the root of your flash device

Deleted config/passwd

Deleted config/shadow

Deleted config/smbpasswd

Delete the file config/super.dat

Booted up server .....

You didn't need to delete 'super.dat', but no mater.  If you are certain parity is assigned correctly click 'Start'.

 

Since the flash drive was backed up, Albin should be able to re-instate the super.dat file.

Link to comment

I did the following for this upgrade (after first backing up the flash drive)

 

Copied the files bzimage and bzroot from the zip file to the root of your flash device

Deleted config/passwd

Deleted config/shadow

Deleted config/smbpasswd

Delete the file config/super.dat

Booted up server .....

You didn't need to delete 'super.dat', but no mater.  If you are certain parity is assigned correctly click 'Start'.

 

Since the flash drive was backed up, Albin should be able to re-instate the super.dat file.

 

I did back up the flash drive, so I just restored config/super.dat and now all the drives are green balled, and I am getting "configuration valid"

 

I originally went from 4.7 to 5.0-beta12a a long time back, and had some issues with permissions.  With this upgrade, I did not see specific instructions for going from 5.0-beta12a to 5.0-rc11, so I thought I may need to get rid of the Super.dat file and doing so might in someway help with my permissions issue (I am only guessing at that though).

 

Should I keep the old super.dat (the one I restored) or should I remove it and do a "start" with out the super.dat file?  I will hold off on starting the array, until I hear back.

 

Thanks for your input on this

 

Albin

Link to comment

I did back up the flash drive, so I just restored config/super.dat and now all the drives are green balled, and I am getting "configuration valid"

 

I originally went from 4.7 to 5.0-beta12a a long time back, and had some issues with permissions.  With this upgrade, I did not see specific instructions for going from 5.0-beta12a to 5.0-rc11, so I thought I may need to get rid of the Super.dat file and doing so might in someway help with my permissions issue (I am only guessing at that though).

 

Should I keep the old super.dat (the one I restored) or should I remove it and do a "start" with out the super.dat file?  I will hold off on starting the array, until I hear back.

 

Thanks for your input on this

 

Albin

Keep it like it is. Your configuration is valid. When you removed super.dat before you made it forget all about your configuration and so it saw everything as new disks. Now you are back to normal.

 

There is a link in the first post of this thread with the release notes. See the section labeled

  • All previous 5.0-beta and 5.0-rc versions including 5.0-rc8a

Specifically, you need to run the the New Permissions Utility. It will take a while. Don't close the browser window until it completes.

 

Link to comment
Specifically, you need to run the the New Permissions Utility. It will take a while. Don't close the browser window until it completes.

 

The problem with running the New Permissions script is that it clobbers everything.  Some applications need ownership/permissions different to those which the script imposes.  For instance, my mail folders don't use the default settings, nor the SqueezeboxServer files.  I'm wary, in particular, of disrupting my mail and so have not run the New Permissions.

 

In any case, there is still something in unRAID which sometimes makes files/directories inaccessible.  For instance, I ran mkvmerge on my Ubuntu desktop, the other evening, writing the output file to a user share on unRAID.  That process completed normally.  I then went to open the share I'd just written to, and I no longer had permission to read it.  I know that all the files are there, including the new one, because I can still access them via disk shares and from a telnet session.

 

I have detailed this problem on the forum in the past, but no one seems to have picked up on it - it also happens when I run jdownloader on the Ubuntu desktop, writing to user shares.

Link to comment

RC11a is up.  I guess this should say, 'Changes from 5.0-rc11...'

 

"

Changes from 5.0-rc10 to 5.0-rc11a

----------------------------------

- shfs: return correct extended attribute value length

- webGui: for 'FTP user(s)', permit multiple usernames separated by spaces

"

This is NOT a good idea, mentioning this in a release thread.  It looks like Tom has created a special version (which may or may not be fully tested) for a single user, in order to test a specific issue.  It would NOT be a good idea for others to use this unofficial version, and then want support for it.  Please wait for an official statement from Tom.

 

Man nothing gets past you guys!  Right this is just -rc11 with a couple bug fixes.  Didn't want to start another multi-page post fest of, "damn another -rc, when's final???"  I have to have some way to distribute these test releases for problems I can't readily reproduce in a timely manner.  Once 5.0 has been released, I am going to adopt a different release scheme where I can quickly post releases that have only one or two changes, and get away from the -beta/-rc suffix scheme.

 

is this available for download? been having some issues with my RC8 install, think I have it all sorted (running a data rebuild and will then do a parity check) and want to upgrade to the latest RC.

Link to comment

Changes from 5.0-rc10 to 5.0-rc11a

----------------------------------

- shfs: return correct extended attribute value length

- webGui: for 'FTP user(s)', permit multiple usernames separated by spaces

 

is this available for download? been having some issues with my RC8 install, think I have it all sorted (running a data rebuild and will then do a parity check) and want to upgrade to the latest RC.

Are you having issues specifically with shfs and extended attributes, or with multiple users and vsftp?  If not, then you should upgrade to RC11, found in the first post of this thread.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.