- Avahi is a free Zero-configuration networking (zeroconf) implementation, including a system for multicast DNS/DNS-SD service discovery. It allows programs to publish and discover services and hosts running on a local network with no specific configuration. For example you can plug into a network and instantly find printers to print to, files to look at and people to talk to. It is licensed under the GNU Lesser General Public License (LGPL).
Install the package.
You can manage the Avahi daemon with
avahi-daemon.service using systemd.
systemd-resolved.serviceentirely before using Avahi.
Avahi provides local hostname resolution using a "hostname.local" naming scheme. To enable it, install the start/enable
Then, edit the file
/etc/nsswitch.conf and change the
hosts line to include
mdns_minimal [NOTFOUND=return] before
hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
- If you experience slowdowns in resolving
.localhosts (or you do not want to use IPv6) try to use
- The line above makes
nss-mdnsauthoritative for the
.localdomain, unless your unicast DNS server responds to
SOAqueries for the top level
localname, or if the request has more than two labels. See
Configuring mDNS for custom TLD
mdns_minimal module handles queries for the
.local TLD only. Note the
[NOTFOUND=return], which specifies that if
mdns_minimal cannot find
*.local, it will not continue to search for it in
In case you want Avahi to support other TLDs, you should:
mdns_minimal [NOTFOUND=return]with the full
mdnsmodule. There also are IPv4-only and IPv6-only modules
domain-nameof your choice
- whitelist Avahi custom TLDs in
Avahi includes several utilities which help you discover the services running on a network. For example, run
$ avahi-browse --all --ignore-local --resolve --terminate
to discover services in your network.
The Avahi Zeroconf Browser (
avahi-discover – note that it needs Avahi's optional dependencies , and ) shows the various services on your network. You can also browse SSH and VNC Servers using
Be sure to open UDP port
5353 if you are using a firewall.
Link-Local (Bonjour/Zeroconf) chat
Avahi can be used for Bonjour protocol support under Linux. Check Wikipedia:Comparison of instant messaging clients or List of applications#Instant messaging clients for a list of clients supporting the Bonjour protocol.
Obtaining IPv4LL IP address
The dhcpcd client can attempt to obtain an IPv4LL address if it failed to get one via DHCP. By default this option is disabled. To enable it, comment noipv4ll string:
... #noipv4ll ...
# avahi-autoipd -D
Avahi advertises the services whose
*.service files are found in
/etc/avahi/services. Files in this directory must be readable by the
If you want to advertise a service for which there is no
*.service file, it is very easy to create your own.
As an example, let us say you wanted to advertise a quote of the day (QOTD) service operating per RFC:865 on TCP port
17 which you are running on your machine
The first thing to do is to determine the
<type>. indicates that the type should be "the DNS-SD service type for this service. e.g. '_http._tcp'". Since the DNS-SD register was merged into the IANA register in 2010, we look for the service name on the IANA register or in
/etc/services file. The service name shown there is
qotd. Since we are running QOTD on tcp, we now know the service is
_qotd._tcp and the port (per IANA and RFC 865) is
Our service file is thus:
<?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_qotd._tcp</type> <port>17</port> </service> </service-group>
For more complicated scenarios, such as advertising services running on a different server, DNS sub-types and so on, consult.
Keep in mind that Avahi does not support arbitrary strings in the <type> field, you can only set values known in service database of Avahi. If you want to register something custom you will likely have to edit the database definition, build an updated version and distribute it to your hosts.
Avahi comes with an example service file to advertise an SSH server. To enable it:
# cp /usr/share/doc/avahi/ssh.service /etc/avahi/services/
.service file in
/etc/avahi/services with the following contents:
<?xml version="1.0" standalone='no'?> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">NFS Music Share on %h</name> <service> <type>_nfs._tcp</type> <port>2049</port> <txt-record>path=/data/shared/Music</txt-record> </service> </service-group>
The port is correct if you have insecure as an option in your
/etc/exports; otherwise, it needs to be changed (note that insecure is needed for macOS clients). The path is the path to your export, or a subdirectory of it. For some reason the automount functionality has been removed from Leopard, however a script is available. This was based upon this post.
With the Avahi daemon running on both the server and client, the file manager on the client should automatically find the server.
You can also auto-discover regular FTP servers, such as vsftpd. Install the package and change the settings of vsftpd according to your own personal preferences (see this thread on ubuntuforums.org or ).
.service file in
/etc/avahi/services with the following contents:
<?xml version="1.0" standalone='no'?> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name>FTP file sharing</name> <service> <type>_ftp._tcp</type> <port>21</port> </service> </service-group>
The FTP server should now be advertised by Avahi. You should now be able to find the FTP server from a file manager on another computer in your network. You might need to enable #Hostname resolution on the client.
Hostname changes with appending incrementing numbers
This is a known bug that is caused by a hostname race condition. One possible workaround is disabling IPv6 to attempt to prevent the race condition. If multiple interfaces are present use allow-interfaces to limit Avahi to a single interface. Another possible workaround is to disable the cache to prevent Avahi from checking for host name conflicts altogether, but this prevents Avahi from performing lookups.
systemd-resolved prevents nss-mdns from working
nss-mdns only works if the DNS server listed in
NXDOMAIN to SOA queries for the "local" domain.
Check if your configured DNS server answers the SOA query for the "local" domain with
NXDOMAIN first. For example:
$ host -t SOA local
If the DNS server responds with
NXDOMAIN, you do not need to follow the steps below.
Avahi should be able to find resources in the network normally, even if using systemd-resolved.
In older versions of systemd-resolved the global setting for
MulticastDNS=no in lead to Avahi-incompatible response codes for the "local" domain. This resulted in Avahi not finding resources (printers) correctly. See systemd issue 21659 for reference.
However, if the DNS query above fails to return
NXDOMAIN for the "local" domain, you can use the full
mdns NSS module instead of
mdns_minimal and create
/etc/mdns.allow to allow only the "local" domain. For example:
hosts: mymachines mdns [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
ECONNREFUSED (Connection refused) on avahi socket
If your Avahi instance starts and operates correctly, but nss does not seem to forward requests to mdns, this may be caused by stuck socket
/run/avahi-daemon/socket. This can be verified e.g. with strace. In this case you may have to restart both
avahi-daemon.socket to make it work correctly.