Making netatalk discoverable in OpenSolaris

Previously I described how I had set up netatalk on my OpenSolaris storage server. That step went a long way to making it easy to use Time Machine to backup my Mac to the server. But having read kremalicious, I wanted to find a way to make the netatalk daemon discoverable by the Macs on my network. The same technique that Matthias used on Linux was not going to work on OpenSolaris. For starters, OpenSolaris doesn’t use avahi, it has it’s own solution in the form of the dns/multicast service. In place of creating a static configuration file, you use the dns-sd command line client on OpenSolaris. While this tool is not meant to be used to register long running services, it’s the only feasible solution at the moment. But just running that command in the background and leaving its fate to the gods is not good enough for me. It should be monitored using the Service Management Framework. This turns out to be surprisingly easy once you’ve read the SMF guide on BigAdmin.

Start by installing netatalk, if you haven’t already, as described in an earlier post. Next, create the SMF manifest file that will register the AFP daemon as a discoverable service. Name the file dnssd-afp.xml and place it in the /var/svc/manifest/site directory.

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="dnssd-afp">


      <service_fmri value="svc:/system/filesystem/local:default"/>

      <service_fmri value="svc:/network/dns/multicast:default"/>

        <method_credential user="root" group="root"/>


    <instance name="default" enabled="false" />

    <stability value="Unstable" />

        <loctext xml:lang="C">
          dns-sd registration of afp daemon
        <manpage title="dns-sd" section="1M" manpath="/usr/man"/>

Change the ownership of the manifest to root:sys and make it read-only by all but the root user. For this service, we’ll need to write a shell script that spawns dns-sd as a background process, otherwise SMF will timeout waiting for the service to start (the SMF documentation is better at explaining this than I am). Note that chihiro in the script is the hostname that will be advertised; you may want to change this to suit your needs.

# Registers the AFP daemon with dns-sd.
/usr/bin/dns-sd -R chihiro _afpovertcp._tcp local 548 &
/usr/bin/dns-sd -R chihiro _device-info._tcp. local 548 model=Xserve &
# Sleep to ensure service has enough time to start up,
# otherwise SMF will timeout waiting for it to be ready.
sleep 5

Place the shell script in the /lib/svc/method directory, give it the name dnssd-afp, change the ownership to root:bin, and make the file executable by all and writable only by root. Now we’re ready to import the service configuration and start the service. Import it using the command pfexec svccfg -v import /var/svc/manifest/site/dnssd-afp.xml, then start the service using pfexec svcadm enable dnssd-afp, and finally check that the service is running with svcs dnssd-afp. At this point, if the dns-sd process were to unexpectedly die, SMF will immediately restart it. That’s one of the many advantages of SMF over initd, which does not monitor the processes that it initiates. With the AFP service now registered, any Mac on your network should see your storage server as a Mac-compatible file share, which will appear automatically in the Finder sidebar. If you’ve added a shared volume to your Login Items previously, you can remove it, you won’t need it any more.

About these ads
This entry was posted in Computing, HowTo, Storage and tagged , , . Bookmark the permalink.

