I remember when setting up my Time Machine SMB share that I set a 1TB quota. Now when I randomly checked things out a couple years later, it seems to not be working anymore. Under the SMB advanced options, the quota is set to 0, and changing it just resets it back to 0.
I have a dedicated dataset for the share, so I could set the quota there instead. But I’m not sure if it’s going to work as intended. Why does this SMB setting exist and why isn’t it working?
It appears to be a UI bug. I’ve made a ticket for it. If you want to set it from backend you can run command:
midclt call sharing.smb.query | jq
Then find your share’s id value and run comand:
midclt call sharing.smb.update <id> '{"timemachine_quota": 100000000}'
or whatever you want.
Is a quota respected by Time Machine in the same way as as the size of a directly-attached disk (i.e. to reclaim old snapshots)? Does that apply even when multiple clients back up to the same dataset? I’m guessing yes, because TM is designed to work properly when sparsebundle growth fails on network volumes, but I’d appreciate some confirmation.
Setting a quota would seem to be an essential part of setting up a Time Machine share, since otherwise it presumably will consume all the free space in the pool, leaving one with no alternative but to delete a sparsebundle. Why isn’t that mentioned in the setup instructions for a “Adding a Basic Time Machine SMB Share?”
TIA,
Dave
I use a multi-user Time Machine share. And then I setup a user for each machine. Not the same as the user of each machine.
Each machine will then end up with a dataset to back up to in the multi user Time Machine dataset.
Then you can set a quota for each dataset.
Yes. This is poorly documented.
Modern Time Machine lets me specify a quota from the Mac when I connect the disk. Obviously this isn’t setting a quota on the ZFS dataset, but it seems like a much easier way to manage things, and there’s a slightly greater feeling of security since how/whether Time Machine responds to “disk full” reports from the SMB filesystem is somewhat hidden, while TM is clearly claiming to respect what you set through its own UI.
MacOS maintains quota settings in a plist file within the sparsebundle for the backup. The UI-based quota in truenas for time machine adjusts the dfree value based on the setting with onus on the client to do something sane when it’s running out of space. We can’t rely on plist setting because that’s very much in Apple’s hands and may be liable to change.
I realize the different way these things operate.
But who is the “we” in this case?
Are you saying users should expect Apple to stop honoring the quota settings in the plist file?
I realize it’s possible, but if you’re worried about Apple doing bad things, there’s my concern that Apple will fail to respect disk-full reports from an SMB filesystem (or that caching effects in SMB may cause such problems to be misreported, or reported late). So if you are worried about these things, it probably makes sense to use both methods, and set the plist file quota slightly lower than the ZFS quota.
You’re very much misunderstanding what I write.
SMB server developers. The plist is opaque and we can’t make guesses about how it’s used. That’s the reason why TrueNAS quotas are implemented by adjusting available space for client to write and not by rewriting a plist value. MacOS owns that file and we don’t want to touch it. At some point we have to rely on Apple doing sane things with their client.
Not intentionally, I assure you. I thought this thread was about how to set up quotas for time machine, not about how to implement an SMB server, and I interpreted your post accordingly. Sorry for the misunderstanding and thanks for clarifying.