Initial / experimental support for time machine over SMB

[anodos]

Experimental support for time machine over SMB is in FreeNAS 11.1-U5 and 11.1-U6

Step 1: enable "vfs_fruit" on ALL SMB shares. This is _required_ because OS-X SMB clients negotiate support for the SMB2_AAPL protocol extensions on the first SMB2 tree connect.

Step 2: Add auxiliary parameter "fruit:time machine = yes" to the SMB share you want to use for time machine backups.

Step 3: Restart samba in the UI (not the command line. we need to properly restart mdns as well as samba)

Caveats:
a) you may need to disable time machine over AFP
b) you may need to mount the SMB share before it will appear as a backup target.
c) this feature has not been robustly QA-ed yet, but feel free to take it for a spin.

 

[kdragon75]

Does this mean that in 11.2-Release (or what ever it will be called) will have a dummy proof all sharers auto magically default to vfs_fruit enabled when adding a new time machine enabled share?
Will there be a simple check box to replace the "fruit:time machine = yes"?
Will that auto magically restart samba and mdns? Is the lack of testing support on 11.2+ indicative of some samba regression?
Would the "vfs_fruit enabled" be reverted when removing the last "Time Machine" enabled share?
What kind of fruit is your favorite?
If we don't update our fruit, will be get fruit fly's?

Sorry for the questions. I like to know things.

 

[anodos]

Does this mean that in 11.2-Release (or what ever it will be called) will have a dummy proof all sharers auto magically default to vfs_fruit enabled when adding a new time machine enabled share?
Will there be a simple check box to replace the "fruit:time machine = yes"?
Will that auto magically restart samba and mdns?

I don't think there have been any firm decisions on how to implement this. In general we want to go in the direction of simplifying / dummy-proofing the webui. Checkboxes and automatically doing the right thing are a good start. I just posted this information so that those who want to experiment can do so.

Is the lack of testing support on 11.2+ indicative of some samba regression?

No. There is no regression in samba. These patches were pulled in a while ago, and I've verified things work as expected in my environment.

There has actually been little change to samba since the initial 11.1 release. 11.2 will stay on samba 4.7 and receive security fixes. 11.3 will be on 4.9 (if everything goes according to plan).

 

[Stux]

Looking forward to testing this out. I’d like to retire my macOS x server.

 

[Bytesplit]

This sounds nice, especially as I don't want to switch to 11.2-BETAs yet...

Do I get it right that the FreeNAS Samba 4.7 has the optional Time Machine-patches built in? I think normally they arrived in 4.8.

Also what about Avahi? According to https://gist.github.com/ChloeTigre/4c2022c0d1a281deedba6f7539a2e3ae Avahi needs also to be configured. Same question to quotas: do we still need to setup .com.apple.TimeMachine.quota.plist and .com.apple.timemachine.supported for the TM share? EDIT: Yes we are using MDNS instead of Avahi... and I see you wrote it's being configured on restart.

It's a little tough to move an existing backup (BTW: the now offline pondini.org can be found on archive.org: http://web.archive.org/web/20170620052530/http://pondini.org:80/TM/B6.html).

 

[anodos]

Do I get it right that the FreeNAS Samba 4.7 has the optional Time Machine-patches built in? I think normally they arrived in 4.8.

We cherry-picked the fixes into 4.7

Also what about Avahi? According to https://gist.github.com/ChloeTigre/4c2022c0d1a281deedba6f7539a2e3ae Avahi needs also to be configured. Same question to quotas: do we still need to setup .com.apple.TimeMachine.quota.plist and .com.apple.timemachine.supported for the TM share? EDIT: Yes we are using MDNS instead of Avahi... and I see you wrote it's being configured on restart.

Correct, we fixed mdnsresponder in Samba so everything should theoretically work correctly.

 

[Bytesplit]

Ok, had some time to check things.

Running one client on El Capitan which as it seems does not support SMB backups for TM. AFP still working.
Running one client on High Sierra which does not see the share in "Select Disk..." by default.
I need to manually mount the share and then I can select it. TimeMachine support is advertised correctly but apparently the MDNS part does not seem to be working.

A dig from the clients:

Code:

