limetech

Version 6.3.0-rc9 Release Notes

Recommended Posts

Hi squid!  Thanks for the response, but yes... I have done my "Due Dilligence"    UD developer is pointing me this way:

 

I posted on the rc9 post and this is Tom's response:

 

If it says "wrong" it means the csrf_token is being included but its value is stale.  This would happen, for example, if you had a browser window open and there is some javascript doing some kind of periodic ajax call to the server (like what webGui does to update dashboard), and then the server is rebooted.  If you don't refresh the browser window then the token held in the browser page will not match the newly generated token which is generated as system boot.

 

Could this be your problem?

 

Beautiful response from TOM!  This could very well be my issue and let me tell you why I think so..

 

Since updating to the new rc9 there have been a few serious unrelated issues occurring on my server so I now keep the logging window open at all times to monitor events.  After the updates to UD & PreClear Disks, I rebooted my server, but left my logging window open.  I also launched my IMPI Viewer to monitor reboot routine.  When unRAID OS returned, I mounted disks and refreshed the logging window, once refreshed, log events began popping in including errors.  Since then, I've uninstalled both plugins, rebooted and the like, but errors wont go away.  I use firefox primarily if that matters.

 

 

*Update*

Can you boot in the safe mode and install UD and see if the errors occur then?

 

Uninstalled UD plugin, booted into safe mode and got the following csrf errors, see 18:02:35.  I also included full syslog from Safe Mode boot

 

Feb  2 18:02:29 Tower kernel: br0: port 1(eth0) entered blocking state
Feb  2 18:02:29 Tower kernel: br0: port 1(eth0) entered forwarding state
Feb  2 18:02:31 Tower ntpd[1724]: Listen normally on 3 br0 192.168.1.25:123
Feb  2 18:02:31 Tower ntpd[1724]: new interface(s) found: waking up resolver
Feb  2 18:02:35 Tower root: error: webGui/include/ProcessStatus.php: wrong csrf_token
Feb  2 18:02:36 Tower root: error: webGui/include/ProcessStatus.php: wrong csrf_token
Feb  2 18:02:36 Tower emhttp: shcmd (18): rmmod md-mod |& logger
Feb  2 18:02:36 Tower kernel: md: unRAID driver removed
Feb  2 18:02:36 Tower emhttp: shcmd (19): modprobe md-mod super=/boot/config/super.dat |& logger
Feb  2 18:02:36 Tower kernel: md: unRAID driver 2.7.1 installed
Feb  2 18:02:36 Tower emhttp: Pro key detected, GUID: 058F-6387-0000-000079010148 FILE: /boot/config/Pro.key

 

 

***Bump***

Anymore on this, or am I stuck?

 

If you booted in safe mode, this has to relate to unRAID and not plugins.  I would post this on the rc9 release post along with your diagnostics.

 

As Tom has said, the wrong csrf_token is from a stale csrf_token that can happen from a web page needing to be refreshed.

