unRAID Server Release 5.0-rc12 Available


Recommended Posts

Have you thought about using a newer version of netatalk?

2.2.3 is available in slackware 14.

PACKAGE NAME:  netatalk-2.2.3-i486-4.txz

PACKAGE LOCATION:  ./slackware/n

 

Very easy to install the txz.

And 3.0.3 looks like it has some fixes for EA that might help.

 

Looking into extended attributes a bit deeper. Searching the forums I found some having this problem at least as of 5.0Beta14, with each post displaying errors when  mover was run against "user.org.netatalk.supports-eas.%", research came up with "Default Extended Attributes backend".

 

Which now looks like to me that AFP is setting these EA's up as default. But why on some (AFP) shares and not others, I still cant tell. And no real standard.

What I mean by this is as followed. I have 2 mac clients, and both connect to unRAID AFP shares. Some share don't have these default EA's created on them and the ones that do have varies amounts. One share will have 3 default EA's, another only 2, another 5. So its not say based on setting a default EA per each AFP client connection.

 

You would also note that each value of the default EA's is the same across ALL EA's in any of the share's. Mine being "0seWVzAA" before I deleted them and after they were created once more after a new setup of AFP. So that would mean I could have repaired the 4 corrupted EA's possible by attempting to set their value, as we clearly see the value is the same for each of the default EA's that are generated.

 

So these EA's do not look like they stem from files we place on the array (user.org.netatalk.supports-eas.XXXXXX)

 

ex.

user.org.netatalk.supports-eas.1GU9Yz=0seWVzAA==

user.org.netatalk.supports-eas.9cfJ87=0seWVzAA==

user.org.netatalk.supports-eas.M9UYFC=0seWVzAA==

user.org.netatalk.supports-eas.QZBXPh=0seWVzAA==

user.org.netatalk.supports-eas.pyx2TW=0seWVzAA==

 

Reading the netatalk notes:

# ea                  -> none|auto|sys|ad

#                        Specify how Extended Attributes are stores. default

#                        is auto.

#                        auto: try "sys" (by setting an EA on the shared

#                              directory itself), fallback to "ad".  Requires

#                              writable volume for performing the test.

#                              Note: options:ro overwrites "auto" with "none."

#                        sys:  Use filesystem EAs

#                        ad:  Use files in AppleDouble directories

#                        none: No EA support

 

One could believe setting AFP shares in unRAID to readonly could possibly impact being able to set an EA on a share. But all my shares are public for quite sometime now (a loooong time again I may have change it to secure, in the 5.0 betas to test).

 

So now I am thinking maybe it does not have anything to do with us copying/moving our files around the array...

 

RC12

- shfs: return correct extended attribute value length

 

Beta11

