Project

General

Profile

Bug #7133

Time Machine fails trying to find disk until AFP is restarted

Added by Anthony DeStefano almost 5 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Expected
Assignee:
Josh Paetzel
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

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.


Related issues

Has duplicate FreeNAS - Bug #19473: Time MachineClosed: Duplicate2016-12-08

Associated revisions

Revision 0631525b (diff)
Added by Josh Paetzel about 3 years ago

Reload netatalk to reregister it with mdns whenever mdns is restarted Ticket: #7133 https://forums.freenas.org/index.php?threads/timemachine-share-not-available.47107/

History

#1 Updated by Jordan Hubbard almost 5 years ago

  • Status changed from Unscreened to Closed: Cannot reproduce

I have 5 Macs all happily backing up to 9.3 with no hiccups or issues now. What version(s) of OS X are being used here?

#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:///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:///FreeNAS%20TimeMachine connects fine.

And setting the TM destination,
sudo tmutil setdestination -p afp:///FreeNAS\ TimeMachine

The automatic backups now work.

#4 Updated by Anthony DeStefano almost 5 years ago

Ray,

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

#8 Updated by Josh Paetzel about 3 years ago

  • Status changed from Closed: Cannot reproduce to Investigation
  • Assignee set to Josh Paetzel
  • Target version set to 9.10.2

ok, thanks for the clarification. I'll look in to this.

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

#10 Updated by Josh Paetzel about 3 years ago

  • Status changed from Investigation to Ready For Release

#12 Updated by Josh Paetzel about 3 years ago

#13 Updated by Dru Lavigne almost 2 years ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF