FreeNAS

Note that for users who are running on an SSD and upgrade to High Sierra, Time Machine over SMB is required. SSD users cannot opt out of the APFS upgrade, which then makes Time Machine over AFP impossible. Source: https://support.apple.com/en-us/HT208018

Frank Riley wrote:

Note that for users who are running on an SSD and upgrade to High Sierra, Time Machine over SMB is required. SSD users cannot opt out of the APFS upgrade, which then makes Time Machine over AFP impossible. Source: https://support.apple.com/en-us/HT208018

I think the problem right now is that, unfortunately, the samba team has still yet to merge support into the main samba branches (there's still an open pull/merge request for this). I've posted to the discussion on these patches on the samba GitHub page and awaiting response. Hopefully stating that this is going to become a hard requirement under High Sierra may help move things along.

But yes, there's going to be a very high demand for Time Machine over SMB support in the very near future with the release of High Sierra and forced migration to APFS for SSD drive users (I'm facing that very issue now).

It appears Samba is indeed getting closer to having this feature included in the next Samba release.

https://github.com/samba-team/samba/pull/64

@Frank Riley,

I read the same Apple Support document that you have linked there, and I thought the same thing as you have reported: that Time Machine won't work at all if one upgrades to High Sierra / APFS. However, I have updated four different Macs - all using SSDs - and they all continue to work as of the time I write this note. I suspect that we will not have long however, as Apple is likely just giving NAS makers time to update their stuff; I still would like to see SMB support since that is clearly what Apple is requiring going forward. Who knows how long before Apple cuts off AFP completely?

originalprime - wrote:

@Frank Riley,

I read the same Apple Support document that you have linked there, and I thought the same thing as you have reported: that Time Machine won't work at all if one upgrades to High Sierra / APFS. However, I have updated four different Macs - all using SSDs - and they all continue to work as of the time I write this note. I suspect that we will not have long however, as Apple is likely just giving NAS makers time to update their stuff; I still would like to see SMB support since that is clearly what Apple is requiring going forward. Who knows how long before Apple cuts off AFP completely?

This PR has been around a while and discussed much: https://github.com/samba-team/samba/pull/64

If anyone in this ticket (or anyone following this ticket) would be willing to test this, I'd be happy to merge it into the nightlies. Let me know.

I've cherry picked the commits into the nightlies, feel free to test. I'll try and test as well. The code has modified avahi quite a bit so I'm not clear this will work 100% since we use mDNSResponder. I'll have to take a closer look.

I have been watching this issue and set up FreeNAS in a VM to test. On the 11.0 release train I can connect via smb, but once I switched to the nightlies train (most recently version FreeNAS-11-MASTER-201710080522) I can't connect via smb from my mac at all. The error message says "There was a problem connecting to the server <ip address>." "The share does not exist on the server. Please check the share name, and then try again."

I can connect just fine from Windows 10.

John, is this fixed by the recent work done for mDNS?

This doesn't appear to be working, but I'm also not sure if I set it up properly to be detected by Time Machine as the share doesn't appear to be broadcast via mDNS/Bonjour to the clients.

Maybe some basic instructions on how it's supposed to be properly setup would be helpful in verifying this is actually resolved.

Andrew: that would be a good question for the forums.

I somewhat disagree.

mDNSresponder should be advertising the SMB share as a Time Machine backup volume via Bonjour. Since we shouldn't be editing mDNSresponder's configuration directly, I assume there needs to be some option or checkbox in the SMB share configuration to mark this share as a Time Machine SMB share so the backend can properly configure mDNS to broadcast it as a Time Machine share and it'll show up in Time Machine as a valid backup location.

Andrew: 11.1 did add this: The Home Share Time Machine checkbox has been added to Services → AFP which is supposed to do the right thing. We need feedback from forum users who have actually used it so that we can update that section of the Guide.

That's for AFP (Apple File Protocol) shares which are completely different than SMB (Server Messaging Block) shares.

And the Time Machine checkbox has been in FreeNAS for AFP shares since forever as that's how FreeNAS currently supports Time Machine.

The underlying mechanics changed in 11.1. See https://redmine.ixsystems.com/issues/25522 and https://redmine.ixsystems.com/issues/17875.

