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

[Kevin Anderson]

Hey everyone,
    Sorry in advance for the wall of text.

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

Sorry. I misunderstood what you were saying.

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

For completeness here is the advertised mDNS configuration from a Mac
Server that I have laying around:
ProductName: Mac OS X
ProductVersion: 10.12
BuildVersion: 16A323

sys=waMa=0,adVF=0x100
dk0=adVN=Documents,adVF=0xa3,adVU=E14DFBCB-A2FC-418D-BCCB-528344A807A4


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 did some testing and I think I might have a reasonable guess as to
what sys=adVF=0x100 is used for (tested with and without waMa=0 with
the same results). It appears that setting tells the client whether it
should enumerate shares using the NetShareEnumAll IOCTL (srvsvc.opnum
== 15 in Wireshark). The setting itself it not important to Time
Machine backups working properly from what I can tell but I feel if
Samba is to configure the advertisement (which I am for) it should
also set sys=adVF=0x100 as well.

The test results below use the following configuration and a Linux
smbclient is used for additional verification:
(smb.conf)
[global]
        workgroup = SAMBA
        security = user
        passdb backend = tdbsam
        fruit:aapl = yes

[homes]

[capsule]
        path = /srv
        browseable = Yes
        vfs objects = catia fruit streams_xattr
        read only = No
        fruit:time machine = yes
        inherit acls = Yes

[test]
  path = /tmp
  readonly= true
  browseable = true

(avahi service)

<?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>_adisk._tcp</type>
   <port>0</port>
   <txt-record>sys=adVF=0x100</txt-record> (changed during testing)
   <txt-record>dk0=adVN=capsule,adVF=0x82</txt-record>
 </service>
</service-group>

 - With adVF=0x100;With a homes section defined: Finder and Linux
smbclient enumerates all the shares. A NetShareEnumAll call is also
made to the server with a proper response. All shares are accessible
 - Without adVF=0x100;With a homes section defined: Linux smbclient
enumerates the shares but Finder only sees the capsule share and a
share named after my user. I can connect to the shown shares and
manually connecting to the other shares does work properly.
 - With adVF=0x100; Without a homes section defined: Finder and Linux
smbclient enumerates all of the shares. A NetShareEnumAll call is also
made to the server with a proper response. All shares are accessible.
 - Without adVF=0x100;Without a homes section defined: Linux smbclient
enumerates the shares but Finder only see the capsule share and a
share named after my user. Connecting to the shares manually works
with the exception of the invalid user share.


NOTE: It appears the adVF=0x100 setting is only required when a
_adisk._tcp service is presented for that device. If the _adisk._tcp
service is not defined for a server, the MacOS client always
enumerates shares with NetShareEnumAll IOCTL.

For example this Avahi service file causes the client to always
enumerate shares with the NetShareEnumAll IOCTL:
<?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-group>


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

Good catch and thanks for bringing it up. Please see my results above.


-Kevin Anderson