Time machine backup on SMB share

    • OMV 4.x
    • 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 ?
      I'm a Docker Technical Sales Professional.

      1 NAS OMV 4 (Intel Pentium G4560 3.5 GHz, Asrock H110M-ITX, 24 Gb DDR4, 2*4 To Seagate Ironwolf Nas, 4*4 To WD red) -> Power consumption: 4 euros/month.
      1 Backup Server omv 4 (Intel G3930, 8 Gb DDR4, 6*4To WD blue)
      1 RPI 3 seedbox with omv 3.X
    • RPMan wrote:

      Why don't you use the AFP plugin ?

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

      From: 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: appleinsider.com/articles/13/0…mb2-in-os-x-109-mavericks
      OMV 4.x on intel
    • merula wrote:

      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.

      reddit.com/r/apple/comments/53…_machine_via_smb_but_how/

      developer.apple.com/library/ar…chine_SMB_Spec/index.html

      bugzilla.samba.org/show_bug.cgi?id=12380
      OMV 4.x on intel
    • tkaiser wrote:

      ajaja wrote:

      "Any Time Machine share points must be shared over SMB instead of AFP."
      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.
      OMV 4.x on intel
    • ajaja wrote:

      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.
    • ajaja wrote:

      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).
    • RPMan wrote:

      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.
    • tkaiser wrote:

      ajaja wrote:

      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.
      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.
    • merula wrote:

      AFP plugin does not work either
      This is my MacBook Pro running High Sierra:

      Source Code

      1. mac-tk-2018:~ tk$ sudo sw_vers
      2. ProductName: Mac OS X
      3. ProductVersion: 10.13.6
      4. BuildVersion: 17G65
      5. mac-tk-2018:~ tk$ sudo tmutil destinationinfo
      6. ====================================================
      7. Name : Backup
      8. Kind : Local
      9. ID : C7296CBB-B99F-4883-9AD2-FF249729AD1C
      10. ====================================================
      11. Name : mac-tk-2018
      12. Kind : Network
      13. URL : afp://tk@TimeMachine._afpovertcp._tcp.local./mac-tk-2018
      14. ID : 9E391AEF-69F8-43F1-BBFC-1BFD5F97D5DC
      15. > ==================================================
      16. Name : AO_BACKUP
      17. Kind : Network
      18. URL : afp://tk@backupsrv._afpovertcp._tcp.local./AO_BACKUP
      19. ID : 968CB120-CC02-4265-9F5A-2EC7CF5867F6
      Display All


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

      Source Code

      1. root@espressobin:~# afpd -V
      2. afpd 3.1.9 - Apple Filing Protocol (AFP) daemon of Netatalk
      3. This program is free software; you can redistribute it and/or modify it under
      4. the terms of the GNU General Public License as published by the Free Software
      5. Foundation; either version 2 of the License, or (at your option) any later
      6. version. Please see the file COPYING for further information and details.
      7. afpd has been compiled with support for these features:
      8. AFP versions: 2.2 3.0 3.1 3.2 3.3 3.4
      9. CNID backends: dbd last tdb
      10. Zeroconf support: Avahi
      11. TCP wrappers support: Yes
      12. Quota support: Yes
      13. Admin group support: Yes
      14. Valid shell checks: Yes
      15. cracklib support: Yes
      16. EA support: ad | sys
      17. ACL support: Yes
      18. LDAP support: Yes
      19. D-Bus support: No
      20. Spotlight support: No
      21. DTrace probes: No
      22. afp.conf: /etc/netatalk/afp.conf
      23. extmap.conf: /etc/netatalk/extmap.conf
      24. state directory: /var/lib/netatalk/
      25. afp_signature.conf: /var/lib/netatalk/afp_signature.conf
      26. afp_voluuid.conf: /var/lib/netatalk/afp_voluuid.conf
      27. UAM search path: /usr/lib/netatalk//
      28. Server messages path: /var/lib/netatalk/msg/
      Display All

      Works as expected, restore and disaster recovery included.


      geaves wrote:

      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.
    • geaves wrote:

      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
    • tkaiser wrote:

      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.

      tkaiser wrote:

      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?
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      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:


      geaves wrote:

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

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      Start at 7:40 for the relevant part:
      That is so easy and straightforward.

      tkaiser wrote:

      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.
      Raid is not a backup! Would you go skydiving without a parachute?