27 Responses to Making netatalk discoverable in OpenSolaris

  1. dominik says:


    first of all thanks for this hint. Could you please explain, where to save the shell script “Registers the AFP daemon with dns-sd” above and when to start?



  2. nlfiedler says:

    Sorry about that, forgot to mention where the script goes. The shell script could go anywhere, but the convention is to put it in /var/svc/method (you may have to create that directory). I’ve updated the post to include the path. Thanks for your comment.

  3. mads says:

    if i do “/usr/bin/dns-sd -R “test” _device-info._tcp. . 548 model=Macmini” and then “/usr/bin/dns-sd -R “test” _afpovertcp._tcp. . 548″ i get a mac mini icon…
    But in the linux docs they point the _device-info._tcp too port 0, so my question is, am i breaking anything by doing it this way?

    Thanks for the guide:D

  4. nlfiedler says:

    @mads: good question, and I don’t know the answer. According to the dns-sd man page, a port value of zero means the service is not available, and so using that appears to be a no-op. I’ve just set it up as you’ve done and it seems to be working fine. There are no messages in any of the logs, and my Mac sees the server exactly as intended (it’s viewed as a file server with the appropriate icon, Xserve in my case). So, while I don’t have the definitive answer, this approach seems to work just fine. To find out for sure, post your question to the nwam-discuss list on There’s at least one person there who works for Sun that should know the answer. Thanks.

  5. toto says:

    This works like a charm – for about five minutes.
    After that my Macs seem unable to resolve the addresses of the OpenSolaris machine via mDNS. Pretty weird. Have you experienced anything similar?

  6. nlfiedler says:

    @toto: I’m afraid I’ve not come across that situation before. I’d start by making sure the dns-sd process is still running, that the server is still reachable, that it’s IP/hostname hasn’t changed somehow, etc. But yes, that’s a weird symptom. Good luck.

  7. Mark says:

    Sweet guide man – appreciate all of the help getting some of us less experienced Solaris guys up to speed!

  8. nlfiedler says:

    Regarding where the script should go, the convention is _not_ to put it in /var/svc/method but rather /lib/svc/method. Not sure how I managed to miss that, but wanted to set the record straight.

  9. Jason says:

    Great stuff! Works like a charm!

  10. Tom Rowan says:

    Hi Nathan,

    Thanks very much fella. :-)
    You might want to incorporate the changes from the comment about how to change your icon into the original script. I worked it out of course, but it’s bound to be a common question so – as the rest of the FAQ is so clear! – it’s probably worth sticking in your script from the word go….?

    Thanks again..


  11. nlfiedler says:

    @Tom: good idea. I’ve added the line to the example script. Thanks.

  12. lars says:

    What is the name of the script “Registers the AFP daemon with dns-sd”?
    What name to use for this one.

    I’d save under the name /lib/svc/method/svc-dns-sd and did the command: pfexec svccfg -v import /var/svc/manifest/site/dnssd_afp.xml
    No errors
    pfexec svcadm enable dnssd_afp
    no errors
    but svcs dnssd_afp:
    maintenance 12:12:05 svc:/site/dnssd_afp:default

    I thing that the error is in the filename!

    Thanx in advance

  13. Nathan Fiedler says:

    @lars: I used the name dnssd_afp for the script and put it in /lib/svc/method. Hope that helps.

    • lars says:

      Now it works. :
      root@TimeMachine:/lib/svc/method# svcs dnssd_afp
      online 13:43:01 svc:/site/dnssd_afp:default
      Renaming to dnssd_afp did the work!

      I can now happily announce that I have a working TimeMachine based on OpenSolaris 2009.06 running in 64 bit mode on a AMD Athlon 64 CPU.

      Thanx for your help!

  14. Scruffy Bob says:

    Yes – the script name has to be “dnssd_afp”. Otherwise, you get the error:

    [ Sep 14 20:56:31 Executing start method ("/lib/svc/method/dnssd_afp"). ]
    /sbin/sh[1]: exec: /lib/svc/method/dnssd_afp: not found

  15. Mark says:

    Very nice write-up. The only problem I have is that I get an error when trying to browse the server using bonjour. I get an “can’t resolve link-local name” error. Any ideas?

    • nlfiedler says:

      @Mark: that’s a good question, and I don’t know the answer. Hopefully someone out there has encountered it before and found a solution, but I’ve never seen that error myself. Good luck.

  16. I’m a little confused about how this is supposed to work. Does this just implement the bonjour advertisement, or is it intended to actually start the AFP sharing daemon, replacing /etc/init.d/atalk? I expected the latter, but I wasn’t able to get “svcs dnssd_afp” to report other than “offline*” until after I did “/etc/init.d/atalk start”


    • nlfiedler says:

      This is in addition to the atalk daemon, simply making it easier to manage within OpenSolaris. Thanks for the comments, I’ll try to get the blob updated as soon as I can.

  17. So you don’t expect the new service to be able to do anything without first starting atalk? Is starting /etc/init.d/* part of the usual startup sequence for OpenSolaris, or do I need to do something additional for that?

    Also, note, it might be a good idea to note in the blog that “chihiro” is the name the fileserver will show up with.

    • nlfiedler says:

      Right, OpenSolaris, as with Solaris and most any Unix-like system that I’ve heard of, processes the init scripts on startup. The preferred solution in OpenSolaris is SMF, but I didn’t bother creating the necessary wrapper for atalk. Regarding the hostname, I thought of that too but figured people would look at the dnssd man page. In any case I’ll make a note of the hostname. Thanks for the feedback.

  18. Pingback: OpenSolaris + TimeMachine backup + network discovery « Matt Connolly’s Blog

  19. mattconnolly says:

    You can do the service discovery with the avahi-bridge service. I wrote an article here:

    Thanks for your very helpful posts!

  20. Rossi says:

    Hi, first of all you did a great job. The tutorial helped me a lot.

    My issue was a opensolaris afp network share wich works out of the box with time machine, like time capsule do.

    Did anybody found a solution how dns-sd offers the afp share like time machine wants to have it ?

    take care, Rossi

  21. Pingback: Showing the OpenSolaris netatalk share in your clients Finder « klein2 – technique blog

  22. Pingback: Adding AFP support to Nexenta Core 3.0 | Technical Ramblings

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s