- reiserfs: add patch that fixes a crash in reiserfs_delete_xattr during umount (http://www.spinics.net/lists/reiserfs-devel/msg02827.html)

Could this have caused our corruptions to our default EA's way back here?

 

Beta10

- afp: always mount array/cache disks with extended attributes enabled

- shfs: implement persistent inode numbers (AFP fix)

 

- Also somewhere in these Beta/RC's Tom added the additional 'X' to the mover script for rsync (in order to support moving files and their extended attributes).

 

 

So the corrupted/damaged EA's may have occurred with the various changes (and/or crash) of unRAID (no blame) to correct and get extended attributes and AFP setup properly. So time will tell and I will be closely monitoring my unRAID server EA's as time goes by. I have started a spreadsheet to do this.

Link to comment
  • Replies 480
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I believe if we look at the noted changes on the release notes, as of RC1 to where we stand now, it clearly shows the amount of new versions of varies components that where introduced. Some more than one revision up. Kernel alone was changed 7 times.

 

So either these are still betas under a label of RC or...  new versions maybe still required; to resolve issues like NFS, AFP, EA support. As has been done throughout the RC's.

Its not like all components were locked in as of RC1 and only unraid driver changes, script, or component parameter change/tweaks were only made, for that to hold true.

 

Link to comment

I think it is fair to say we are in an unusual position and have long since stopped following the traditional models of beta/RC.

 

Changes should still be kept to a minimum this close to release but it doesn't harm to ask as long as everyone resists the temptation to jump on the aksers :)

Link to comment

Download | Release Notes

 

This is hopefully the last -rc release.  Everyone is encouraged to upgrade to this release since it incorporates better file system flush support.

 

Edit: link changed to download 5.0-rc12a

 

 

OOOooooOOOooo a release on my Birthday.  Thanks for the Present Tom!

 

How pathetic is this person?????

 

 

About as pathetic as you for feeling the need to make fun of someone.

Link to comment

upgraded to rc12.. seems like i cant access my unraid server by its name anymore only by ip address. array is not started..  i would assume that once its started it will work fine. but i could have sworn that on rc11 i could access the unraid server by its name or ip address when the array wasnt started. figured i'd mention this since i know one of the changes in rc12 was the modification of the network driver to support some features. anyone else running into this or am i just crazy?

 

Mar 28 17:34:23 husky kernel: r8168 Gigabit Ethernet driver 8.035.00-NAPI loaded
Mar 28 17:34:23 husky kernel: r8168 0000:04:00.0: irq 44 for MSI/MSI-X
Mar 28 17:34:23 husky kernel: eth%%d: RTL8168E-VL/8111E-VL at 0xf8572000, d4:3d:7e:4d:e4:89, IRQ 44
Mar 28 17:34:23 husky kernel: ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
Mar 28 17:34:23 husky kernel: ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst 
Mar 28 17:34:23 husky kernel: ahci 0000:00:1f.2: setting latency timer to 64
Mar 28 17:34:23 husky kernel: r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
Mar 28 17:34:23 husky kernel: eth0: Identified chip type is 'RTL8168E-VL/8111E-VL'.
Mar 28 17:34:23 husky kernel: r8168  Copyright (C) 2012  Realtek NIC software team <[email protected]> 

 

also see this now that i dont recall seeing before:

Mar 28 17:34:23 husky kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
Mar 28 17:34:23 husky kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT1._GTF] (Node f504e858), AE_NOT_FOUND (20120320/psparse-536)

 

full syslog attached

syslog-2013-03-28.txt

Link to comment

upgraded to rc12.. seems like i cant access my unraid server by its name anymore only by ip address.

 

So, this is, clearly, a name resolution issue.  What environment are you trying to access your server from?  Who (or what) do you expect to be providing the name resolution service (ie translation of the alphabetic name into a numeric IP address)?

 

Going back to basics, the surest way to fix this is to add your unRAID server name/ip into the 'hosts' file on your client(s).

 

 

-- just checked and looks like there was a new bios for my mobo about a month ago.. going to try that out tomorrow and see if that helps out on anything.

 

I would be extremely surprised if this issue has anything to do with the BIOS!

Link to comment

upgraded to rc12.. seems like i cant access my unraid server by its name anymore only by ip address. array is not started..  i would assume that once its started it will work fine. but i could have sworn that on rc11 i could access the unraid server by its name or ip address when the array wasnt started. figured i'd mention this since i know one of the changes in rc12 was the modification of the network driver to support some features. anyone else running into this or am i just crazy?

Well Not crazy.  The change that was made to the network driver would not affect Name (DNS) resolution for your unraid server.

 

Go to the unraid menu then click on Settings -> Network settings to make sure you have configured your unraid system to point to your DNS server.  Generally this is the same address as your gateway or firewall appliance.

 

-- just checked and looks like there was a new bios for my mobo about a month ago.. going to try that out tomorrow and see if that helps out on anything

 

And updating the BIOS is suppose to help with what?  With Name Resolution?  Not likely.  or how your NIC operates ... possibly but also not likely.  BEFORE, you update your BIOS, check the settings above.  Also check your PC make sure its configured correctly.  Use NSLOOKUP from the windows PC command line type in the name of your system like as below:

 

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

c:\User\PlaceNameHere\nslookup
Default Server: bluemaumau  <- thats the name of my DNS server
Address:  10.1.1.1   <- Thats the address of my DNS server

>davyjones
Server:  bluemaumau    
Address:  10.1.1.1

Name:  davyjones.shipwrekcove.net
Address:  10.1.1.10

>exit

C:\Users\PlaceNameHere>_

 

If you see:

DNS request timed out.
        time out was 2 seconds.
DNS request timed out.
        time out was 2 seconds.
*** Request to [PlaceServerNameHere] timed-out

 

Then something is definitely wrong with your DNS server and it needs to be looked at.  If you are not using DNS, then maybe your hosts file has become corrupted or is missing this entry.  Either way, updating BIOS will not solve this issue.

 

