unRAID Server Release 5.0-beta10 Available


Recommended Posts

Hey Tom - quick question... Is it possible to say if you've changed anything in the webGui php files (in the release notes) whenever you release an update? At the moment I have to compare code for each of the files, takes a while to do.

 

Learn to use the diff command. It's willing to be your friend. This is from my unraid dev box:

 

mkdir unraid-50b9 unraid-50b10
cd unraid-50b9 && 7z x ../unRAID\ Server\ 5.0-beta9\ AiO.zip bzroot bzimage
zcat bzroot | cpio -m -i -d -H newc --no-absolute-filenames
cd ..
cd unraid-50b10 && 7z x ../unRAID\ Server\ 5.0-beta10\ AiO.zip bzroot bzimage
zcat bzroot | cpio -m -i -d -H newc --no-absolute-filenames
cd ..
diff -uwbr unraid-50b9 unraid-50b10 | egrep -vi special\|fifo > diffs_b9_b10.brief
diff -uwr unraid-50b9 unraid-50b10 | egrep -vi special\|fifo > diffs_b9_b10.full

 

Nice. I've been using a gui solution, but this looks far cooler :)

Link to comment
  • Replies 292
  • Created
  • Last Reply

Top Posters In This Topic

Does this fix the AFP with SMB issue on Lion ("-SMB" prefix seems to break the server browsing)?

 

I don't have Lion just yet, but if you google "Lion SMB" and you'll see there are all kinds of issues with Lion accessing Windows shares and Samba shares.  Supposedly Apple has developed their own replacement for Samba called "smbx":

http://www.itproportal.com/2011/03/28/apple-replaces-samba-mac-osx-10-7-lion/

 

The "-SMB" suffix is just the smb service being advertised by AVAHI.  Please try Finder's "Connect to Server" dialog and use "cifs" or "smb" as the protocol, e.g.:

 

cifs://tower

 

and report back the results of this.

 

 

If you remove the -SMB prefix from the service file, smb works from the finder sidebar. Unfortunately AFP is then no longer available in the sidebar. Connect to server works as it did before and even works with the -SMB prefix. This is using 5.09.

 

That's why there's a "-SMB" suffix added in the service name (so that it's differentiated in Finder).  I guess I don't understand if you are reporting a bug or not  ???

Link to comment

Big problem with beta10 for me. It doesn't appear to see my eth0. Quite a novice with Linux-type things but have used unRaid for several months now and have performed several updates and rebuilds etc. Beta10 screws up my network and eth0 does not show up when using ifconfig.

Log file attached -  in case it is of any use/interest . Have gone back to beta9 and all OK again (although 1 parity check error found .. but this could just be a coincidence I guess). Interested in any feedback/advice - hope this doesn't mean that I now have to stick at beta9?

 

OOPS -forgot to mention - Network card is Dlink DGE-528T

syslog-20110723-171617.txt.zip

Link to comment

That's why there's a "-SMB" suffix added in the service name (so that it's differentiated in Finder).  I guess I don't understand if you are reporting a bug or not  ???

 

It seems that Lion is unable to connect to the service when "-SMB" is added to the service name. I'm not sure why. Perhaps Lion is attempting to do a DNS lookup on "tower-SMB" (which fails)?

 

As btlupin says, SMB works if you are not also using AFP at the same time (and thus, "-SMB" is not added to the service name). SMB also works if you connect directly to "smb://tower/" (even when "-SMB" is added to the service name), however if you do connect this way, you will be unable to connect to the AFP share from the "shared" section of the sidebar.

 

I need AFP for Time Machine only, but since I can't access AFP and SMB shares at the same time due to this bug I have disabled AFP (and Time Machine) so I can access my other shares of SMB. I tried to access all my shares over AFP, but it was taking ages for a directory listing to come up when connected to an AFP share.

 

On a related note, Time Machine initially would not work until I deleted the .AppleD* folders from the Time Machine share. Is this because netatalk was upgraded? Is this the required procedure to "upgrade" the cnid db, or is there a better way (dump and restore)?

 

Link to comment

Big problem with beta10 for me. It doesn't appear to see my eth0. Quite a novice with Linux-type things but have used unRaid for several months now and have performed several updates and rebuilds etc. Beta10 screws up my network and eth0 does not show up when using ifconfig.

Log file attached -  in case it is of any use/interest . Have gone back to beta9 and all OK again (although 1 parity check error found .. but this could just be a coincidence I guess). Interested in any feedback/advice - hope this doesn't mean that I now have to stick at beta9?

 

OOPS -forgot to mention - Network card is Dlink DGE-528T

 

That card has a Realtek 8169S chipset, but tends to be masked from being discovered because of Vendor and Device Ids not being typical.

Link to comment

First of all - thank you for releasing an update so soon to resolve the AFP / Time Machine issues with Lion.

 

Similarly to davekeel, I too have a problem with my NIC since upgrading to 5.0-beta10. 

No 'eth0' showing up anymore in ifconfig & hence no network access.

 

My network card is a PCI Tenda Gigabit NIC TEL9901G which utilises a Realtek r8169 chip.

 

I had no problems with previous unRAID releases (5.0-beta9 and 5.0-beta6a) so I assume it's something to do with what is mentioned in the changelog regarding updating the Realtek drivers.

 

I include two syslogs: one for when my NIC was working (5.0-beta9) and one for my 5.0-beta10 system with the failed NIC.

The working system (5.0-beta9) logs the following, whereas when I boot the failed NIC system (5.0-beta10) it excludes these lines:

 

Jul 23 20:31:24 Tower kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: PCI: Disallowing DAC for device
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: (unregistered net_device): no PCI Express capability
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: eth0: RTL8169sb/8110sb at 0xf8426800, c8:3a:35:d8:36:d0, XID 10000000 IRQ 19

 

Please help - was really looking forward to getting Time Machine working with Lion OS-X.

syslog-unRAIDServerRelease5.0-beta10_NoNIC.txt

syslog-unRAIDServerRelease5.0-beta9_WorkingNIC.txt

Link to comment

First of all - thank you for releasing an update so soon to resolve the AFP / Time Machine issues with Lion.

 

Similarly to davekeel, I too have a problem with my NIC since upgrading to 5.0-beta10. 

No 'eth0' showing up anymore in ifconfig & hence no network access.

 

My network card is a PCI Tenda Gigabit NIC TEL9901G which utilises a Realtek r8169 chip.

 

I had no problems with previous unRAID releases (5.0-beta9 and 5.0-beta6a) so I assume it's something to do with what is mentioned in the changelog regarding updating the Realtek drivers.

 

I include two syslogs: one for when my NIC was working (5.0-beta9) and one for my 5.0-beta10 system with the failed NIC.

The working system (5.0-beta9) logs the following, whereas when I boot the failed NIC system (5.0-beta10) it excludes these lines:

 

Jul 23 20:31:24 Tower kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: PCI: Disallowing DAC for device
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: (unregistered net_device): no PCI Express capability
Jul 23 20:31:24 Tower kernel: r8169 0000:00:0b.0: eth0: RTL8169sb/8110sb at 0xf8426800, c8:3a:35:d8:36:d0, XID 10000000 IRQ 19

 

Please help - was really looking forward to getting Time Machine working with Lion OS-X.

 

 

Can you remove the PCI nic card and use the onboard one?

Link to comment

It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB.

 

You can put this line in your 'go' script before invoking 'emhttp':

 

rm /etc/avahi/services/smb.service

 

This just removes the service definition file for smb under avahi.  Now Finder won't see it automatically but it would be interesting to see under Lion if you can connect to AFP via Finder sidebar as usual, and then also connect using "Connect to Server" method to same share using smb.

 

If you look inside that smb.service file you'll see it's pretty simple.  Maybe there's another way to same server show up in Finder sidebar with both protocols enabled.

 

Link to comment

Big problem with beta10 for me. It doesn't appear to see my eth0. Quite a novice with Linux-type things but have used unRaid for several months now and have performed several updates and rebuilds etc. Beta10 screws up my network and eth0 does not show up when using ifconfig.

Log file attached -  in case it is of any use/interest . Have gone back to beta9 and all OK again (although 1 parity check error found .. but this could just be a coincidence I guess). Interested in any feedback/advice - hope this doesn't mean that I now have to stick at beta9?

 

OOPS -forgot to mention - Network card is Dlink DGE-528T

 

From the console or telnet session please type this command:

 

modprobe r8168

 

And then see if that turns on your network interface.  If not, please send another syslog obtained after typing above command.

Link to comment

On a related note, Time Machine initially would not work until I deleted the .AppleD* folders from the Time Machine share. Is this because netatalk was upgraded? Is this the required procedure to "upgrade" the cnid db, or is there a better way (dump and restore)?

You can follow instructions in the netatalk documentation:

http://netatalk.sourceforge.net/2.2/htmldocs/upgrade.html#id4005752

 

At the end of that section there the "brute force" approach, which is delete the .AppleDB directory.  Here is what the netatalk documentation says about that:

If you are absolutely sure what you are doing, you can also just clear out all database files from the .AppleDB directories. They will be recreated, but will not contain the same CNIDs as before!! That might lead to all sorts of problems, like aliases not working any more on clients. As I said, make sure you know the consequences and don't mind them.

 

Actually I think that info is not 100% accurate because it appears the code will try and use CNID info stored in files under .AppleDouble directory.  But I have not completely verified this.

 

So I don't know the implication of this on your server.  I can say that in testing I just delete all the .AppleDB directories  ;D

Link to comment

Big problem with beta10 for me. It doesn't appear to see my eth0. Quite a novice with Linux-type things but have used unRaid for several months now and have performed several updates and rebuilds etc. Beta10 screws up my network and eth0 does not show up when using ifconfig.

Log file attached -  in case it is of any use/interest . Have gone back to beta9 and all OK again (although 1 parity check error found .. but this could just be a coincidence I guess). Interested in any feedback/advice - hope this doesn't mean that I now have to stick at beta9?

 

OOPS -forgot to mention - Network card is Dlink DGE-528T

 

That card has a Realtek 8169S chipset, but tends to be masked from being discovered because of Vendor and Device Ids not being typical.

 

Please also try the "modprobe r8168" command.

Link to comment

It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB.

 

You can put this line in your 'go' script before invoking 'emhttp':

 

rm /etc/avahi/services/smb.service

 

This just removes the service definition file for smb under avahi.  Now Finder won't see it automatically but it would be interesting to see under Lion if you can connect to AFP via Finder sidebar as usual, and then also connect using "Connect to Server" method to same share using smb.

 

If you look inside that smb.service file you'll see it's pretty simple.  Maybe there's another way to same server show up in Finder sidebar with both protocols enabled.

 

 

If I remove the smb.service file I can no longer connect to afp via Finder Sidebar. The entry for afp is there, but the shares are mounted using smb. Connect to server works as expected.

Link to comment

It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB.

 

You can put this line in your 'go' script before invoking 'emhttp':

 

rm /etc/avahi/services/smb.service

 

This just removes the service definition file for smb under avahi.  Now Finder won't see it automatically but it would be interesting to see under Lion if you can connect to AFP via Finder sidebar as usual, and then also connect using "Connect to Server" method to same share using smb.

 

If you look inside that smb.service file you'll see it's pretty simple.  Maybe there's another way to same server show up in Finder sidebar with both protocols enabled.

 

 

If I remove the smb.service file I can no longer connect to afp via Finder Sidebar. The entry for afp is there, but the shares are mounted using smb. Connect to server works as expected.

 

So are you saying this:

1. With smb.service file removed, the server still shows up in sidebar because AFP is enabled.

2. If you click on your server in the sidebar, it works, but then you can't connect via smb.

3. Alternately, if you connect via smb, it now won't work to click on your server in the sidebar.

 

All above correct?

Link to comment

It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB.

 

You can put this line in your 'go' script before invoking 'emhttp':

 

rm /etc/avahi/services/smb.service

 

This just removes the service definition file for smb under avahi.  Now Finder won't see it automatically but it would be interesting to see under Lion if you can connect to AFP via Finder sidebar as usual, and then also connect using "Connect to Server" method to same share using smb.

 

If you look inside that smb.service file you'll see it's pretty simple.  Maybe there's another way to same server show up in Finder sidebar with both protocols enabled.

 

 

If I remove the smb.service file I can no longer connect to afp via Finder Sidebar. The entry for afp is there, but the shares are mounted using smb. Connect to server works as expected.

 

So are you saying this:

1. With smb.service file removed, the server still shows up in sidebar because AFP is enabled.

2. If you click on your server in the sidebar, it works, but then you can't connect via smb.

3. Alternately, if you connect via smb, it now won't work to click on your server in the sidebar.

 

All above correct?

 

1. Correct, the server without the -SMB prefix is still in the sidebar since afp service is enabled.

2. If I click the server in the sidebar, it works but connects using smb and not afp.

3. Not sure if I follow, but both the sidebar and connect to server work, but both use smb.

Link to comment

From the console or telnet session please type this command:

 

modprobe r8168

 

And then see if that turns on your network interface.  If not, please send another syslog obtained after typing above command.

I tried typing the above modprobe command but still no eth0.  Here's my log.  Hope it helps.

 

Do you have two ethernet NIC's?  If so, please disable, or remove all but the one you want active.  If not, please type this command and post it's output:

 

cat /proc/net/dev

Link to comment

It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB.

 

You can put this line in your 'go' script before invoking 'emhttp':

 

rm /etc/avahi/services/smb.service

 

This just removes the service definition file for smb under avahi.  Now Finder won't see it automatically but it would be interesting to see under Lion if you can connect to AFP via Finder sidebar as usual, and then also connect using "Connect to Server" method to same share using smb.

 

If you look inside that smb.service file you'll see it's pretty simple.  Maybe there's another way to same server show up in Finder sidebar with both protocols enabled.

 

 

If I remove the smb.service file I can no longer connect to afp via Finder Sidebar. The entry for afp is there, but the shares are mounted using smb. Connect to server works as expected.

 

So are you saying this:

1. With smb.service file removed, the server still shows up in sidebar because AFP is enabled.

2. If you click on your server in the sidebar, it works, but then you can't connect via smb.

3. Alternately, if you connect via smb, it now won't work to click on your server in the sidebar.

 

All above correct?

 

1. Correct, the server without the -SMB prefix is still in the sidebar since afp service is enabled.

2. If I click the server in the sidebar, it works but connects using smb and not afp.

3. Not sure if I follow, but both the sidebar and connect to server work, but both use smb.

 

How do you know it's connecting via smb?  Maybe this is an "Apple thing" where if once you connect via smb, it will prefer to always connect that way?  Perhaps try a reboot of your Mac to see if it still behaves like that.  I should have a Lion machine to test with later this weekend.

Link to comment

From the console or telnet session please type this command:

modprobe r8168

And then see if that turns on your network interface.  If not, please send another syslog obtained after typing above command.

I tried typing the above modprobe command but still no eth0.  Here's my log.  Hope it helps.

Do you have two ethernet NIC's?  If so, please disable, or remove all but the one you want active.  If not, please type this command and post it's output:

cat /proc/net/dev

 

Yes I have two ethernet NICs but the non-Gigabit integrated one is intentionally disabled in BIOS.  Here's my output after typing cat /proc/net/dev

 

Inter-|   Receive                                                |  Transmit
face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:     660      10    0    0    0     0          0         0      660      10    0    0    0     0       0          0

 

Link to comment

You can follow instructions in the netatalk documentation:

http://netatalk.sourceforge.net/2.2/htmldocs/upgrade.html#id4005752

 

At the end of that section there the "brute force" approach, which is delete the .AppleDB directory.  Here is what the netatalk documentation says about that:

If you are absolutely sure what you are doing, you can also just clear out all database files from the .AppleDB directories. They will be recreated, but will not contain the same CNIDs as before!! That might lead to all sorts of problems, like aliases not working any more on clients. As I said, make sure you know the consequences and don't mind them.

 

Actually I think that info is not 100% accurate because it appears the code will try and use CNID info stored in files under .AppleDouble directory.  But I have not completely verified this.

 

So I don't know the implication of this on your server.  I can say that in testing I just delete all the .AppleDB directories  ;D

 

Thanks. Perhaps this information could be included in the release notes whenever netatalk is updated, or even a little script that people can run while the array is stopped to update their CNID databases properly?

 

Cheers.

 

Link to comment

Big problem with beta10 for me. It doesn't appear to see my eth0. Quite a novice with Linux-type things but have used unRaid for several months now and have performed several updates and rebuilds etc. Beta10 screws up my network and eth0 does not show up when using ifconfig.

Log file attached -  in case it is of any use/interest . Have gone back to beta9 and all OK again (although 1 parity check error found .. but this could just be a coincidence I guess). Interested in any feedback/advice - hope this doesn't mean that I now have to stick at beta9?

 

OOPS -forgot to mention - Network card is Dlink DGE-528T

 

That card has a Realtek 8169S chipset, but tends to be masked from being discovered because of Vendor and Device Ids not being typical.

 

Please also try the "modprobe r8168" command.

 

I have been trying to re-compile my own kernel to add DVB drivers over the last few days. I noticed that when compiling a new kernel from 5.0beta10, that when I rsync'd the new modules into the new bzroot there was one "deleted" line for realtek. I don't remember which realtek, but that seemed odd to me at the time.

 

My understanding is that by using the .config that comes with unRAID and running `make oldconfig`, I should be starting with the same base configuration that unRAID ships with. I did not remove anything drivers, I only added DVB drivers. Perhaps 5.0beta10 ships without this realtek module?

 

Cheers.

 

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.