Time machine backup on SMB share

  • Hi,


    I try to do a time machine backup on an OMV SMB share. I have OMV version 4.1.12 with all updates installed. SMB is running and I can connect to the backup share from the MAC. The smbd claims to be able to support Apples SMB extensions


    root@korostorage:~# smbd -b | grep -i fruit vfs_fruit_init


    In the configuration of SMB I have given the following extra options:


    vfs objects = catia fruit streams_xattrfruit:veto_appledouble = nofruit:encoding = nativefruit:metadata = stream


    The share itself has this extra options


    fruit:time machine = yesWith these settings I try to add this share as Time Machine target using


    sudo tmutil setdestination /Volumes/backup


    All I get is an error message that the share does not support Time Machine backups. Any hints on how to investigate this issue further?


    Regards


    Lars

  • Why don't you use the AFP plugin ?


    From: https://support.apple.com/en-us/HT208018 ---
    "Any Time Machine share points must be shared over SMB instead of AFP."


    From: https://support.apple.com/en-us/HT207828 ---
    "AFP can’t share files on Apple File System (APFS). Apple File System (APFS) is the default file system in macOS High Sierra for Mac computers with all-flash storage. You can't opt out of the transition to APFS when you upgrade a Mac with all-flash storage to macOS High Sierra. Learn more about APFS in macOS High Sierra.


    If you need to share files, switch to SMB. If you have network home directories shared via AFP on an APFS volume, update the mount records and user records to use SMB."


    From 2013: https://appleinsider.com/artic…mb2-in-os-x-109-mavericks

  • All I get is an error message that the share does not support Time Machine backups. Any hints on how to investigate this issue further?


    Please let us know if you get this figured-out. I fear that OMV needs a newer version of SMB.


    https://www.reddit.com/r/apple…_machine_via_smb_but_how/


    https://developer.apple.com/li…chine_SMB_Spec/index.html


    https://bugzilla.samba.org/show_bug.cgi?id=12380

  • "Any Time Machine share points must be shared over SMB instead of AFP."

    This (and the other Apple link) talk about shares residing on

    • a Mac running macOS
    • an APFS filesystem

    OMV neither runs on macOS nor can cope with APFS so simply use AFP/Netatalk shares for TimeMachine as in the past. Once OMV5 is ready we can talk again about SMB shares for TimeMachine.

  • OMV neither runs on macOS nor can cope with APFS so simply use AFP/Netatalk shares for TimeMachine as in the past. Once OMV5 is ready we can talk again about SMB shares for TimeMachine.

    Thank you.
    My understanding is Mac OS X has been using APFS for a few years now. OMV does not need to "cope" with or support APFS. I think the need is for OMV to support a more modern SMB service.
    Simply using AFP/Netatalk shares for TimeMachine do not work as they have in the past. My experience is --- My MacBook Pro from 2015 runs the current Mac OS, for nearly three years I have not been able to get a truly usable TimeMachine backup to/from my OMV (3.x 4.x) server. My understanding is that OMV's version of SMB does not have the features that TimeMachine needs to fuction. It has been my hope, and I suspect other's as well, that OMV4 would support TimeMachine. I am pleased by your hint that OMV5 may support SMB shares for TimeMachine.

  • It has been my hope, and I suspect other's as well, that OMV4 would support TimeMachine


    OMV 4 just as OMV 3 already supports TimeMachine (AFP/Netatalk). APFS volumes can be backed up flawlessly to TimeMachine AFP shares still using the anachronistic HFS+ SparseBundles. No need for SMB here whatsoever.

  • I think the need is for OMV to support a more modern SMB service

    No, there is no 'need' for this now since TimeMachine over AFP still works. And OMV relies on the underlying Debian packages (and at Debian everything follows the 'outdated as hell' AKA 'stable' mantra) so unless there is a newer Samba in Debian (backports) OMV won't be able to use newer Samba features.

  • My MacBook Pro from 2015 runs the current Mac OS, for nearly three years I have not been able to get a truly usable TimeMachine backup to/from my OMV (3.x 4.x) server

    Then you need to diagnose your problem. With 'mobile' clients (MacBook Pro) that's usually interrupting a running backup and not reconnecting the Mac back to the TimeMachine server within the so called 'reconnect timeout' (defaults AFAIK to 24 hours).


    My take on this is using snapshot ready filesystems on the OMV server (ZFS or btrfs) and once a backup got corrupted simply reverting back to lastest working version (currently automating this for a customer).

  • Why don't you use the AFP plugin ?

    AFP plugin does not work either. I can trigger an initial backup but once an incremental backup is triggered I get some vague error message that the volumes misses some essential features. Lot of websites claim that MAC OS High Sierra on SSD cannot backup to AFP. That is why I try to backup on SMB.

  • OMV 4 just as OMV 3 already supports TimeMachine (AFP/Netatalk). APFS volumes can be backed up flawlessly to TimeMachine AFP shares still using the anachronistic HFS+ SparseBundles. No need for SMB here whatsoever.

    This is not true for me. I tried several times to run on AFP but the result is always as mentioned in my reply to RPMan. I also tried to create the spares bundle on the MAC and then copy that over to OMV. But this also did not work.

  • AFP plugin does not work either

    This is my MacBook Pro running High Sierra:


    The 2 AFP shares are provided by Netatalk (on OMV 4):


    Works as expected, restore and disaster recovery included.



    I found this whilst the information is mac/windows based the principle should be same


    Bad advise since putting a SparseBundle somewhere is the irrelevant part. You do backup for a reason and that's restore and disaster recovery which won't work with this Windows/SMB approach.


    The important part is having access to your backed up data and being able to restore -- even from scratch. If I throw my MacBook now out of the Window and get a new one, I can boot the new one, connect it to my network and will then be asked whether I want to restore from a backup. If I say yes both OMV servers will be presented and I can restore through the network without hassles since OMV/Netatalk does the magic to announce the TM volumes appropriately. Windows won't do this.

  • So the short answer is to use AFP until omv incorporates samba 4.8

    Well, the required features have been integrated into Samba 4.8 but usually for everything to work flawlessly it needs another (few) version increments. That's why I talked about 4.9 or 4.10 above (no idea when these Samba versions will be part of Debian which is important since OMV relies on upstream Debian packages here. Also no idea whether Debian's Samba maintainers will build Samba with Avahi integration which is a basic requirement for TM)


    And yes, for now there's only one option: TM over AFP by using the Netatalk plugin. This works flawlessly as long as some stuff is considered:


    • Never ever use the same share with more than one protocol at the same time. If you want a dedicated TM share only share it using Netatalk but not Samba or NFS at the same time
    • Keep in mind that interrupted backups (Mac client sent to sleep or disconnected from the network) are usually not a problem as long as the client is reconnected to the server within 24 hours. If this fails then you almost always end up with a corrupted sparsebundle and TM tells you a new backup is needed
  • And yes, for now there's only one option: TM over AFP by using the Netatalk plugin.

    I just find this interesting, I'm not a Mac user, but I did work with a website developer who needed access to the server just to save his work (because the server had a backup) so I set up an SMB share for that purpose, in that context simply copying his 'working files' would be sufficient and work on something like omv.


    The important part is having access to your backed up data and being able to restore -- even from scratch. If I throw my MacBook now out of the Window and get a new one, I can boot the new one, connect it to my network and will then be asked whether I want to restore from a backup. If I say yes both OMV servers will be presented and I can restore through the network without hassles since OMV/Netatalk does the magic to announce the TM volumes appropriately. Windows won't do this.

    If I take the above, which I understand, OMV/Netatalk communicate with the new Mac without user intervention....in simple terms they just say 'hello' to each other. Which Windows cannot do, which in essence makes sense the protocol/handshake is not there, but surely that would just require intervention from the user to mount or whatever is necessary to restore that backup, or am I wrong?

  • in that context simply copying his 'working files' would be sufficient and work on something like omv


    If that user is running macOS the better idea is to switch on TM on both client and OMV server and use TimeMachine since TM as every real backup solution creates versions that are easily accessible later. Simply copying stuff over usually results in no older file versions being preserved which can be a big problem if you realize an accidental change too late:


    Start at 7:40 for the relevant part:


    OMV/Netatalk communicate with the new Mac without user intervention


    Netatalk announces the TM shares via ZeroConf using Avahi on Linux. This works with both AFP and SMB shares just not when Windows is the SMB server.


    And then there's another problem: When making TimeMachine ready for networked backups Apple added at least one new call to the AFP protocol back then and did the same later with SMB (adding proprietary extensions as they did in the past already partially described here: https://redmine.ixsystems.com/issues/5904 -- this is also interesting for those users making the same share available with AFP and NFS or SMB at the same time which can not work reliably without the changes outlined in my link). I haven't checked with Windows 10 yet but usually those Apple proprietary SMB extensions will not be supported by Windows' own SMB implementation.

  • Start at 7:40 for the relevant part:

    That is so easy and straightforward.


    This works with both AFP and SMB shares just not when Windows is the SMB server.

    Sorry perhaps what I asked was not clear, whilst that write up is Windows based, and I understand what you're saying regarding Windows, could that write up be used in the same way but for OMV? Or is there something within that process that would fail.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!