unRAID Server Release 6.0-beta6-x86_64 Available

[JustinChase]

I'm not really familiar with the mac changing problem you mention, so that probably means it's no longer an issue.  I've not seen any mention of it since I installed beta5, so I'd suggest you update to the latest beta and see if it still exists.  if it does, please provide details on the bug, and I'm sure it will get resolved.

[Schar]

I am on 6.0-beta6 (x64)

 

The MAC address is reported in settings correctly, but what the DHCP server is seeing and issuing against is a 36 byte string, which changes each boot. I have tried a reservation against the base address but that doesn't work, it only works when I create the reservation against the instance in my above post (which is only good for one boot cycle!).

 

My network settings:

Bonding: no

Bridge: no

Auto IP: yes

Auto DNS: yes

 

From my log file:

Jul 15 15:19:48 TOWER dhcpcd[1342]: eth0: using ClientID ff:65:74:68:30:00:01:00:01:1b:57:5a:54:10:c2:7b:1c:ac:ab

Jul 15 15:19:48 TOWER dhcpcd[1342]: eth0: soliciting a DHCP lease

Jul 15 15:19:48 TOWER dhcpcd[1342]: eth0: sending DISCOVER (xid 0x8df6567), next in 4.07 seconds

Jul 15 15:19:48 TOWER dhcpcd[1342]: eth0: offered 192.168.1.211 from 192.168.1.2

 

Which matches the reservation, and changes each boot.

 

[itimpi]

I wonder if it is something to do with the way your particular router works?  It might be worth mentioning what you are using?  I have no trouble issuing an IP against the base MAC address of my unRAID system, and have no need to look up that 36 byte ID you mention (I am not even sure if it is MEANT to be constant).

[jbartlett]

Have you tried configuring UNRAID with a static IP outside of the range that the Router maintains?

[Schar]

Not yet. I could do that but everything else in the house other than my DSL router and domain controllers are managed by DHCP reservation, which is my preferred approach.

 

It is the DHCP server (2K8R2) that is receiving it, but per the logs above you can see that is also what the UNRAID6 server is sending when it requests the lease.

 

Today I'll check UNRAID5 on the same hardware to validate that it is a 6.0 thing.

[mikeybunting]

I have been having numerous errors when writing data to any of my disks/shares...had no problems with beta5.

 

Is it possible to go back to beta 5 from the latest beta 6?

[RobJ]

I have been having numerous errors when writing data to any of my disks/shares...had no problems with beta5.

 

Is it possible to go back to beta 5 from the latest beta 6?

Certainly, just copy bzimage and bzroot from your copy of the beta 5 distro to your UnRAID flash drive and reboot.

 

However, unless you have Marvell controllers, there is little chance that this will help you.  Exactly what errors are you seeing?

[Schar]

Just a quick note - after battling with AD integration on v4 and v5 for years, I got it working very simply with v6. Not sure if I was just doing the wrong thing with v4/5 but it all fell into place nicely this time. Kudos and thanks - it adds a much wanted layer to what I do with UNRAID at home.

 

(now just to play with the more complex ACLs).

[SSD]

This thread from General Support may indicate an issue with 6.0b6.

 

SEE HERE

[SmallwoodDR82]

nice work guys!

 

I'm seeing a small bug but it doesn't seem to effect the operation of unRAID.

 

My syslog shows a boat load of these...

 

Jul 21 06:28:03 SMC-unRAID kernel: e1000 0000:02:01.0 eth0: Detected Tx Unit Hang
Jul 21 06:28:03 SMC-unRAID kernel:   Tx Queue             <0>
Jul 21 06:28:03 SMC-unRAID kernel:   TDH                  <15>
Jul 21 06:28:03 SMC-unRAID kernel:   TDT                  <31>
Jul 21 06:28:03 SMC-unRAID kernel:   next_to_use          <31>
Jul 21 06:28:03 SMC-unRAID kernel:   next_to_clean        <14>
Jul 21 06:28:03 SMC-unRAID kernel: buffer_info[next_to_clean]
Jul 21 06:28:03 SMC-unRAID kernel:   time_stamp           <100496529>
Jul 21 06:28:03 SMC-unRAID kernel:   next_to_watch        <17>
Jul 21 06:28:03 SMC-unRAID kernel:   jiffies              <100496593>
Jul 21 06:28:03 SMC-unRAID kernel:   next_to_watch.status <0>

 

google/searching unRAID forum showed this was a bug way back in the day....but everyone was reporting the operation was not effected and that still seems to be the case. 

 

I'm running ESXi 5.1 with plop for unRAID.  When on 5.0.4 these messages were not there.

 

My thought is unRAID 6.0 e1000 NIC driver is out dated?

 

Any ideas?

 

Thanks!!!!

syslog.txt

[gtroyp]

Before I start mucking about in configuration files, are there any unRAID specific changes to to the ssh server related to users being able to access?

 

And, on a similar note, is there a way to grant a user access to the console? I want to limit root access as much as possible.

[limetech]

Before I start mucking about in configuration files, are there any unRAID specific changes to to the ssh server related to users being able to access?

 

And, on a similar note, is there a way to grant a user access to the console? I want to limit root access as much as possible.

 

A concept that we have not done a good job of pointing out is this: there really are no "users" in unRAID OS.  That is, no users in the traditional sense of separate logins, home directories, etc.  The only reason there is a "Users" list is to implement network-based security.

 