dig @224.0.0.251 -p 5353 SRV nas._smb._tcp.local
;; QUESTION SECTION:
;nas._smb._tcp.local.	   IN   SRV

;; ANSWER SECTION:
nas._smb._tcp.local.   10   IN   SRV   0 0 445 nas.local.

;; ADDITIONAL SECTION:
nas.local.	   10   IN   A   192.168.3.17
nas.local.	   10   IN   AAAA   fe80::3ea8:2aff:fe9f:9884
nas.local.	   10   IN   AAAA   fd00::3ea8:2aff:fe9f:9884

SRV works. But both _adisk._tcp and _device-info._tcp stay unanswered unless I re-enable AFP. Apparently as AFP is sending out the _adisk-reply the connection will use AFP not SMB:

Code:

;; ANSWER SECTION:
nas._adisk._tcp.local.   10   IN   TXT   "sys=waMa=0,adVF=0x100" "dk0=adVN=MyTimeMachine,adVF=0xa1,adVU=6EB6B897-3838-4681-610B-898944A4635A"
nas._adisk._tcp.local.   10   IN   SRV   0 0 548 nas.local.

I'm wondering how mdnsd is getting configured. I cannot seem to find a config file so I guess it's autoconfigured by the other services!?

I for now played with avahi on a Linux machine cross-publishing the MDNS response for FreeNAS.

Code:

;; ANSWER SECTION:
nas._adisk._tcp.local.   10   IN   TXT   "sys=waMa=0,adVF=0x100" "dk0=adVN=MyTimeMachine,adVF=0xa3,adVU=6EB6B897-3838-4681-610B-898944A4635A"
nas._adisk._tcp.local.   10   IN   SRV   0 0 0 nas.local. (Port is 0 as 445 or 548 can be used / could also be related to avahi host-mapping)

For the shared disk in use adVF=0xa1 would result in AFP
For the shared disk in use adVF=0xa2 would result in SMB
For the shared disk in use adVF=0xa3 would result in BOTH (AFP for old clients and SMB for newer)

The adVF a can also be set to 8 as in many other samples. For me 83 and a3 did show the same behavior. For more background the interesting thread is on the Samba list: https://lists.samba.org/archive/samba-technical/2017-July/121855.html.

I guess this needs some more advanced methodology when running both Netatalk and Samba side-by-side.


BTW: FreeNAS build is 11.1-U6

 

[eexodus]

Thank you for this. I will be using it on over 20 Macs.

 

[eexodus]

Unfortunately I can't setup Time Machine on the Macs. I get the error "Time Machine can't connect to the backup disk. The operation couldn't be completed. (OSStatus error 17.)" My FreeNAS box is on a different subnet but I can mount the Time Machine SMB share. AFP is turned off completely on FreeNAS. All SMB shares (24 including TWO Time Machine shares) have VFS fruit. The two TM shares have "fruit:time machine = yes" under Auxiliary Parameters. Any ideas?

Some more info: each SMB share including the two TM shares are there own datasets. The normal SMB shares have two Aux Parameters: "nfs4:aclmode=simple" and "valid users = @"domain\file admins", domain\backupuser". The normal SMB shares are Windows datasets with the permissions managed through Windows. The two TM shares are Mac datasets with the permissions: Owner (user) domain\backupuser and Owner (group) domain\file admins.

Even when I remove all SMB shares and leave only a single SMB TM share I am getting the same error.

EDIT SOLUTION: Looks like this is a Finder bug if the share is already mounted (which is needed if the share is not on your subnet). The solution is to mount the drive and choose it in TM System Preferences, when presented with the login prompt though go back to Finder and unmount the drive. You should then be able to login after returning to the login prompt and start the TM backup: https://apple.stackexchange.com/que...stination-fails-with-osstatus-error-17/310549

 

[kpfleming]

I've started experimenting with this after upgrading FreeNAS to 11.2-RC2. I created a new Windows (SMB) Share following the instructions above, with the AFP service stopped. The share is not advertised via mDNS at all; using 'avahi-browser --all' I see various other services advertised by FreeNAS (Web site, SSH, SFTP server), but no Samba shares.

 

[anodos]

