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

[Kevin Anderson]

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


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

> 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