Those issues have nothing to do with SMB only AFP (which is a deprecated protocol for Time Machine now). They are two completely different services on FreeNAS.

How is marking an AFP share as Time Machine going to effect a SMB share?

Andrew: we'll need a debug from an 11.1 system in order to proceed.

Hi Dru, Andrew, I hope you don't mind if I chime in here as this particular feature is of importance for us as well.

Dru, the links you provided are about a completely different thing: Apple Time Machine over AFP (Apple File Protocol), which is provided by Netatalk and works reasonably well.

Apple has since deprecated Time Machine over AFP from macOS release 10.13 (High Sierra) onwards, and officially, it does not work anymore since macOS 10.13 (technically you can still get it to work on modern macOS).

Apple now only supports TimeMachine over SMB (Samba), and Samba 4.7 shipped with FreeNAS 11.1 does not support this feature unless you patched the FreeNAS Samba according to https://bugzilla.samba.org/show_bug.cgi?id=12380.

So, this is a feature request, not a bug report. It needs work on samba, probably the GUI for enabling TimeMachine over SMB, some configuration changes for the TimeMachine-Samba-shares and some Bonjour-advertisements to make it all work.

This is a feature more or less needed by all the Mac-users out there who keep their systems up to date, as Apple might be disabling the TimeMachine over AFP-Feature any time now which would leave FreeNAS- (and TrueNAS-) users depending on FreeNAS for their backup standing in the rain. I'm more than willing to test this in a multi-client setup if needed.

If this is supposed to work already (TimeMachine via SMB, not via AFP) I'd equally be more than willing to test, but that would need some documentation as to how to configure this.

Hope this clarifies things a bit. Kind regards and have a good time at the end of the year!
Lukas

Hi, Lukas!

The stability of the patch you mentioned haven't proven yet itself, in the past we've seen a lot of unverified and broken code coming from the given source. So we don't rush to back-port it into the 11.1-11.2 and FreeNAS Samba 4.7.

As an alternative for now I'm planning to make this patch configurable feature for the FreeBSD Samba 4.7 port, where it's it'll get more chances to be tested and verified. If that would go well - it'll be included into the FreeNAS as well.

How was this closed with insufficient information? As far as I can tell there still isn't support for this in FreeNAS stable right now.
AFP is still working in High Sierra but it's more in limp mode than anything else. WWDC is only 3 months away and a GM build is roughly 8 months away and Apple isn't known for gracefully sunsetting anything.

I was unable to find another ticket of any kind that would lead to this feature getting implemented. Are there other information regarding this feature? If Apple pulls the plug on AFP this year 100% of macOS users saving their backup on their FreeNAS / TrueNAS boxes will be left unable to backup.

Thanks

Constantin Jacob wrote:

How was this closed with insufficient information? As far as I can tell there still isn't support for this in FreeNAS stable right now.
AFP is still working in High Sierra but it's more in limp mode than anything else. WWDC is only 3 months away and a GM build is roughly 8 months away and Apple isn't known for gracefully sunsetting anything.

I was unable to find another ticket of any kind that would lead to this feature getting implemented. Are there other information regarding this feature? If Apple pulls the plug on AFP this year 100% of macOS users saving their backup on their FreeNAS / TrueNAS boxes will be left unable to backup.

Thanks

Probably because I didn't provide a debug from my system when Dru requested it. A debug would be been pointless because the code hasn't been merged into the Samba branch that FreeNAS has been using.

As far as instability of the patched code, it's been accepted into the Samba 4.8 release which is undergoing final testing and due for release later this week (unless of course it's delayed) so there really shouldn't be any reason to upgrade Samba to 4.8 in a future release and hammer out the bits around UI configuration and Bonjour advertisement of the SMB share as supporting Time Machine backups.

In looking at this, I don't recall what happened. I remember cherry picking the code, but after looking at the original samba PR, I don't think I grabbed it all. I will look again. We do not use avahi so at the time I was confused on what this even accomplished, but not that I've looked again, there are more files changed than just the mdns portion. Give me some more time so I can see what's going on here.

Just for the record - Samba 4.8 got Time Machine support in the vfs_fruit. One complication is that it uses AVAHI for server discovery, while we use mdnsresponder - another implementation of mDNS server discovery, coming from Apple.