A wrong csrf (assuming that Unassigned Devices doesn't have any hardcoded anywhere, and I would be shocked if it did -> everyone would be seeing this) is generally from a stale browser session open after a reboot.

 

Note that this browser session can be on any device.  If you've got your phone's browser sitting on the UD screen and then reboot the server, then this stuff is going to get generated until you reload / refresh your browser in the phone.

 

Not saying that its impossible that this isn't LT's issue, but since no one else is seeing it, the odds state that you've got a browser open somewhere sitting idle and continually updating the stats for UD.

 

He is also reporting it on the preclear plugin.

Don't both preclear and UD sit on the "Main" tab?  With refresh of the UI turned on, both those plugins will gather whatever info they want from their support php files, and another browser anywhere on the network will generate those errors.

Share this post


Link to post
Share on other sites

I know lots of people want this issue resolved but it's not a 6.3.0 "pre-release issue", though if someone in the linux community finds a driver bug and pushes a fix upstream it would show up first in a pre-release because we keep up to date with the latest kernel.  Speaking of kernel, upcoming 6.3.0 is now on 4.9.7.

 

This issue is almost certainly a problem with the card's bios.  Probably there are not enough people complaining to Supermicro for them to care about it.

 

Why would it be the bios ? These cards have worker without a problem for years.. driver issue seems more likely no ?

 

 

Verzonden vanaf mijn iPhone met Tapatalk

 

From what I understand the issue presents itself after changing h/w: eg, different motherboard, adding controller, adding device(s) etc.  Is that not the case?

 

In my case only if you view adding 5in3 drive cages... adding a few of them; i was already using 1 of the exact same case and i added three of them..

 

 

Verzonden vanaf mijn iPhone met Tapatalk

Share this post


Link to post
Share on other sites

Hi squid!  Thanks for the response, but yes... I have done my "Due Dilligence"    UD developer is pointing me this way:

 

I posted on the rc9 post and this is Tom's response:

 

If it says "wrong" it means the csrf_token is being included but its value is stale.  This would happen, for example, if you had a browser window open and there is some javascript doing some kind of periodic ajax call to the server (like what webGui does to update dashboard), and then the server is rebooted.  If you don't refresh the browser window then the token held in the browser page will not match the newly generated token which is generated as system boot.

 

Could this be your problem?

 

Beautiful response from TOM!  This could very well be my issue and let me tell you why I think so..

 

Since updating to the new rc9 there have been a few serious unrelated issues occurring on my server so I now keep the logging window open at all times to monitor events.  After the updates to UD & PreClear Disks, I rebooted my server, but left my logging window open.  I also launched my IMPI Viewer to monitor reboot routine.  When unRAID OS returned, I mounted disks and refreshed the logging window, once refreshed, log events began popping in including errors.  Since then, I've uninstalled both plugins, rebooted and the like, but errors wont go away.  I use firefox primarily if that matters.

 

 

*Update*

Can you boot in the safe mode and install UD and see if the errors occur then?

 

Uninstalled UD plugin, booted into safe mode and got the following csrf errors, see 18:02:35.  I also included full syslog from Safe Mode boot

 

Feb  2 18:02:29 Tower kernel: br0: port 1(eth0) entered blocking state
Feb  2 18:02:29 Tower kernel: br0: port 1(eth0) entered forwarding state
Feb  2 18:02:31 Tower ntpd[1724]: Listen normally on 3 br0 192.168.1.25:123
Feb  2 18:02:31 Tower ntpd[1724]: new interface(s) found: waking up resolver
Feb  2 18:02:35 Tower root: error: webGui/include/ProcessStatus.php: wrong csrf_token
Feb  2 18:02:36 Tower root: error: webGui/include/ProcessStatus.php: wrong csrf_token
Feb  2 18:02:36 Tower emhttp: shcmd (18): rmmod md-mod |& logger
Feb  2 18:02:36 Tower kernel: md: unRAID driver removed
Feb  2 18:02:36 Tower emhttp: shcmd (19): modprobe md-mod super=/boot/config/super.dat |& logger
Feb  2 18:02:36 Tower kernel: md: unRAID driver 2.7.1 installed
Feb  2 18:02:36 Tower emhttp: Pro key detected, GUID: 058F-6387-0000-000079010148 FILE: /boot/config/Pro.key

 

 

***Bump***

Anymore on this, or am I stuck?

 

If you booted in safe mode, this has to relate to unRAID and not plugins.  I would post this on the rc9 release post along with your diagnostics.

 

As Tom has said, the wrong csrf_token is from a stale csrf_token that can happen from a web page needing to be refreshed.

A wrong csrf (assuming that Unassigned Devices doesn't have any hardcoded anywhere, and I would be shocked if it did -> everyone would be seeing this) is generally from a stale browser session open after a reboot.

 

Note that this browser session can be on any device.  If you've got your phone's browser sitting on the UD screen and then reboot the server, then this stuff is going to get generated until you reload / refresh your browser in the phone.

 

Not saying that its impossible that this isn't LT's issue, but since no one else is seeing it, the odds state that you've got a browser open somewhere sitting idle and continually updating the stats for UD.

 

He is also reporting it on the preclear plugin.

Don't both preclear and UD sit on the "Main" tab?  With refresh of the UI turned on, both those plugins will gather whatever info they want from their support php files, and another browser anywhere on the network will generate those errors.

 

In looking at the UD code, the function

detect_usb_disk_change()

is fired every 5 sec to check for usb device changes.  You can verify you have the latest version of this plugin by looking at the beginning of the file on your server:

 

less /usr/local/emhttp/plugins/unassigned.devices/UnassignedDevices.php

 

The beginning of the code should look like:

 

<?PHP
$plugin = "unassigned.devices";
require_once("plugins/${plugin}/include/lib.php");
require_once("webGui/include/Helpers.php");
$config_file = "/boot/config/plugins/{$plugin}/{$plugin}.cfg";
$var = parse_ini_file("state/var.ini");
$csrf_token = $var['csrf_token'];

 

Looks to me that it's properly handling the csrf_token.  Are you 100% sure there is not another browser window opened somewhere sitting on the UD page or Main page?

Share this post


Link to post
Share on other sites

I know lots of people want this issue resolved but it's not a 6.3.0 "pre-release issue", though if someone in the linux community finds a driver bug and pushes a fix upstream it would show up first in a pre-release because we keep up to date with the latest kernel.  Speaking of kernel, upcoming 6.3.0 is now on 4.9.7.

 

This issue is almost certainly a problem with the card's bios.  Probably there are not enough people complaining to Supermicro for them to care about it.

 

Why would it be the bios ? These cards have worker without a problem for years.. driver issue seems more likely no ?

 

 

Verzonden vanaf mijn iPhone met Tapatalk

 

From what I understand the issue presents itself after changing h/w: eg, different motherboard, adding controller, adding device(s) etc.  Is that not the case?

 

In my case only if you view adding 5in3 drive cages... adding a few of them; i was already using 1 of the exact same case and i added three of them..

 

 

Verzonden vanaf mijn iPhone met Tapatalk

 

There might be something marginal about your cages: defective connector, cold solder joint, etc.  Maybe something marginal with the controller where the signals passing through another connector cause just enough attenuation on some data line.  Maybe your PSU is right on the edge.  Alternately there might have been a kernel/driver change that accounts for this.  But if you change 2 things (h/w and s/w) how can you deduce the culprit?  You have to restore both to a known working state, verify it still works, then change just one thing at a time.

Share this post


Link to post
Share on other sites

There might be something marginal about your cages: defective connector, cold solder joint, etc.  Maybe something marginal with the controller where the signals passing through another connector cause just enough attenuation on some data line.  Maybe your PSU is right on the edge.  Alternately there might have been a kernel/driver change that accounts for this.  But if you change 2 things (h/w and s/w) how can you deduce the culprit?  You have to restore both to a known working state, verify it still works, then change just one thing at a time.

 

Agree with changing just one thing, but these errors seem to be more and more frequent and affecting more users with the latest kernels, both on the SASLP and SAS2LP, since both use the same driver my money is on that.

Share this post


Link to post
Share on other sites

I had problems with my Controller nearly weekly all of the sudden and then I swapped out my Power Supply then all was good again without an error. I've been error free for several months and all I did was swap out my Corsair CX400 to a Corsair AX760.

Share this post


Link to post
Share on other sites

In looking at the UD code, the function

detect_usb_disk_change()

is fired every 5 sec to check for usb device changes.  You can verify you have the latest version of this plugin by looking at the beginning of the file on your server:

 

less /usr/local/emhttp/plugins/unassigned.devices/UnassignedDevices.php

 

The beginning of the code should look like:

 

<?PHP
$plugin = "unassigned.devices";
require_once("plugins/${plugin}/include/lib.php");
require_once("webGui/include/Helpers.php");
$config_file = "/boot/config/plugins/{$plugin}/{$plugin}.cfg";
$var = parse_ini_file("state/var.ini");
$csrf_token = $var['csrf_token'];

 

Looks to me that it's properly handling the csrf_token.  Are you 100% sure there is not another browser window opened somewhere sitting on the UD page or Main page?

 

No I'm not gonna say that I'm 100% sure!  I do check my server from time to time from peripheral devices.  Seems like this issue is specific to me, so I will lurk around and try to figure out where my server is going wrong.

 

Thanks for everyone's assistance with my problem.  Community support is great here in unRAID forums :)

Share this post


Link to post
Share on other sites

There might be something marginal about your cages: defective connector, cold solder joint, etc.  Maybe something marginal with the controller where the signals passing through another connector cause just enough attenuation on some data line.  Maybe your PSU is right on the edge.  Alternately there might have been a kernel/driver change that accounts for this.  But if you change 2 things (h/w and s/w) how can you deduce the culprit?  You have to restore both to a known working state, verify it still works, then change just one thing at a time.

 

Agree with changing just one thing, but these errors seem to be more and more frequent and affecting more users with the latest kernels, both on the SASLP and SAS2LP, since both use the same driver my money is on that.

 

I had two SAS2LP running fine in 5.0.6 for many years, then when I moved to 6.x, the problem appeared.  I wrestled with it for a bit (updated BIOS, etc.) and ultimately swapped the cards out for Dell HV52W PERC H310 controller cards and have had 0 issues since.

 

It was a while back, but I don't recall any other changes in hardware at the time.  Seems unlikely since if I'm going to make the jump from 5.x to 6.x, I would have kept everything else as stable as possible.

 

Share this post


Link to post
Share on other sites

There might be something marginal about your cages: defective connector, cold solder joint, etc.  Maybe something marginal with the controller where the signals passing through another connector cause just enough attenuation on some data line.  Maybe your PSU is right on the edge.  Alternately there might have been a kernel/driver change that accounts for this.  But if you change 2 things (h/w and s/w) how can you deduce the culprit?  You have to restore both to a known working state, verify it still works, then change just one thing at a time.

 

Agree with changing just one thing, but these errors seem to be more and more frequent and affecting more users with the latest kernels, both on the SASLP and SAS2LP, since both use the same driver my money is on that.

 

I had two SAS2LP running fine in 5.0.6 for many years, then when I moved to 6.x, the problem appeared.  I wrestled with it for a bit (updated BIOS, etc.) and ultimately swapped the cards out for Dell HV52W PERC H310 controller cards and have had 0 issues since.

 

It was a while back, but I don't recall any other changes in hardware at the time.  Seems unlikely since if I'm going to make the jump from 5.x to 6.x, I would have kept everything else as stable as possible.

The hard part of this problem is that the majority of users (myself included) do not have any issues with the SAS2LP at all (either with recurring errors on parity checks or with VT-D enabled and utilizing passthrough to VMs).  Why I tend to blame the issue for those that do have it on the motherboard itself.  Either way, its very hard to diagnose something that doesn't affect all combinations of hardware, unless you have access to the identical hardware...

 

And just because the BIOS on the motherboard worked under a 32Bit OS does not mean that extra features that a 64bit OS utilizes may use features on the board that are buggy.

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Do you have an adblocker installed? If so, whitelist your server.

 

You might also try a different browser. There have been some reports of the browser not saving your settings.

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

I had this problem a long time ago. I don't know if it can still happen but I believe it had something to do with too many slots assigned to drives and none left for cache. I just reduced the slots for drives and add one for cache.

Share this post


Link to post
Share on other sites

There might be something marginal about your cages: defective connector, cold solder joint, etc.  Maybe something marginal with the controller where the signals passing through another connector cause just enough attenuation on some data line.  Maybe your PSU is right on the edge.  Alternately there might have been a kernel/driver change that accounts for this.  But if you change 2 things (h/w and s/w) how can you deduce the culprit?  You have to restore both to a known working state, verify it still works, then change just one thing at a time.

 

Agree with changing just one thing, but these errors seem to be more and more frequent and affecting more users with the latest kernels, both on the SASLP and SAS2LP, since both use the same driver my money is on that.

 

I had two SAS2LP running fine in 5.0.6 for many years, then when I moved to 6.x, the problem appeared.  I wrestled with it for a bit (updated BIOS, etc.) and ultimately swapped the cards out for Dell HV52W PERC H310 controller cards and have had 0 issues since.

 

It was a while back, but I don't recall any other changes in hardware at the time.  Seems unlikely since if I'm going to make the jump from 5.x to 6.x, I would have kept everything else as stable as possible.

The hard part of this problem is that the majority of users (myself included) do not have any issues with the SAS2LP at all (either with recurring errors on parity checks or with VT-D enabled and utilizing passthrough to VMs).  Why I tend to blame the issue for those that do have it on the motherboard itself.  Either way, its very hard to diagnose something that doesn't affect all combinations of hardware, unless you have access to the identical hardware...

 

And just because the BIOS on the motherboard worked under a 32Bit OS does not mean that extra features that a 64bit OS utilizes may use features on the board that are buggy.

 

Good point, my motherboard is the ASUS M3A78-T, an older AM2+ motherboard with an AM3 compatible CPU (Phenom II X6 1100T).  Everything is on the latest BIOS, but the motherboard was originally purchased back in 2008.  I guess I hadn't suspected that.  I do have a newer motherboard/cpu combo that I could run tests on, but that probably won't be available for several weeks.  I'll report back once I have some results.

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Do you have an adblocker installed? If so, whitelist your server.

 

You might also try a different browser. There have been some reports of the browser not saving your settings.

 

No adblocker installed, I try other browser IE also same. I also monitoring disk.cfg. The setting have update, but after boot the cache device will missing or not mount.

During troubleshoot, I try many thing, i.e. assign both drive be cache pool, change the FS from btrfs to xfs, disconnect one of drive, etc ..... boot many mnay times .....

Update to 6.3 RC, still same.

 

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="6bd95f23-1087-42c0-9026-09c0d52fd360"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

 

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Do you have an adblocker installed? If so, whitelist your server.

 

You might also try a different browser. There have been some reports of the browser not saving your settings.

 

No adblocker installed, I try other browser IE also same. I also monitoring disk.cfg. The setting have update, but after boot the cache device will missing or not mount.

During troubleshoot, I try many thing, i.e. assign both drive be cache pool, change the FS from btrfs to xfs, disconnect one of drive, etc ..... boot many mnay times .....

Update to 6.3 RC, still same.

 

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="6bd95f23-1087-42c0-9026-09c0d52fd360"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

Did you see my post above? What licence do you have? Say you have a Plus licence, I don't know if it's still possible with the array stopped, to set 12 drive slots and a cache slot as well. I had the same problem with the cache not being assigned on reboot. Reducing the number of drive slots fixed it.

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Do you have an adblocker installed? If so, whitelist your server.

 

You might also try a different browser. There have been some reports of the browser not saving your settings.

 

No adblocker installed, I try other browser IE also same. I also monitoring disk.cfg. The setting have update, but after boot the cache device will missing or not mount.

During troubleshoot, I try many thing, i.e. assign both drive be cache pool, change the FS from btrfs to xfs, disconnect one of drive, etc ..... boot many mnay times .....

Update to 6.3 RC, still same.

 

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="6bd95f23-1087-42c0-9026-09c0d52fd360"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

Did you see my post above? What licence do you have? Say you have a Plus licence, I don't know if it's still possible with the array stopped, to set 12 drive slots and a cache slot as well. I had the same problem with the cache not being assigned on reboot. Reducing the number of drive slots fixed it.

 

 

Also try, PLUS key user, currently only with 6 data disk + 2 parity.

In general say, it seems a bug and no solution found. Thanks

Share this post


Link to post
Share on other sites

I have 1 SSD (sdc) and 1 HDD (sdb) in unRAID for spare / cache purpose, if stop-assign-start unRAID, cache device would be fine as expect.

But once reboot, the cache device will be lost and no cache device show.

 

I try several operation and setting include "new config", still can't fix.  :(

Do you have an adblocker installed? If so, whitelist your server.

 

You might also try a different browser. There have been some reports of the browser not saving your settings.

 

No adblocker installed, I try other browser IE also same. I also monitoring disk.cfg. The setting have update, but after boot the cache device will missing or not mount.

During troubleshoot, I try many thing, i.e. assign both drive be cache pool, change the FS from btrfs to xfs, disconnect one of drive, etc ..... boot many mnay times .....

Update to 6.3 RC, still same.

 

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="6bd95f23-1087-42c0-9026-09c0d52fd360"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

root@G3250:/boot/config# cat disk.cfg | grep UUID

cacheUUID="b73bfcc7-6ab7-4ade-b62b-facf7421aef4"

Did you see my post above? What licence do you have? Say you have a Plus licence, I don't know if it's still possible with the array stopped, to set 12 drive slots and a cache slot as well. I had the same problem with the cache not being assigned on reboot. Reducing the number of drive slots fixed it.

 

 

Also try, PLUS key user, currently only with 6 data disk + 2 parity.

In general say, it seems a bug and no solution found. Thanks

 

This happened to me many times before with chrome, but more recently with firefox and chrome worked, in any case it's usually fixed by using a different browser, but you need to a the whole procedure with it, assign cache, start array, stop array, reboot.

 

Share this post


Link to post
Share on other sites

Thinks your advice, you give me a important direction. I will focus on browser first.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.