I have a macOS client (12.6.7) with APFS filesystem that supports large extended attributes (one attribute value being over 68 MB in a test).
I have a NAS server with Ubuntu Server 22.04.2 LTS with ZFS file system and Samba Version 4.15.13-Ubuntu.
ZFS has xattr=sa set. So extended attributes are enabled on the NAS.
I configured Samba to run with vfs fruit like so:
ea support = yes
vfs objects = catia fruit streams_xattr
fruit:resource = stream
fruit:metadata = stream
With this configuration I was able to write smaller extended attributes and resource forks (less than 64 KB) onto the NAS share.
But with larger extended attributes and resource forks (over 64 KB) it did not work.
After a lot of threads, man pages and code I stumbled upon this little note in the zfs man page:
xattr = on | off | sa
The default value of on enables directory based extended attributes. This style of extended attribute imposes no practical limit on either the size or number of attributes which can be set on a file. Although under Linux the getxattr(2) and setxattr(2) system calls limit the maximum size to 64K.
So cool that we have a ZFS on Linux with "no practical limit", just the Linux Kernel (being a practical thing) limits the size of extended attributes in practice.
Ok so I can't fix it either on the ZFS side nor on the Linux side.
Next step was Samba specifically.
Because of the size limitation of extended attributes, I needed an alternative storage for them. For resource forks there is a setting to write them to files:
fruit:resource = file
Having this enabled I can write large resource forks to the share.
But fruit has no option to write other metadata (like extended attributes) to a companion file:
fruit:metadata = [ stream | netatalk ]
- netatalk (default) - use Netatalk compatible xattr
- stream - pass the stream on to the next module in the VFS stack
stream is not working, because streams_xattr tries to write it into an extended attribute.
netatalk is not working, because fruit tries to write it into a netatalk compatible named extended attribute.
Why there is no option to write metadata to files too?
This would make Samba more independent of the underlying filesystem provided (even if it has no extended attributes at all).
My current solution is to use:
ea support = no
This forces macOS clients to create AppleDouble files for their resource forks and extended attributes.
With this the resource fork and extended attributes from the client are kept.
Of course this is incompatible with windows clients, which is ok for me at the moment, but this is a significant limitation of how I can use this box.
Also because vfs fruit needs ea support = yes, I can't use it. From what I read about fruit this means slowing down the NAS performance and I also don't get easy Time Machine setup. I don't even know about the other consequences. fruit seems to implement the FULLSYNC capability (see fruit:time machine). From the legacy Apple documents it reads like it's needed for a clean Time Machine backup on power failure.
I also thought about writing the streams into a database, but that makes fixing things a lot harder if something goes wrong with this vfs object (for more information see). Mind the "Do not use this module in production".
Switching to an OS with no extended attributes limitation to get Samba working is not an option … for now at least.
Is there another option to fully support macOS resource forks and extended attributes on Linux systems without disabling extended attributes on the samba share (and therefore vfs fruit)?
