vfs_fruit: Time Machine/FULLSYNC: add mDNS/DNS-SD advertisement

[Omri Mor]

> On Jul 19, 2017, at 19:28, Kevin Anderson <andersonkw2 at gmail.com> wrote:
> 
>> Yes, I saw that too. I’m currently using 0xa2 and adVU, so I wonder if the
>> problems I reported on GitHub have something to do with that.
> 
> It certainly wouldn't hurt to remove and test. I have been running
> with this avahi configuration
> https://github.com/kevinanderson1/samba-timemachine/blob/master/timemachine.service
> without any of the issues that you stated you were having. When I was
> testing backup consistency which included doing hard power off's of
> the file server, the client was always able to recover (albeit maybe
> having to restart the backup after a timeout), and the disk always
> passed backup verification. I didn't have to kill any processes on the
> Mac to get it to backup again.

I’ll test using 0x82, as well as actually specifying the MAC address. My current configuration is below:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_smb._tcp</type>
    <port>445</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=TimeCapsule</txt-record>
  </service>
  <service>
    <type>_adisk._tcp</type>
    <txt-record>sys=waMa=0,adVF=0x100</txt-record>
    <txt-record>dk0=adVN=Time Machine,adVF=0xa2,adVU=1f6f452a-0585-4267-8ce7-39d6874fba33</txt-record>
  </service>
</service-group>

>> I actually meant 0x20 (i.e. 0x80 | 0x20 = 0xa0), which as far as I know
>> isn’t documented anywhere. Netatalk uses 0xa1, which makes me wonder if it
>> is the cause of some of the the Time Machine on Netatalk issues (though Time
>> Machine issues occur using AFP on macOS Server / Time Capsule too, so it’s
>> probably not the only reason).
>> The Netatalk wiki is obviously outdated, now that 0x02 is documented. 0x03
>> would presumably mean that both AFP and SMB are supported.
>> The older Apple AFP Time Machine documentation also doesn’t say anything
>> about 0x20:
> 
> I have never run Netatalk so I can't really comment on it other than I
> know I have heard of many people having issues with backup consistency
> when running with AFP. That's why with the patch we enable strict
> sync'ing to ensure data gets flushed to disk when the client requests
> it. So far this seems to have improved the reliability in the backups
> based on my testing.
> 
> Also given that we disable most of the locking to gain durable file
> handles, I wouldn't recommend trying to share the same disk with both
> AFP and SMB.

I wasn’t saying that it’s a good idea to run both—just that a system that *had* both could presumably using 0x83.
Older versions of macOS that didn’t support Time Machine over SMB would use AFP, while newer ones would use SMB.

>> The Apple spec doesn’t document sys=waMa=0,adVF=0x100, which some of the
>> users (as well as Netatalk) say is needed.
>> One source (https://dreness.com/blog/archives/48) found that waMa is the MAC
>> address. The Netatalk wiki states that *this* adVF value forces prompting
>> for username and password, as well as hiding a bogus ‘home’ share.
>> I wonder if publishing adVF=0x182 will have the same effect.
>> 
> I haven't needed to publish those attributes (except for 0x82) to have
> a working configuration. Maybe they were just required for AFP
> backups? They don't seem to be required for SMB based backups
> according to what I have seen. Also I have always been prompted for a
> username/password and given the option to store it in the keychain for
> backups. As for hiding the home share, I would suspect that would be a
> Samba configuration but I will tinker with it later.

I just tested again, and if adVF=0x100 isn’t exported under the sys key, then macOS creates a bogus share with the name of the SMB login user—even when there isn’t a [homes] share!
See my smb.conf below:

[global]
    multicast dns register = no
    ea support = yes
    vfs objects = catia fruit streams_xattr
    fruit:copyfile = yes
    fruit:encoding = native
    fruit:time machine = yes

[Time Machine]
    path = /media/eSATA/timemachine/
    read only = no

Trying to connect to the bogus share causes Strange Things™ to happen—an entry in /Volumes/ is created, but then Finder reports an error and disconnects from SMB.
This really seems to be an issue on the macOS end, but since this seems to avoid the issue, it’s probably best to leave it in.
I’m not sure if this hides [homes] if it *is* defined—that’s something that will need to be tested.

>> Apple’s spec also doesn’t document that multiple Time Machine volumes on the
>> same server would use successive dkN values (dk0, dk1, …).
> 
> That is good to know. I currently don't have a need but I could see
> the use case.
> 
> -Kevin Anderson


I don’t have the need either, and I suspect *most* users will not, but it might be useful to business users—and will, in any case, be something that needs to be taken into account when setting up the mDNS/DNS-SD advertisement.

Omri