Time Machine fails trying to find disk until AFP is restarted
Upon upgrading to 9.3 I started to have issues with Time Machine mounting the remote disk. After the AFP services is started a time machine backup will work one time. On subsequent attempts the backup fails until the AFP is restarted. Other AFP connections are successful even when Time Machine says the disk cannot be found.
Here are the relevant logs on the client side:
12/14/14 6:51:33.569 PM com.apple.backupd1919: Attempting to mount network destination URL: afp://ajd@freenas._afpovertcp._tcp.local./Time%20Machine
12/14/14 6:52:03.595 PM com.apple.backupd1919: NAConnectToServerSync failed with error: 64 (Host is down) for url: afp://ajd@freenas._afpovertcp._tcp.local./Time%20Machine
12/14/14 6:52:03.597 PM com.apple.backupd1919: Backup failed with error 18: The backup disk could not be found.
#2 Updated by Anthony DeStefano almost 5 years ago
I've seen it on both a Macbook Pro running Yosemite and a Macbook Air running Mavericks.
I was doing some debugging tonight and it looks like it might be a mdns problem and not an AFP issue. If I hard code the path with "sudo tmutil setdestination -p afp://firstname.lastname@example.org/Time\ Machine", then it works fine. The issue is when the mac system tries to use the mdns path of freenas._afpovertcp._tcp.local.
Using the Bonjour Browser program on my Macbook Pro, the mdns responses from the FreeNAS server are painfully slow and sometimes do not resolve. I have other systems running netatalk on the network and they resolve instantly in Bonjour Browser. It may be hitting a timeout which is why the error when using the mdns name is "Host is down."
#3 Updated by Ray Price almost 5 years ago
I had exactly the same issue.
Manually triggering a backup was fine, however the automated backup always failed.
Doing, sudo tmdiagnose, the configuration/reachability.txt file shows:
Network Destination Response Times
=== freenas | ID: AAB34C2B-8E01-40FF-930C-F048A2949528 ===
Could not resolve Bonjour URL: freenas._afpovertcp._tcp.local
Indeed, using Finder to 'Connect to Server' with afp://ray@freenas._afpovertcp._tcp.local/FreeNAS%20TimeMachine fails.
However, afp://email@example.com/FreeNAS%20TimeMachine connects fine.
And setting the TM destination,
sudo tmutil setdestination -p afp://firstname.lastname@example.org/FreeNAS\ TimeMachine
The automatic backups now work.
#4 Updated by Anthony DeStefano almost 5 years ago
My mDNS timeout problem went away when I enabled IPv6 on my network interface. I went from lagged mDNS responses that usually hit a timeout to instantaneous responses with IPv6 enabled. With that change I was able to use the mDNS address for all AFP connections instead of directly configuring the destination.
#5 Updated by Michael Polanz over 4 years ago
- Category set to 78
I also have the same issue after an unspecified amount of time (sometimes days, sometime weeks) the AFP service stops answering to mDNS queries.
Enabling IPv6 doesn't help anything, but simply restarting the service does.
It instantly works again.
AFP itself always worked (Connect to to host "afp://192.168.1.3/")
I am using FreeNAS-9.3-STABLE-201505130355
#6 Updated by Jeff Hutchison over 3 years ago
- Priority changed from Nice to have to Expected
- Seen in changed from 9.3-RELEASE to 9.10-RELEASE
I just installed a new FreeNAS Mini last night and am seeing the exact same issue on 9.10. The Apple File Sharing and AirDisk mDNS entries drop off the network periodically until the afp service is restarted. IP6 doesn't seem to help.
#7 Updated by Jan Nieuwstad about 3 years ago
Making changes in FreeNas via the web interface sometimes triggers reload of several services including the mDNSresponder (mdnds). Due to this restart the .<hostname>._afpovertcp._tcp.local mDNS entry gets lost / is not registered again. This entry is needed by the Macs to find the TimeMachine disk. Restarting AFS solves this. It looks like AFS registers the _afpovertcp entry.
Hope this helps to reproduce the problem.
I've posted some log outputs on: https://forums.freenas.org/index.php?threads/timemachine-share-not-available.47107/#post-323356
#9 Updated by Josh Paetzel about 3 years ago
Alright, so it turns out that restarting or reloading samba restarts mdns. And samba is reloaded for all sorts of things that you wouldn't immediately expect it would need to be reloaded for.
And every time that happens netatalk loses it's mdns registration.