In a windows workgroup network, these "users" should match your windows login names, or be similar.  They are used when you try to access a non-public share.  If your windows logon name does not match any name in the unRaid Users list, windows opens a dialog box asking you to enter credentials.  Same thing for AFP access via OSX.

 

In a windows active directory network, you don't need to define any users at all - it is all handled by active directory.

 

For webGui access, the reason 'root' user was chosen was because that's also the user that has console access.  The webGui runs as 'root' anyway, so even if we implemented access via different username, there would be no change in webGui functionality (e.g., that user could still break the array if they wanted to).

 

unRaid is not a "general purpose" linux platform - it's specialized NAS appliance platform that happens to run linux.

[lockholster]

Hi Guys,

 

First time on the forums here, sorry if this is the wrong place to post, but I've either F'd up or come across a bug. 

 

Just tried upgrading from a 5 server to 6beta6 and it looks like my Plus key is registering as though it's Basic (free edition).

 

Copied my config to the flash, only one .key file in the directory, syslog appears to have the correct GUID on my key, but just registers it as Basic instead of Plus!?

 

syslog attached.

syslog.txt

[NAS]

lockholster drop Limetech an email that stuff gets done direct It might be as simple as placing it in the wrong place but better to deal direct with licensing

[lockholster]

Thanks NAS, will do.

[itimpi]

Hi Guys,

 

First time on the forums here, sorry if this is the wrong place to post, but I've either F'd up or come across a bug. 

 

Just tried upgrading from a 5 server to 6beta6 and it looks like my Plus key is registering as though it's Basic (free edition).

 

Copied my config to the flash, only one .key file in the directory, syslog appears to have the correct GUID on my key, but just registers it as Basic instead of Plus!?

 

syslog attached.

Nobody else has reported such a problem, so I suspect the problem has to be something else?  I assume that the .key file you copies was the one that was already on the USB drive when it was working for v5?

 

One thing I noticed is that a few plugins are being loaded.    Have you ensured that these are all 64-bit compatible - if not they may be upsetting something.    You could try booting in Safe Mode to load without plugins to see if that helps.

[sacretagent]

from the main website

 

To install the Registration Key, simply copy the key data file to the config directory of your Flash and reboot your server.

 

i recently changed usb drive and had the same issue by putting the key in the main /flash dir

it has to be in /flash/config (if you look at it from a network machine

or /boot/config if you look at it from unraid (winscp or something like that)

[garycase]

As noted above, I suspect you have simply placed the key file in the wrong place.    Be sure it's in the CONFIG folder on the flash drive.

 

[Kryspy]

I always just dropped mine in the root of the usb key. Never had a problem.

 

Kryspy

[trurl]

Hi Guys,

 

First time on the forums here, sorry if this is the wrong place to post, but I've either F'd up or come across a bug. 

 

Just tried upgrading from a 5 server to 6beta6 and it looks like my Plus key is registering as though it's Basic (free edition).

 

Copied my config to the flash, only one .key file in the directory, syslog appears to have the correct GUID on my key, but just registers it as Basic instead of Plus!?

 

syslog attached.

Nobody else has reported such a problem, so I suspect the problem has to be something else?  I assume that the .key file you copies was the one that was already on the USB drive when it was working for v5?

 

One thing I noticed is that a few plugins are being loaded.    Have you ensured that these are all 64-bit compatible - if not they may be upsetting something.    You could try booting in Safe Mode to load without plugins to see if that helps.

Yea, those unplugged plugins are not going to work for you and they are unsupported besides. Look for the replacements by PhAzE, they are available for 64bit. In fact, if you have any plugins from before you need to remove them. Maybe not causing this particular problem, but they won't work.

 

As far as I remember, my .key file has always been in /boot/config, even when I was on 4.7

[NAS]

time to fork this thread please this is announcements

[Helmonder]

I just moved my unraid server back to bare metal... out of esxi.. I build a new esxi server next to it (just for the heck of it). Just wanted to let know that I have experienced an enormous speed increase in this setup using the V6 version...

 

Even without cachedrive I get transferrates of above 70 on average and peaking to above 100. Writes to cachedrive shares are sustained at 100mb..

 

Really happy with this..

 

Am running a Xenon E3 1230 so I can expect some speed... But with the 32bit I never used to get this performance on bare metal..

[METDeath]

Using this release I sometimes have my shares go away, I also have /mnt/user and /mnt/user0

When they vanish /mnt/user is empty, but /mnt/user0 has my shares listed in it.

 

Rebooting brings them back... which is frustrating while I'm still populating it...

[JonathanM]

Using this release I sometimes have my shares go away, I also have /mnt/user and /mnt/user0

When they vanish /mnt/user is empty, but /mnt/user0 has my shares listed in it.

 

Rebooting brings them back... which is frustrating while I'm still populating it...

Possibly a cache drive issue? Try running without a cache drive for a test run and see if the symptoms change.

[METDeath]

Using this release I sometimes have my shares go away, I also have /mnt/user and /mnt/user0

When they vanish /mnt/user is empty, but /mnt/user0 has my shares listed in it.

 

Rebooting brings them back... which is frustrating while I'm still populating it...

Possibly a cache drive issue? Try running without a cache drive for a test run and see if the symptoms change.

 

The biggest problem is that the issue is mostly random. I did experience it while not running a cache drive though. However, at the time I was experimenting with enable/disable NFS which made them vanish/return.