There is a possibility of back-porting of this module to 4.7, although it makes more sense just to upgrade to 4.8, but in any case we need to integrate with mDNSresponder first.

I'd just like to add a +1 for having Time Machine over SMB. I'm looking at buying a NAS from either ixsystems or Synology and it seems Synology already has SMB over Time Machine:

https://www.synology.com/en-us/knowledgebase/DSM/tutorial/Backup_Restore/How_to_back_up_files_from_Mac_to_Synology_NAS_with_Time_Machine

Could be a deciding factor in my case, and maybe for others too.

I verified that you can at least advertise an SMB share as time machine capable. That much worked. However, when tried as an actual time machine backup share, it failed. I haven't investigated yet but intend to get this working soon.

This is my first post; apologies if I'm in error.

Apple Time Machine support is one of the primary use cases of my NAS. I realize there there are or were missing upstream dependencies for this, but it's been well over a year, other vendors apparently have Time Machine over SMB support, and I still don't see movement on this issue.

I appreciate all the fine work you do, but an improved GUI experience is a much lower priority for me than a functioning Time Machine mount on the latest macOS. Near as I can tell, Time Machine over SMB support has been an issue since High Sierra, and now Mojave is production.

• Can someone give a status update on where FreeNAS is with this feature?
• Am I monitoring the right feature number?
• Is there better Time Machine support than I am aware of from a simple reading of this thread?

I've lagged behind a full macOS release cycle for this issue, but two release cycles is pushing it.

Thanks in advance!

David,

I'm the original submitter of the bug/feature request, it's the right one to keep track of (other bugs have been closed as dups of this one).

Time Machine over AFP continues to work in High Sierra (10.13) without any issues with FreeNAS 11.x. I cannot speak to Mojave (10.14), as I haven't attempted to upgrade any of my machines to it just yet (I'm waiting for some updated software for compatibility).

So it's safe to upgrade your Sierra-based machines to High Sierra without any loss of functionality of Time Machine as it's been proven to work.

I know this bug has gotten some traction (SMB working and advertising TM support) but does need a little love to push it over the finish line.

Thank you very much for the update!

Rather than update twice, perhaps I should wait a wee bit more for others to test out the current support on Mojave.

I will continue to monitor this thread.

(I feel a bit sheepish carping about lack of a feature, when you all are nice enough to offer it open source. I really do appreciate it.)

I feel the need to be another poster with a ‘+1’ request. I really appreciate the great work by the freenas team for a fabulous product that I love, but the lack of priority on this request is troubling.

Probably the most urgent thing is for a member of the freenas community to go guinea pig and upgrade to Mojave. If it turns out that AFP TM support still exists then lucky us, we can let it be for another year. But if not, it is going to be a scramble.

Hey everybody,

I have four physical machines (3 MacBook Pros +1 iMac) running Mojave and 2 of them are using AFP to do the Time Machine backups (from APFS volumes even). The other two need a new volume to backup to.
So far everything has been working fine and after the upgrade I didn't see a single thing from Mojave about using AFP.

I have just tried to restore a folder with a couple of documents (the backup ran on Tuesday night) and had no issue with it. It restored perfectly fine and I was able to open all the documents.

Mojave overall has been a really solid release so far. I've been running it on my main machine since beta 2 (or beta 3. Not quite sure anymore) without any issues.
During WWDC I met with people from Apple who told me they were allowed to spend a lot of time over the last 12 months on fixing things and making the OS' more efficient. Those stories seemed to be backing up the rumors from earlier this year, and the OS' reflect that as well. If you have doubts about it, wait for the .1 release and have a solid backup plan (I think that's why we're all here right?), but so far I can tell you that I'm very happy.
I think for now, Time Machine over AFP is safe but I agree with Nick that I'd like to see some more movement here.

Thanks for the great update Constantin Jacob - that’s very reassuring.

So it sounds like we’ll be ok for another year, but gee it would be great if we can get TM over SMB support into FreeNAS soon. Who knows - maybe we’ll see fewer of those ‘TM verification failed, start again messages’ if backing up over SMB. (OK probably not but I can wish - thank goodness for ZFS snapshots / rollbacks)

