It doesn't matter assuming that fix is:
- known
- trivial
- fixes bug in the officially offered samba package for armel
I agree that size_t should "store the maximum size of a theoretically possible object of any type (including array)". But at the same time the code mixes off_t and size_t both used for representing file sizes (say, band sizes) when other modules use uint64_t. So if I was a maintainer, I would fix it asap. But I am not a maintainer, so I've fixed it for myself.
After investigation I realised that this bug is already known and reported. The reporter's solution is not complete, so I added a comment to it. I rebuilt vfs_fruit and confirmed that it works properly. Now I am rebuilding the whole samba-4.9.5 package for clean upgrades.
The bug report is here: https://bugzilla.samba.org/show_bug.cgi?id=13622
It seems no one is fixing it since 2018. Maybe you may push Ralph to put fixes upstream.
Apart from samba package upgrade via apt it seems no more changes is required to use it (including TimeMachine over SMB) with OMV4 which, as I said, is the only version running well on low powered NAS boxes.
It seems that I found the problem - it is a bug in samba source code if built for armel architecture (it may work on x86/64).
In vfs_fruit some data types are used: off_t and size_t. The first is normally used for file sizes and is 8 bytes long (as configured for samba build), the second is used to count objects and is 4 bytes long (according to my build logs). But in the vfs_fruit code they for some reason compare free space with SIZE_MAX constant which is for size_t and is 4GB max. So the overflow is detected and error returned.
There are two options to fix that: either set size_t to 8 bytes globally (I do not know where else they may mix file size type with object count type), or fix this only issue locally for vfs_fruit. I will try to do the second for now and see if it solves the problem.
TL;DR: does 'fruit:time machine max size = 200G' work with OMV5/Samba 4.9.5?
Full story:
I am trying to revive old DNS-325 NAS box (armel single core 1.2GHz CPU, 256MB RAM) replacing original D-Link firmware with OMV. Version 4 is just fine, but Time Machine backups over AFP are slow. Version 5 of OMV is no-go for this hardware since it uses always running configuration agent which takes near 30MB RAM and it is so slow that any change takes minutes to be applied.
In order to use TimeMachine backups I rebuilt Samba 4.9.5 packages from buster on stretch (including all dependencies of course, 84 packages total were built to build samba, but only 10 or so are required for upgrade on top of official stretch versions). After adding a repo I did 'apt install samba' and the system was upgraded without any issues. So now I have OMV4 with Samba 4.9.5 with TM support.
Next I tried to patch OMV4 to add TM support and TM quota options to UI, but later I decided to stay on the original OMV4 and use Extra configs for SMB service and SMB shares (also optionally disabling Avahi for SMB using internal Samba mDNS option). Everything is fine except TM quotas.
When I have no Time Machine quotas set, it works great, much better for me than AFP version. But when I add the line 'fruit:time machine max size = 200G' in the share configuration, this share becomes inaccessible via SMB neither for TM nor for plain files - Mac just can't open the folder. This is the only option which breaks the access. I tried it in combinations from OMV5 fruit configs to many others, no luck.
The questions are:
- why OMV5 does not support this option (at least, when I looked at it, it did not) - is there a reason for?
- anybody tried it at all?
- any hints how to limit TM disk space not using a whole filesystem user quotas?
Ideally I wish to limit the quota per user, but even quota per share would be good enough (I can have one TM share per user).
I also tried to put misc com.apple.TimeMachine.quota.plist (with leading dot and without it) to different places, and it doesn't seem to work at all (ignored by TM clients).
Any help is highly appreciated.
