Time Machine problem


Recommended Posts

There is an ancient problem with Time Machine shares not been detected by Mac OSX unless you mount it before you choose the disk. I tracked it down to be a lack of correct service announcement by avahi. One service, just like this, must be placed into the afp.service file:

 

    <service>

        <type>_adisk._tcp</type>

        <port>9</port>

        <txt-record>sys=waMA=xx:xx:xx:xx:xx,adVF=0x100</txt-record>

        <txt-record>dk1=adVF=0x83,adVN=TimeMachine1</txt-record>

        <txt-record>dk2=adVF=0x83,adVN=TimeMachine2</txt-record>

    </service>

 

As you can see, Tom, the service must bee altered with the mac address and the TM share name. Each time machine share should use it's own disk number (dk[ x ]).

Link to comment

There is an ancient problem with Time Machine shares not been detected by Mac OSX unless you mount it before you choose the disk. I tracked it down to be a lack of correct service announcement by avahi. One service, just like this, must be placed into the afp.service file:

 

    <service>

        <type>_adisk._tcp</type>

        <port>9</port>

        <txt-record>sys=waMA=xx:xx:xx:xx:xx,adVF=0x100</txt-record>

        <txt-record>dk1=adVF=0x83,adVN=TimeMachine1</txt-record>

        <txt-record>dk2=adVF=0x83,adVN=TimeMachine2</txt-record>

    </service>

 

As you can see, Tom, the service must bee altered with the mac address and the TM share name. Each time machine share should use it's own disk number (dk[ x ]).

Oh! ...this could solve one of life's great mysteries!

 

gfjardim,

I'm running mavericks, and can't find anything close.

I've searched for 'afp.service', afp, service, netatalk, avahi, bonjour, and 'adisk._tcp' .  No Joy.  :(

Could you please point me to the afp.service file you mention?

Link to comment

There is an ancient problem with Time Machine shares not been detected by Mac OSX unless you mount it before you choose the disk.

What do you mean by this?

 

I tracked it down to be a lack of correct service announcement by avahi. One service, just like this, must be placed into the afp.service file:

 

    <service>

        <type>_adisk._tcp</type>

        <port>9</port>

        <txt-record>sys=waMA=xx:xx:xx:xx:xx,adVF=0x100</txt-record>

        <txt-record>dk1=adVF=0x83,adVN=TimeMachine1</txt-record>

        <txt-record>dk2=adVF=0x83,adVN=TimeMachine2</txt-record>

    </service>

 

As you can see, Tom, the service must bee altered with the mac address and the TM share name. Each time machine share should use it's own disk number (dk[ x ]).

If the disk number (dk[ x] ) association to particular shares changes, will this cause problems on the OSX side?

Link to comment

1) Without _adisk._tcp service, Time Machine will only see a TM destination if it was already mounted.

 

2) Documents:

https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/TimeMachineNetworkInterfaceSpecification/Introduction/Introduction.html

http://netatalk.sourceforge.net/wiki/index.php/Bonjour_record_adisk_adVF_values

http://www.bootc.net/archives/2010/11/07/apple-time-machine-and-netatalk/

 

Accordingly to these documents, adVF should be 0x80, but I saw elsewhere it should be 0x83, and Apple define this value as 0x81.

 

The dk[ X ] is the disk number; X is an increasing number starting with 0. Every TM share should have it`s own disk number. Apple didn't say anything about it; I think the only requirement is uniqueness.

 

 

Link to comment

Interestingly (or not, as I haven't looked into it any further, and don't have any supporting logs etc), on my old unibody 2011 MBP running 10.8, I had to manually access the Time Machine share at least once on every reboot of the Mac to ensure it was available.  I just got used to doing it.

 

I've recently picked up a 2013 rMBP running Mavericks, and Time Machine no longer has this issue.  No changes at the unRAID end.  Not 100% sure if this relates to this issue, but I think it's the same.  If not, ignore this post and carry on ~ lol

Link to comment

I've recently picked up a 2013 rMBP running Mavericks, and Time Machine no longer has this issue.  No changes at the unRAID end.  Not 100% sure if this relates to this issue, but I think it's the same.  If not, ignore this post and carry on ~ lol

 

It's the same behavior, but now TM search for the share independent of Bonjour announcement, but only if the TM was already configured.

Link to comment
  • 1 year later...