speeding_ant Posted July 23, 2011 Share Posted July 23, 2011 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 Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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 Quote Link to comment
btlupin Posted July 23, 2011 Share Posted July 23, 2011 It is a bug. Lion Finder will not connect to smb unraid in the sidebar if the service has the prefix -SMB. Quote Link to comment
davekeel Posted July 23, 2011 Share Posted July 23, 2011 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 Quote Link to comment
mrmachine Posted July 23, 2011 Share Posted July 23, 2011 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)? Quote Link to comment
BRiT Posted July 23, 2011 Share Posted July 23, 2011 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. Quote Link to comment
MrLondon Posted July 23, 2011 Share Posted July 23, 2011 I have a problem with nfs and beta 10. I have enabled nfs and selected a share to be exported with nfs however if I look in the exports file it's empty. Any clues and I would need it for VMware datastore. After a power cycle of the unraid server it is now shown in the exports file. syslog-2011-07-231.txt Quote Link to comment
Interstellar Posted July 23, 2011 Share Posted July 23, 2011 Will update my server and report back regarding speed issues tomorrow. Can't test with Lion yet as my MP isn't going to Lion just yet. Quote Link to comment
capler Posted July 23, 2011 Share Posted July 23, 2011 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 Quote Link to comment
prostuff1 Posted July 23, 2011 Share Posted July 23, 2011 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? Quote Link to comment
capler Posted July 23, 2011 Share Posted July 23, 2011 Can you remove the PCI nic card and use the onboard one? But the onboard one isn't Gigabit, hence the reason for me buying the PCI one. Is there another driver-based solution? Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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. Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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. Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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 Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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. Quote Link to comment
btlupin Posted July 23, 2011 Share Posted July 23, 2011 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. Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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? Quote Link to comment
capler Posted July 23, 2011 Share Posted July 23, 2011 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. syslog-20110723-223441.txt.zip Quote Link to comment
btlupin Posted July 23, 2011 Share Posted July 23, 2011 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. Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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 Quote Link to comment
limetech Posted July 23, 2011 Author Share Posted July 23, 2011 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. Quote Link to comment
btlupin Posted July 23, 2011 Share Posted July 23, 2011 When I get info on the shares, it shows that smb is being used. Quote Link to comment
capler Posted July 23, 2011 Share Posted July 23, 2011 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 Quote Link to comment
mrmachine Posted July 24, 2011 Share Posted July 24, 2011 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 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. Quote Link to comment
mrmachine Posted July 24, 2011 Share Posted July 24, 2011 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. Quote Link to comment
Recommended Posts
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.