brent112 Posted June 8, 2013 Share Posted June 8, 2013 On my Macbook Pro when AFP is enabled in unRAID i see both "Servername" and "Servername - SMB" in Finder on the left hand side. When i disable AFP both of those shares go away. Is there a way to keep the "Servername - SMB" when AFP is disabled? With AFP disabled i can still connect to my shares by going to "Connect to Server" then manually typing in "smb://servername" but it would be nice it it auto detected it like it did when AFP is turned on. Link to comment
itimpi Posted June 8, 2013 Share Posted June 8, 2013 I suspect that this is a Mac issue to do with how it handles network discovery. If AFP is disabled, then the Apple network discovery protocol (Bonjour) will not be running at the unRAID end. Link to comment
limetech Posted June 8, 2013 Share Posted June 8, 2013 This is a known issue. The component responsible for device discovery in OSX world is "avahi", aka, zeroconf, aka bonjour. unRaid only starts this service when AFP is enabled. A workaround is to enable the AFP network service, but don't enable AFP for any shares. Link to comment
greenythebeast Posted June 8, 2013 Share Posted June 8, 2013 It works fine for me on rc12a. Which version are you using? Edit: By fine I mean I only have SMB enabled and the server shows up on my Mac in the sidebar. Link to comment
dgaschk Posted June 8, 2013 Share Posted June 8, 2013 Is the correct workgroup configured on the Mac? Link to comment
Joe L. Posted June 8, 2013 Share Posted June 8, 2013 It works fine for me on rc12a. Which version are you using? Edit: By fine I mean I only have SMB enabled and the server shows up on my Mac in the sidebar. Do you have an entry in your hosts file for the unRAID server? that might explain it. Link to comment
brent112 Posted June 9, 2013 Author Share Posted June 9, 2013 This is a known issue. The component responsible for device discovery in OSX world is "avahi", aka, zeroconf, aka bonjour. unRaid only starts this service when AFP is enabled. A workaround is to enable the AFP network service, but don't enable AFP for any shares. Thanks, I will give this a shot. I have tried to move away from AFP but I love the auto discovery. Link to comment
spylex Posted June 10, 2013 Share Posted June 10, 2013 Other NAS manufacturers like QNAP allow controlling UPNP/Bonjour separately from shares. It could be something you can implement here also. Link to comment
limetech Posted June 11, 2013 Share Posted June 11, 2013 Other NAS manufacturers like QNAP allow controlling UPNP/Bonjour separately from shares. It could be something you can implement here also. Yes that is the correct solution. Link to comment
limetech Posted June 28, 2013 Share Posted June 28, 2013 I changed AVAHI handling for 5.0 'final' as follows. First, AVAHI is now always enabled. This lets you get to the webGui in a pure-OSX environment by typing "tower.local" in your browser address bar, instead of having to either edit a config file to enable afp or finding your ip address and entering that. [This is why I made this change.] The effect of this is that: (substitute your server name for "tower" below if you changed it) a) if SMB is enabled and AFP is disabled (which is the default), Finder shows "tower-smb" and lets you access files using the SMB protocol. b) if SMB is enabled and AFP is enabled, you get two entries in Finder: "tower" and "tower-smb". Access is via AFP for "tower" and via SMB via "tower-smb". c) if SMB is disabled and AFP is enabled, you only get one entry in Finder, "tower", and access is via AFP. d) if both SMB and AFP disabled, nothing in Finder, but you still can access the webGui via "tower.local". So, no way to turn off AVAHI completely. If this proves to be problem, I'll add that control post-5.0-final. Link to comment
NAS Posted June 29, 2013 Share Posted June 29, 2013 We are now getting into territory where uNRAID should set a random hostname on first boot. Otherwise if you ever end up with 2+ unraid and dont change the default hostname on the first your going to have clashes. This has always been the case but the more avahi type stuff we add/rely on the worse the impact will be. Link to comment
limetech Posted June 29, 2013 Share Posted June 29, 2013 We are now getting into territory where uNRAID should set a random hostname on first boot. Otherwise if you ever end up with 2+ unraid and dont change the default hostname on the first your going to have clashes. This has always been the case but the more avahi type stuff we add/rely on the worse the impact will be. I guess another solution to this is to "strongly suggest" changing the hostname from "tower" to something else. Link to comment
mrow Posted June 29, 2013 Share Posted June 29, 2013 We are now getting into territory where uNRAID should set a random hostname on first boot. Otherwise if you ever end up with 2+ unraid and dont change the default hostname on the first your going to have clashes. This has always been the case but the more avahi type stuff we add/rely on the worse the impact will be. Avahi should append a "-2" to the end of the host name of the second device joining a network if it detects a host name collision. Not ideal but at least it will not prevent both servers from being detected on the network by bonjour aware devices. Hopefully at that point the user will realize they need to rename one or both devices. Link to comment
NAS Posted June 29, 2013 Share Posted June 29, 2013 We are now getting into territory where uNRAID should set a random hostname on first boot. Otherwise if you ever end up with 2+ unraid and dont change the default hostname on the first your going to have clashes. This has always been the case but the more avahi type stuff we add/rely on the worse the impact will be. I guess another solution to this is to "strongly suggest" changing the hostname from "tower" to something else. Yeah thats probably the best compromise for the short term at least We are now getting into territory where uNRAID should set a random hostname on first boot. Otherwise if you ever end up with 2+ unraid and dont change the default hostname on the first your going to have clashes. This has always been the case but the more avahi type stuff we add/rely on the worse the impact will be. Avahi should append a "-2" to the end of the host name of the second device joining a network if it detects a host name collision. Not ideal but at least it will not prevent both servers from being detected on the network by bonjour aware devices. Hopefully at that point the user will realize they need to rename one or both devices. Now thats something i didnt know. Is till think iun gernal this is an area needing addressed maybe its time to fork this thread Link to comment
whiteatom Posted September 5, 2013 Share Posted September 5, 2013 How were things prior to 5-final? Because I am on a Mac, and I use SMB only - AFP and NFS disabled. Before the upgrade, I had "tower" only and it worked perfectly all the time. It appeared in my side bar and all was well. Now I have the 2 entries - since I only need one protocol, is it essential to show 2 entries? I don't really care if it says -smb or not, I just don't want to fill my side bar with extra entries because I have several shared systems on my network. Cheers, whiteatom Link to comment
limetech Posted September 11, 2013 Share Posted September 11, 2013 How were things prior to 5-final? Because I am on a Mac, and I use SMB only - AFP and NFS disabled. Before the upgrade, I had "tower" only and it worked perfectly all the time. It appeared in my side bar and all was well. Now I have the 2 entries - since I only need one protocol, is it essential to show 2 entries? I don't really care if it says -smb or not, I just don't want to fill my side bar with extra entries because I have several shared systems on my network. Cheers, whiteatom Yes there was a change near the end of the -rc series where avahi, aka zeroconf, aka bonjour is always enabled. This was done in order to make it easier for OSX users to bring up the server webGui in their browser by entering "tower.local" in the address bar. Without avahi enabled, one has to enter the IP address. In Windows environment, the name resolution is provided by nmbd using netbios. What unRaid is doing is enabling only the "smb.service" file, which contains this: <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h-SMB</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group> But apparently what's happening is both the hostname (tower) and the service defined above (tower-smb) are recognized by OSX, and both links in finder's side bar point to the same thing (accessing shares via SMB protocol). If AFP is disabled and I remove the -SMB suffix like this: <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group> then you only see "Tower" in finder's side bar (and still using SMB). When AFP is enabled, you see two entries in finder's side bar: Tower - access to shares via AFP, and Tower-SMB - access to shares via SMB. What I don't like is in case where there's only "Tower" that access is via SMB, whereas with AFP is enabled, that access is via AFP - an inconsistency. I'm not sure how to fix this behavior, there's probably a way, perhaps in the avahi-daemon.conf file to have it not publish the hostname, that is, only publish names obtained via service files. I have not looked into this, but if anyone knows a fix for this I'll put it in to upcoming 5.0.1, otherwise I think I'll just restore the behavior described above (where if AFP is disabled but SMB is enabled, there will be a single "Tower" entry in side bar but access will be via SMB). Hope this makes sense. Link to comment
spylex Posted September 12, 2013 Share Posted September 12, 2013 @limetech competing NAS products (like QNAP) also have the same issue. You can only give unique names to the different avahi/bonjour services, as you demonstrated. I don't think it is a big issue but giving the choice of naming from the webGUI might help. Link to comment
whiteatom Posted September 14, 2013 Share Posted September 14, 2013 Thanks for the info Tom! I agree that configuring the service names over the GUI might be an option. The other option is to drop AFP support because Apple is in the next OS X. Link to comment
Furby8704 Posted September 18, 2013 Share Posted September 18, 2013 is there a way to revert back?? i came from rc12a and dislike having both entries. i already had my hosts file pickup my tower with ip address so i dont need it =/ Link to comment
dgaschk Posted September 18, 2013 Share Posted September 18, 2013 Thanks for the info Tom! I agree that configuring the service names over the GUI might be an option. The other option is to drop AFP support because Apple is in the next OS X. AFP is not being dropped in OS X 10.9. It is being depreciated for file sharing and is required for Time Machine. Link to comment
dgaschk Posted September 18, 2013 Share Posted September 18, 2013 is there a way to revert back?? i came from rc12a and dislike having both entries. i already had my hosts file pickup my tower without ip address so i dont need it =/ See here: http://lime-technology.com/forum/index.php?topic=13269.0 Link to comment
Furby8704 Posted September 18, 2013 Share Posted September 18, 2013 See here: http://lime-technology.com/forum/index.php?topic=13269.0 i just tried it and did not work for me. i still get double entry. thanks for the post though Link to comment
gfjardim Posted November 22, 2013 Share Posted November 22, 2013 I'm not sure how to fix this behavior, there's probably a way, perhaps in the avahi-daemon.conf file to have it not publish the hostname, that is, only publish names obtained via service files. I have not looked into this, but if anyone knows a fix for this I'll put it in to upcoming 5.0.1, otherwise I think I'll just restore the behavior described above (where if AFP is disabled but SMB is enabled, there will be a single "Tower" entry in side bar but access will be via SMB). Hope this makes sense. Tom, maybe SMB should always be referred as "Hostname", and AFP with "Hostname-AFP". This way, in OSX, the mDNS name will overwrite the Netbios name, and in Windows it will remain the same. This works ok. <?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_http._tcp</type> <port>80</port> </service> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group> Link to comment
limetech Posted November 23, 2013 Share Posted November 23, 2013 <service> <type>_http._tcp</type> <port>80</port> </service> Why do you have this service defined? Link to comment
gfjardim Posted November 23, 2013 Share Posted November 23, 2013 Just a test, works alright without it. Link to comment
Recommended Posts