Time Machine not working - Mac does not find any Backup-Volume

[Christian H]

as written in the title: My Mac does not find any backup volume. I'm on the latest version of Unraid. Any ideas?

 

Unraid-version: 6.12.8 (same with 6.12.6)

MacBook Pro M2: Ventura 13.6

 

SMB-Settings:

• Enable SMP: Yes (Workgroup)
• Hide "dot" files: no
• Enable SMB Multi Channel: no
• Enhanced macOS interoperability: yes
• Enable NetBIOS: no
• Enable WSD: yes
• WSD options (experimental): empty

 

SMB-Extras:

• veto files = /._*/.DS_Store/

 

SMB Security Settings:

• Share name: tm
• Export: Yes/Time Machine
• Time Machine volume size limit: 2000000 MB
• Case-sensitive names: Auto
• Security: Private

 

SMB User Access

• christian Read/Write    <-- this is the same user which I use on my Mac

 

Share Settings:

• Share name: tm
• Comments: Time Machine
• Minimum free space: 97.6 GB
• Share Status: Share is empty
• Exclusive access: No
• Primary storage (for new files and folders): Cache    <-- Single SSD pool device
• Secondary storage: Array
• Allocation method: High-Water
• Split level: Automatically split any directory as required
• Included disk(s): Disk 1
• Excluded disk(s): None
• Mover action: Cache --> Array

 

 

[Squid]

From Finder, you have to first navigate to the TM share in order for TM to see it.  IE: The Mac has to have it mounted first.   After adding it in, TM will automatically mount it.

 

NOTE:  I don't recommend having TM shares moving to/from the array or cache.  IF something happens in the middle of the move and everything doesn't get moved for one reason or another, the backups get trashed.   Leave it on the cache pool or write directly to the array.  Also, TM shares moving from cache to array (and vice versa) has not been fully tested under all circumstances to begin with.

[Squid]

Oh, and FWIW veto files slows everything down.

[Christian H]

Thank's a lot - you made my day! 😀😀

[jademonkee]

On 2/22/2024 at 6:33 PM, Squid said:

Oh, and FWIW veto files slows everything down.

Does it? Can you elaborate? I have set my Mac/SMB settings up as per the following post:

Which includes vetoing the Mac dot files.

I note on the 6.12.6 changelog it mentions fruit changes to help TimeMachine restore.

 

Currently my SMB Extra is as follows:

veto files = /._*/.DS_Store/
aio read size = 1
aio write size = 1
strict locking = No
use sendfile = No
server multi channel support = Yes
readdir_attr:aapl_rsize = no
readdir_attr:aapl_finder_info = no
readdir_attr:aapl_max_access = no
fruit:posix_rename = yes
fruit:metadata = stream

Is there something you recommend I change? Either deleting it entirely (perhaps it's setup by default now?) or anything in particular?

Are the recommended settings for Mac OS available somewhere so that I can set them up?

Sorry to hijack the thread (I just wanted to respond to the news that veto slows things down), and thanks for your help.

[Squid]

Veto'ing files slows all access down as samba has to then compare every single file against the veto list

Quote

Setting this parameter will affect the performance of Samba, as it will be forced to check all files and directories for a match as they are scanned.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#VETOFILES:~:text=valid %3D yes-,veto,-files (S)

 

fruit:metadata being set to stream is technically faster in conjunction with everything else listed there, but pre-existing metadata may get lost by changing it from the default of netdata.  My testing on a directory with ~1000 folders has stream being ~1 second faster to open and populate.  Default of netdata was ~2-3 seconds.

 

6.12.8 has for the settings with Mac Interoperability enabled what LT recommends.  Not to say that there may not be better / faster, but the possibility of losing metadata - especially if you ever used AFP on the server dictates a more conservative setting for the OS defaults