When AFP is disabled Server Not Advertised on MAC

[brent112]

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.

[itimpi]

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.

[limetech]

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.

[greenythebeast]

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.

[dgaschk]

Is the correct workgroup configured on the Mac?

[Joe L.]

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.

[brent112]

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.

[spylex]

Other NAS manufacturers like QNAP allow controlling UPNP/Bonjour separately from shares. It could be something you can implement here also.

 

[limetech]

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.

[limetech]

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.

[NAS]

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.

 

 

[limetech]

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.

[mrow]

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.

[NAS]

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

[whiteatom]

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

[limetech]

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.

 

 

 

[spylex]

@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.

[whiteatom]

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.

[Furby8704]

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 =/

[dgaschk]

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.

 

[dgaschk]

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

[Furby8704]

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

[gfjardim]

 

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>

[limetech]

    <service>
        <type>_http._tcp</type>
        <port>80</port>
    </service>

 

Why do you have this service defined?

[gfjardim]

Just a test, works alright without it.