If your DNS server is the same server as your ISP, you have mis-configured your DNS settings.  You should have your own DNS server (usually provided by your firewall appliance) with all requests that are not cached on your local DNS server forwarded to your ISP DNS for resolution.  This makes your name lookup response faster and allows you to add host names to your network without having to modify your hosts file on every PC in your network. 

 

Sincerely,

 

Sideband Samurai

Link to comment

I am currently running RC12a with no plugins or issues at this time.

 

Parity check Non-Correcting speeds started at around 120MB/s and at the 25% mark have dropped to 108 MB/s

By the end of the check speeds had dropped to about 80mb/s

 

This is a small 3 disk system all with 2TB Green drives installed.

 

-- Sideband Samurai

Link to comment

Download | Release Notes

 

This is hopefully the last -rc release.  Everyone is encouraged to upgrade to this release since it incorporates better file system flush support.

 

Edit: link changed to download 5.0-rc12a

 

 

OOOooooOOOooo a release on my Birthday.  Thanks for the Present Tom!

 

How pathetic is this person?????

 

 

About as pathetic as you for feeling the need to make fun of someone.

+1
Link to comment

 - Update onboard Realtek LAN UEFI PXE driver.

which i figured may help with the recent network driver changes made in rc12.

 

PXE is the "Preboot eXecution Environment".  It has to do with booting from a remote network server.

 

yes, but seeing anything for the integrated network card in a bios update raises eyebrows that i probably should upgrade just so i dont hear 'well you arent using the latest bios'. I'm well aware that fundamentally this shouldnt make any difference. I'll post back once I get home from work and can startup the server to check the information that people had asked for.

Link to comment

As requested:

Go to the unraid menu then click on Settings -> Network settings to make sure you have configured your unraid system to point to your DNS server.  Generally this is the same address as your gateway or firewall appliance.

 

gateway and dns are both set to my router ip in the unraid network settings, 192.168.0.1.

 

/boot/config# more network.cfg 
# Generated settings:
USE_DHCP="no"
IPADDR="192.168.0.11"
NETMASK="255.255.255.0"
GATEWAY="192.168.0.1"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="192.168.0.1"
DNS_SERVER2=""
DNS_SERVER3=""

 

ifconfig info from unmenu:

NIC driver info (from ethtool -i)
driver: r8168
version: 8.035.00-NAPI
firmware-version: 
bus-info: 0000:04:00.0

Ethernet config info (from ifconfig)
eth0      Link encap:Ethernet  HWaddr d4:3d:7e:4d:e4:89  
          inet addr:192.168.0.11  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6463 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2912934 (2.7 MiB)  TX bytes:9241639 (8.8 MiB)
          Interrupt:43 Base address:0xe000 

 

from a machine within the network,

C:\>nslookup husky
1.0.168.192.in-addr.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
Server:  UnKnown
Address:  192.168.0.1

*** UnKnown can't find husky: Non-existent domain

 