I've started experimenting with this after upgrading FreeNAS to 11.2-RC2. I created a new Windows (SMB) Share following the instructions above, with the AFP service stopped. The share is not advertised via mDNS at all; using 'avahi-browser --all' I see various other services advertised by FreeNAS (Web site, SSH, SFTP server), but no Samba shares.

I will try to take a closer look into this at the end of the week.

 

[kpfleming]

Thanks, although this is rapidly becoming less important for me because the last two machines running macOS in my network are being replaced or 'upgraded' to Linux

 

[anodos]

Ok, had some time to check things.

Running one client on El Capitan which as it seems does not support SMB backups for TM. AFP still working.
Running one client on High Sierra which does not see the share in "Select Disk..." by default.
I need to manually mount the share and then I can select it. TimeMachine support is advertised correctly but apparently the MDNS part does not seem to be working.

A dig from the clients:

Code:

dig @224.0.0.251 -p 5353 SRV nas._smb._tcp.local
;; QUESTION SECTION:
;nas._smb._tcp.local.       IN   SRV

;; ANSWER SECTION:
nas._smb._tcp.local.   10   IN   SRV   0 0 445 nas.local.

;; ADDITIONAL SECTION:
nas.local.       10   IN   A   192.168.3.17
nas.local.       10   IN   AAAA   fe80::3ea8:2aff:fe9f:9884
nas.local.       10   IN   AAAA   fd00::3ea8:2aff:fe9f:9884

SRV works. But both _adisk._tcp and _device-info._tcp stay unanswered unless I re-enable AFP. Apparently as AFP is sending out the _adisk-reply the connection will use AFP not SMB:

Code:

;; ANSWER SECTION:
nas._adisk._tcp.local.   10   IN   TXT   "sys=waMa=0,adVF=0x100" "dk0=adVN=MyTimeMachine,adVF=0xa1,adVU=6EB6B897-3838-4681-610B-898944A4635A"
nas._adisk._tcp.local.   10   IN   SRV   0 0 548 nas.local.

I'm wondering how mdnsd is getting configured. I cannot seem to find a config file so I guess it's autoconfigured by the other services!?

I for now played with avahi on a Linux machine cross-publishing the MDNS response for FreeNAS.

Code:

;; ANSWER SECTION:
nas._adisk._tcp.local.   10   IN   TXT   "sys=waMa=0,adVF=0x100" "dk0=adVN=MyTimeMachine,adVF=0xa3,adVU=6EB6B897-3838-4681-610B-898944A4635A"
nas._adisk._tcp.local.   10   IN   SRV   0 0 0 nas.local. (Port is 0 as 445 or 548 can be used / could also be related to avahi host-mapping)

For the shared disk in use adVF=0xa1 would result in AFP
For the shared disk in use adVF=0xa2 would result in SMB
For the shared disk in use adVF=0xa3 would result in BOTH (AFP for old clients and SMB for newer)

The adVF a can also be set to 8 as in many other samples. For me 83 and a3 did show the same behavior. For more background the interesting thread is on the Samba list: https://lists.samba.org/archive/samba-technical/2017-July/121855.html.

I guess this needs some more advanced methodology when running both Netatalk and Samba side-by-side.


BTW: FreeNAS build is 11.1-U6

Thank you very much for posting this information. I believe I was able to fix the adisk advertisements.

Code:

Andrews-MacBook-Pro:CODE awalker$ dns-sd -B _adisk._tcp .
Browsing for _adisk._tcp
DATE: ---Wed 12 Dec 2018---
5:28:17.178  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
5:28:17.179  Add        2   5 local.               _adisk._tcp.         S49TEST

I'm still testing, but so far the results look promising.

 

[anodos]

Looks like my first backup was a success.

 

[Bytesplit]

Do you mind sharing your changes? I've upgraded to 11.2 and could do a quick test run if you are able to provide a changeset.

I hope the final release will take all three (AFP, SMB or both) variants into account. At least in the moment I'm unable to give up on the old AFP clients.

 

[anodos]

Do you mind sharing your changes? I've upgraded to 11.2 and could do a quick test run if you are able to provide a changeset.

