Time Machine backups fail with error "The selected network backup disk does not support the required capabilities."

[Dave Hamby]

The MacOS volume being backed up is File Vault encrypted. The target dataset is encrypted. MacOS user Davey owns the target dataset and Davey is the MacOS admin. I can't find anything additional in the system console logs. The attached captures the MacOS Finder volume info and the SMB share configuration. The thrid image shows the Disk Utility info on the MacOS system volume being backed up. It appears MacOS thinks the Time Machine volume is full. I can't see an obvious cause.

Davey has a second dataset of music in the pool and can add new music to the music dataset. It's an iTunes format music library. iTunes is happy. So I know user name, user number, etc are not an issue.

I had intended to encrypt the TrueNAS pool Pool1 but missed that when commissioning the new Mini+. That hadn't been an issue before the update.

At this point, I'm out of ideas and need some coaching.
Thanks, Dave.

 

[anodos]

Gosh, the forums are being problematic. You have selected a SMB share preset that:
1) autogenerates per-user datasets with 1 TiB ZFS USER quota
2) automatically manages snapshots of said dataset as time machine creates new backups

You can adjust quota in (1) via webui for the dataset in the storage menu (bump it up to an appropriate value for how much of NAS you want the Mac to take over).

 

[Dave Hamby]

So, every novice does this to himself? I saw the earlier incident and concluded it didn't apply because I had not set quotas. Apparently WebUI did for me. TimeMachine eating shares is an old problem (Drobo). The fix is always to set quotas.

On "Createing Datasets" I found "To quickly create a dataset with the default options, enter a name for the dataset and click SUBMIT."

I couldn't find a list of the defaults. Usually, there is an expandable table or some such. Was it omitted?

I doubled quota for now and Time Machine recovered. It is chugging away.

 

[Dave Hamby]

As I was updating my blog, I realized what had happened. I hadn't created the filesystem for the user davey. I just created the FM_TM container. Time Machine created the davey container. And put the quota on it, and created the APFS sparse volume structure inside. Bless Apple for not troubling our pointy little heads with such administrative trivia. Perhaps a reminder in the SMB section?

 

[Zeff]

Dave,
I have the same issue, but I'm not grasping the solution.
Can you elaborate please?
I have two users with quotas set.
I have hit the quota and Time Machine throws the error.

 

[Dave Hamby]

Sorry Zeff. That old post is ancient history predating the move from FreeNAS to TrueNAS and TrueNAS 13 UI. I've since brought in a second machine that is my primary TrueNAS. The old home brew machine from FreeNAS 9 days is now used as a replication target and network DVR.

The move to TrueNAS and release 13 has made things about as simple as they could be. (No way out of Owner and Group IDs and permissions, sorry).

• First, Each Time Machine user must have a TrueNAS log in that matches user numbers with the user computer and user id to be backed up.
• Second, create a dataset for each Time Machine user machine and user account. They can be inside a dataset associated with the user machine running Time Machine Client.
• 
• Third. set dataset owner to be the User machine client user's user UID
• 
• Fourth, create a Windows Share for each TM file system created above. Set the multi-user Time Machine Option
• 
• Mount the Time Machine User share on the Time Machine client system. Note the mount user UID and storage owner UID match.
• 

 

[colton.padden]

Just wanted to say thank you, Dave.

Your instructions got me up-and-running on my machine!

 

[Dave Hamby]

Glad it was so easily sorted. I've been driving Unix since 1990 or so so know where most of the pitfalls are. That one is a classic with shares. I miss "Sun Yellow Pages!", simple light weight for small workgroups.

 

[anodos]

Glad it was so easily sorted. I've been driving Unix since 1990 or so so know where most of the pitfalls are. That one is a classic with shares. I miss "Sun Yellow Pages!", simple light weight for small workgroups.

YP was renamed to NIS (fairly obvious legal reasons). We have support for it in TrueNAS 13 (assuming you have a NIS server), but it's only really useful if you're NFS-only. In SCALE we've deprecated support for it.

 

[Dave Hamby]

Sadly, no NIS server. And I can't bring myself to say "NIS" :) The problem is that there is no lightweight directory server like NIS for home use. Manually managing user numbers across a Mac and a couple of TrueNAS boxes is a pain.

 

[Zeff]

Hi Dave, sorry to be so late in reply—meant to get back to you but got distracted and forgot.
Thank you so much. This worked for me, except for this:
"…TrueNAS log in that matches user numbers with the user computer and user id to be backed up."
If I'm understanding this, the user id on the Mac must match the user id on TrueNAS?
I got this working with two Macs and two users, each of whom had the default Mac user id of 501 and on TrueNAS user one has id 1000 and user two has 1001.
I have a question about user quotas. I have set user quotas for each user and have set the size of each sub-dataset the same.
However, when I run Time Machine it claims the available space is the entire pool free space.
Will Time Machine start deleting old backups when it reaches the limit of the sub-dataset or will it fail when it reaches the limit as it believes there is more free space?

 

[Dismal Wizard]

MacOS, Linux, and FreeBSD all follow POSIX file system permission conventions. Time Machine may be a special case, as Apple made it, in that it will create the remote backups with the appropriate UID and GID for the user on whose behalf it is running. If you look at a multi-user Time Machine tree, you'll see a root directory for each user that Time Machine is serving and they'll all be in the share you created for Time Machine.

I have a different issue in that I'm keeping regular user files in the TrueNAS share. I have shares over there for Music and Photos that I write from MacOS XLD (music ripper) and Apple Photos.App and a third that is Mylio on behalf of my regular user ID (first user unprivleged). It is in these three branches of the TrueNAS pool that I have to mind owners so these user-land applications can traverse, change directories, and write new files.

I've not yet figured out TrueNAS free space reporting but here are some things to keep in mind.

• When you create a zvol, it has a size limit that you set at creation. You have the option of sparse provisioning (default) or guaranteed provisioning (optional). Sparse provisioning allows the zvol to grow to the limit if space is available. Guaranteed provisioning will claim the space at creation.
• A filesystem will grow to the space available
• TrueNAS uses the term dataset to refer to any pool-resident storage container so you have to mind your volumes and filesystems.

I have plenty of storage for Time Machine so I have created regular filesystems for the time machine spool. Time Machine growth is not a concern with several TB available.

File owner and group are only part of the story. When Linux gained traction, access control lists (ACL) were added following practices that evolved in US DOD. A file system object could be assigned access identifiers. For a process to access an object, it had to hold that identifier and permissions had to match. This is all independent of the UNIX permissions system. And it is part of POSIX now and is ISO standardized. FreeBSD, Linux, MacOS, and Windows all support POSIX ACLS.

• TrueNAS and ZFS have access control lists in addition to UNIX permissions. ACLS let you get fancy granting rights should you work for the NSA. Generally, keep it simple and don't use ACLS. If you do, keep records.
• UID and GID (numeric) identify accounts and groups in the regular file system permissions scheme. In the absence of a global user management service, the local definitions hold sway and can differ from host to host.
• Apple has aligned account and group numbering with the POSIX standard. Back in 2002, it was not so aligned so they started with 500, source of my troubles.

 

[Zeff]

Thanks Dave—much appreciated.