+1 here as well. Thanks, Constantin, I was holding off upgrading my systems because I was concerned that my current backup strategy (Time Machine to FreeNAS) wouldn't work with Mojave.

I really hope this doesn't slip past 11.3!

Well my 2¢ is that not supporting Time Machine over SMB gives FreeNAS the appearance of not supporting macOS well, especially when Synology already supports it. I still haven't decided which I'm going to buy, mostly because of this...

Hello,

Just an update from a MacOS Mojave user: I was prompted this morning to rebuild my backup and the Time Machine message recommended me to use SMB instead of AFP. I went ahead and tried to switch to SMB only to end up finally coming across this ticket. So from a layman's point of view this will become more necessary as Mojave adoption increases.

Thanks for all of the good work!

I've not seen that before on a Mojave machine but it's great to know that it tells you to use SMB instead of SMB...

Just to clarify for those who may not be familiar with Time Machine, having to rebuild the backup is something entirely unrelated to AFP and can happen even through a wired connection to an external USB drive. It's just TM being silly for some reason and being uncertain about the state of the backup.

It's not TM being silly; it's complaining because the disk image is corrupted. It doesn't know how corrupted, just that repairs are needed -- and repairing a volume over the network is painfully slow under the best of circumstances.

The corruption invariably happens because data was not flushed to disk as promised.

The patches to support time machine over SMB should already be in 11.1-U6. What needs to happen is:

1) Enable vfs_fruit on all SMB shares
2) set the parameter "fruit:time machine = yes" as an auxiliary parameter for the SMB share.
3) restart the SMB service via the UI.

You also need to advertise the share as a time machine drive via mDNS.

Yes, Andrew will need to read this ticket top to bottom. See in particular note #34 above: "One complication is that [Samba] uses AVAHI for server discovery, while we use mdnsresponder - another implementation of mDNS server discovery, coming from Apple."

mdnsresponder patches for samba are already in 11.1-U5+

In test environment try turning off AFP, and perform the steps I listed above.

Ah, so are these steps for OP and others to take to test the functionality that should already be present as of 11.1-U6?

Is it universally necessary to disable AFP for this test, or is it only necessary if there's a Time Machine AFP share? (I'm presuming the general issue is that you want only one service advertising Time Machine.)

Why is it necessary to enable vfs_fruit on all SMB shares?

@Andrew Walker,

I tried what you said:

1) On each SMB share, go into advanced and under the "VFS Objects" Section I added fruit and catia to the "Selected" list (found another post that said catia and streams_xattr were also needed for smb/mac)
2) Under "Auxilliary Parameters" for my time machine share, I added fruit:time machine = yes
3) Hit ok and it prompted me to restart the service, so I selected yes.

I can mount the other non-Time Machine SMB share on my Mac, but when I try to mount the Time Machine volume I get an error that says:

"There was a problem connection to the server "<freenas hostname>".
Check the server name or IP address, and then try again. If you continue to have problems, contact your system administrator."

In the console log I found the following errors:
default 22:09:16.232128 -0400 NetAuthSysAgent checkForDfsReferral: mounting dfs url failed, syserr = Unknown error: -1073741275
default 22:09:16.232256 -0400 NetAuthSysAgent smb_mount: mount failed to <freenas hostname>/<time machine share>, syserr = Unknown error: -1073741275

Let me know what other information I could provide!

Thanks!

Peter C wrote:

Ah, so are these steps for OP and others to take to test the functionality that should already be present as of 11.1-U6?

Correct. The pieces are there. I was able to perform time machine backups over SMB in a testing environment, but at this point it hasn't been robustly tested.

Is it universally necessary to disable AFP for this test, or is it only necessary if there's a Time Machine AFP share? (I'm presuming the general issue is that you want only one service advertising Time Machine.)

The key thing is to prevent multiple services from advertising as time machine.

Why is it necessary to enable vfs_fruit on all SMB shares?

The reason for this is that OS-X SMB clients will negotiate support for SMB2 AAPL protocol extensions on the first SMB server tree connect. This means that if you connect to a non-fruit share first then your OS-X client will not see the server as supporting time machine (or having other OS-X related capabilities).

