I have two internal CORE systems that serve as time machine targets for all my colleagues. They have been in use for a couple of years without any incident and it seems that just about now the first users hit their assigned storage space limit.
The system itself is connected to our Active Directory for authentication. As you can see from the auxiliary parameters I used the fruit:time machine max size parameter combined with auto creation to set the space limit.
Each user automatically gets their own dataset. Snapshots after time machine completion etc. work well.
But when the 1 TB limit is reached, time machine on the Mac in question does not delete old backups but instead just complains about a lack of space and refuses to perform another run.
So what can I do about this? Setting ZFS quota won’t be available when the datasets are created automatically, right? That’s why I picked that auxliiary parameter.
Any fix greatly appreciated. An upgrade to CE would be possible provided that multi user time machine with AD authentication works in CE. Does it?
I guess I’ll try to create a cron job that simply sets a ZFS quota for all datasets below <pool>/share/tm - that’s trivial. And a new colleague will not fill their 1 TB on the first day before the cron job runs.
IIRC in core I have some logic to auto-set a ZFS quota, but that would run into same problems as builtin option. If MacOS isn’t properly handling low-space on disk then adding a ZFS quota won’t work.
I hope a hard ZFS limit will be more robust than the Samba option? The former was how I ran TM at home when I still did that. That was only a single dataset so that part was easy. Never had a problem.
For one colleague backups somehow caught up and the error message has not reappeared, since. Macs. Weird.