I hope the final release will take all three (AFP, SMB or both) variants into account. At least in the moment I'm unable to give up on the old AFP clients.

The changes are in compiled code, but they should be in the nightlies for 11.3 Master if you want to give it a quick spin. The patch for our FreeBSD port was generated from this https://github.com/anodos325/samba/commit/4f75e23a82a35443fc7d46e671dcf6dcfd644b79

At present there is no UI integration. You will have to add vfs_fruit to a share and then set "fruit:time machine = true". My testing was performed on a custom 11.2 build. I will move it into 11.2-stable once I've made a few more samba-related changes.

 

[NineFingers]

Is this working in 11.2 yet? My Mojave Macs are failing on 11.1-U6, even with fruit enabled, etc.

 

[Dollar Bill]

Experimental support for time machine over SMB is in FreeNAS 11.1-U5 and 11.1-U6

Step 1: enable "vfs_fruit" on ALL SMB shares. This is _required_ because OS-X SMB clients negotiate support for the SMB2_AAPL protocol extensions on the first SMB2 tree connect.

Step 2: Add auxiliary parameter "fruit:time machine = yes" to the SMB share you want to use for time machine backups.

Step 3: Restart samba in the UI (not the command line. we need to properly restart mdns as well as samba)

Caveats:
a) you may need to disable time machine over AFP
b) you may need to mount the SMB share before it will appear as a backup target.
c) this feature has not been robustly QA-ed yet, but feel free to take it for a spin.

I am new to using FreeNAS. When you say enable "vfs_fruit" do you just mean adding that line to auxiliary parameters as well or is there more to it?

 

[itskando]

Experimental support for time machine over SMB is in FreeNAS 11.1-U5 and 11.1-U6

Step 1: enable "vfs_fruit" on ALL SMB shares. This is _required_ because OS-X SMB clients negotiate support for the SMB2_AAPL protocol extensions on the first SMB2 tree connect.

Step 2: Add auxiliary parameter "fruit:time machine = yes" to the SMB share you want to use for time machine backups.

Step 3: Restart samba in the UI (not the command line. we need to properly restart mdns as well as samba)

Caveats:
a) you may need to disable time machine over AFP
b) you may need to mount the SMB share before it will appear as a backup target.
c) this feature has not been robustly QA-ed yet, but feel free to take it for a spin.

Followed this guide to start:


.

Created user timemach with group timemach.

Created dataset: /backup
Created dataset: /backup/timemachine
Created dataset: /backup/timemachine/laptopname
(For all: used Windows permissions.)

Created SMB share: backuptmLaptopnameSMB
Set to dataset: /backup/timemachine/laptopname
Set host allow to IP range: 192.168.86.0/24
Enabled fruit (other SMB share for user home directories also has fruit enabled.)
Added auxiliary parameter "fruit:time machine = yes"

Couldn't find SMB on PC in Time Machine.
Mounted SMB, appeared in Time Machine.
Used credentials for user timemach.

Received error:

Time Machine can't connect to the backup disk.
The operation couldn't be completed. (OSStatus error 17.)

 

[matthew_keough]

Experimental support for time machine over SMB is in FreeNAS 11.1-U5 and 11.1-U6

Step 1: enable "vfs_fruit" on ALL SMB shares. This is _required_ because OS-X SMB clients negotiate support for the SMB2_AAPL protocol extensions on the first SMB2 tree connect.

Step 2: Add auxiliary parameter "fruit:time machine = yes" to the SMB share you want to use for time machine backups.

Step 3: Restart samba in the UI (not the command line. we need to properly restart mdns as well as samba)

Caveats:
a) you may need to disable time machine over AFP
b) you may need to mount the SMB share before it will appear as a backup target.
c) this feature has not been robustly QA-ed yet, but feel free to take it for a spin.

This SMB TimeMachine worked fine! Running FreeNAS-11.2-RELEASE-U1 (Build Date: Dec 20, 2018 22:41)
There was not a "vfs_fruit" option, just "fruit" under VFS Objects.

Used "Connect to server" though Finder, smb://192.168.2.200/, login as root (my account did not work), and it was available in my TimeMachine devices.

I also have 2 additional AFP and SMB folders setup and it is not affected.