February 22, 20242 yr 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
February 22, 20242 yr Solution 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.
February 28, 20242 yr 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.
February 29, 20242 yr 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
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.