started up unraid server.. still cant reach the webui using the host name :(

ip address still works fine. i can access the shares just fine. only has to do with hostname.

this is all in the latest version of chrome (26.0.1410.43 beta-m).

tried firefox 19.0.2 for kicks.. and the hostname works fine. So seems to be a problem just in chrome.. joy. now to figure out what they broke/what setting needs to be changed to make it work as it did previously.

Link to comment

upgraded to rc12.. seems like i cant access my unraid server by its name anymore only by ip address.

 

So, this is, clearly, a name resolution issue.  What environment are you trying to access your server from?  Who (or what) do you expect to be providing the name resolution service (ie translation of the alphabetic name into a numeric IP address)?

 

Going back to basics, the surest way to fix this is to add your unRAID server name/ip into the 'hosts' file on your client(s).

 

 

-- just checked and looks like there was a new bios for my mobo about a month ago.. going to try that out tomorrow and see if that helps out on anything.

 

I would be extremely surprised if this issue has anything to do with the BIOS!

 

About updating the BIOS - the 2nd code block referenced stuff when searched on the forums that a BIOS may help. Also in my BIOS update I see

 - Update onboard Realtek LAN UEFI PXE driver.

which i figured may help with the recent network driver changes made in rc12.

 

About the network settings, I'll have to check for rc12 to see if something changed on the server (currently offline).

Here is what network.cfg had when I made a copy of RC11 just before the upgrade:

# Generated settings:
USE_DHCP="no"
IPADDR="192.168.0.11"
NETMASK="255.255.255.0"
GATEWAY="192.168.0.1"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="192.168.0.1"
DNS_SERVER2=""
DNS_SERVER3=""

 

You are not using the DHCP services on your router.  My router does log the 'name' of any device that it does not provide DHCP services for.  (I have even added the IP address to its reserve list.) 

 

If your router behaves the same way, you will have to add the name to your hosts file on your computer or continue to use the IP address.  I have chosen to use the IP address method as I use a short cut to the server and once setup I never even think about that option. 

Link to comment

Hi

I can only confirm on rc12/a stale NFS issue still exist :( im few time get this error on 2 days :(

this should be finly fixed, this is main function. With error like that this shuould be Alpha or Beta version not RC !

(for me array work and files handle over network should be on 1rst plain, if this work OK yes could be named RC version

but now even with AFP make some errors :/ sorry, i know Tom have a lot stuff on head but maybe this all issue are in some

related with quite new kernel and like for me old filesystem from slackare 13.1 from 2010 :/ maybe time to move on )

Link to comment
I can only confirm on rc12/a stale NFS issue still exist :( im few time get this error on 2 days :(

 

Do you find, like I do, that the stale file handle problem was almost completely fixed in rc4, and was like this all the way through to rc10, but then became much worse again in rc11?

 

Have you seen this thread?

Link to comment

@zoggy

C:\>nslookup husky
1.0.168.192.in-addr.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
Server:  UnKnown
Address:  192.168.0.1

*** UnKnown can't find husky: Non-existent domain

 

Zoggy, this is not a normal output of windows nslookup.  I don't know where you got this from but it should look like my previous post.  From the looks of this it appears that you have picked up the reverse look configuration file from a linux named setup.  Possibly left over in your clipboard from another copy/paste process you did earlier.  I can tell this because of all the options included in the record.  This is a reverse lookup because of the 1.0.168.192.in-addr.arpa phrase at the top (you will notice the ip of that is reversed).

 

No ... updating the BIOS will not resolve your name resolution issues.  The update may improve network performance but that is not what we are troubleshooting right now.

 

If I execute 'nslookup davyjones' this is the result I get:

 

server:  bluemaumau
address:  10.1.1.1

name:  davyjones
address:  10.1.1.10

 

and nothing else.

 

You can also try this:

ping husky

 

if you get

Ping request could not find host husky, please check the name and try again.

 

then this is a name resolution issue not a network connectivity issue.  Things a BIOS update might fix are slow transfer speeds, connection/disconnection from the network, getting the wrong linkspeed stuff like that.  Not what you are having now.  As you can contact the server via IP but not by name.

 

What are you using for a firewall/gateway?

 

The "unknown or non-existant domain" error is also a clue your DNS server is not working correctly.

 

-- Sideband Samurai

Link to comment

 

So, this is, clearly, a name resolution issue.  What environment are you trying to access your server from?  Who (or what) do you expect to be providing the name resolution service (ie translation of the alphabetic name into a numeric IP address)?

 

Going back to basics, the surest way to fix this is to add your unRAID server name/ip into the 'hosts' file on your client(s).

 

 

Well Yes and no.  Yes it will fix it for that ONE PC, but not fix it for the entire network.  Clearly his DNS server is not working properly and the PROPER way to fix it is to troubleshoot why its not working.  Its why I asked him what he is using for a firewall.  Clearly this issue is not for this thread.  It should be in its own thread so we can help him better there.

 

@frank1940

What environment are you trying to access your server from?

Who (or what) do you expect to be providing the name resolution service (ie translation of the alphabetic name into a numeric IP address)?

What kind of questions are these.  obviously he is using the windows environment (based on his command prompt of c:\nslookup husky).  And that second question, is, a bit confusing also.  It does not matter who or what he is supplies the name look up service for.  To answer that question for zoggy, he is providing name look up service for his local network. His name service is just not working.  period.  In my network, I have a statically assigned pool of addresses.  The static area is from .1 to .30 with the DHCP pool starting at .31.  I update my DNS server with the host name and ip address assigned the new host and it starts working for the entire network.  I don't have to update a local host file, and I don't have to statically assign a DHCP address to the new host.  Simple as that.

 

@zoggy, if you want to start a new thread in the "General Support" section we will help you there. OK?

 

--Sideband Samurai

Link to comment
Guest
This topic is now closed to further replies.