To go with this, you should also add the following auxiliary parameters to your SMB shares once you've converted them to "fruit" so that your SMB clients are still able to access the already-written AFP_Info and AFP_Resource metadata.

fruit:metadata = stream
fruit:resource = stream

Once you have made these changes you can verify that the FreeNAS server is being properly identified by running the following command on an OS-X client:

smbutil statshares -a

Ben Nave wrote:

1) On each SMB share, go into advanced and under the "VFS Objects" Section I added fruit and catia to the "Selected" list (found another post that said catia and streams_xattr were also needed for smb/mac)

Catia is not strictly required. OS-X SMB clients will translate illegal NTFS characters (example ":") to unicode that characters that look sort of similar in Finder, but can be a pain to interact with through an SSH session on the samba server. Catia can basically dynamically re-map the name coming across the wire to what it was before OS-X translated it for SMB. It's useful in some situations (especially if you want consistency f you're sharing the same dataset via SMB and AFP simultaneously).

I can mount the other non-Time Machine SMB share on my Mac, but when I try to mount the Time Machine volume I get an error that says:

"There was a problem connection to the server "<freenas hostname>".
Check the server name or IP address, and then try again. If you continue to have problems, contact your system administrator."

Increase logging under Services -> SMB to "full", then reproduce the problem with the time machine share. I will email you from my ixsystems email address. Please generate a debug file (system->advanced->save debug) and attach it in response to the email. This is so that we can keep this ticket public-facing.

Andrew Walker wrote:

The patches to support time machine over SMB should already be in 11.1-U6. What needs to happen is:

1) Enable vfs_fruit on all SMB shares
2) set the parameter "fruit:time machine = yes" as an auxiliary parameter for the SMB share.
3) restart the SMB service via the UI.

.

• Are the patches already in the 11.2 stream as well (in addition to 11.1-U6+)?

.
.
.

Andrew Walker wrote:

Ben Nave wrote:

1) On each SMB share, go into advanced and under the "VFS Objects" Section I added fruit and catia to the "Selected" list (found another post that said catia and streams_xattr were also needed for smb/mac)

Catia is not strictly required.

.

freeNAS documentation (Sharing:SMB) wrote [https://doc.freenas.org/11/sharing.html]:

Fruit: Enhances macOS support by providing the SMB2 AAPL extension and Netatalk interoperability. Automatically loads catia and streams_xattr but read the caveat in NOTE below table.

.

• Is there any reason to select catia and/or streams_xattr if fruit is already enabled?

I can confirm Time Machine over SMB has been working for me the last few weeks on FreeNAS-11.1-U6 (and on the 11.3 nightlies as well).

I have 'fruit' enabled on all SMB shares, and "fruit:time machine = yes" on the time machine shares.

What are the consequences of not setting these?
```
fruit:metadata = stream
fruit:resource = stream
```

It didn't seem to work with those enabled but I didn't try too hard to debug the issue.

@Andrew Miskell, do these instructions work for you?

@John Hiesey, I think those settings don't matter if you're not using a preexisting backup -- I believe they tell SMB to read/write the metadata in the same way the netatalk/AFP did.

I will make separate PR for 11.2 once I bring samba up to 4.7.12.

Nice, thanks Andrew! What do these patches address, since it sounded like you thought the functionality was already there?

Also, one observation: I suspect the volume UUID is needed for detecting a malicious server. Normally when the UUID changes, Time Machine yells about a possible malicious server trying to sneakily get a copy of our backups. If it's always zero, you might be introducing an indirect security risk to Time Machine clients, since if someone guesses my server's name and uses a zero UUID, my laptop might just start backing up to the impostor...

I couldn't tell if that part of the patch was yours or cherry-picked from upstream Samba.

I can of course address the risk for myself by setting "fruit:volume_uuid", but it might be advisable to avoid a default of 0 (or none).

PR for freenas/freenas - 11.2: https://github.com/freenas/freenas/pull/2338/files

Great to see progress on this ticket!

Do the recent notes mean that it should work if one switches to "FreeNAS-11-Nightlies"?

Sean McBride wrote:

Great to see progress on this ticket!

Do the recent notes mean that it should work if one switches to "FreeNAS-11-Nightlies"?

I've been using this for several weeks on both 11.1 and 11.2 and it appears to be working as expected.