samba - Oct 2025 - Inquiry: Samba and xattr with vfs_fruit on FreeBSD / ZFS (macOS Finder metadata problem)

Hi and Thanx for taking your time!

On 10/13/25 16:57, Perttu Aaltonen via samba wrote:
> Do you know if fruit:resource = xattr and large xattr support is actually
implemented on FreeBSD? The fruit man page only talks about Solaris derivatives.
I am not 100% sure, but with dnodesize=auto it should also handle large 
xattr. But I have to find yet a more authoritative page.
> With veto_appledouble = yes (the default), I don?t think you should see the
._ files from the client side with fruit:resource = file.
> 
> I wonder if this is related to the issues I?ve seen with folder icons on a
Linux Samba server:
> https://bugzilla.samba.org/show_bug.cgi?id=15013
> 
> As a test could you test with:
> fruit:resource = file
> fruit:encoding = native / private
> fruit:veto_appledouble = no
With this setting (+: fruit:metadata = netatalk), Finder spits out an 
error dialogue (Error -8058)
xattr is created (but not read back)
annoying sidecar file is created (368 bytes long)

With

fruit:metadata = netatalk
fruit:resource = file
fruit:encoding = native
fruit:veto_appledouble = yes

Nothing is created, but Finder brings up a "sudo window" requiring 
biometrics or admin password (which makes no sense, since it is not local)
> Just to see if it works then. This works for me with Samba 4.22 but on 4.20
I couldn?t get it to work at all IIRC.
I will try again with 4.22 as soon as the port is out. I've seen it has 
many FreeBSD patches in files/ and fear the rabbit hole waiting for me 
there.
>Also try if copying a file with tags or labels works instead of applying
them directly on the server. Would be interesting to know if this is the same
issue I?ve seen. I haven?t tested with tags and labels, only with icons.
On 10/13/25 15:26, Andrea Venturoli wrote:
> 
> Same here, but "zfs version" gives 2.2.7! Why does yours differ
(on 14.3)?
Sorry, I realized I copied the zfs version from a FreeBSD 14.2 host. 
14.3 has 2.2.7. Sorry for the confusion.
>> and with the use of LDAP/ACLs (passdb backend = ldapsam:...)
> 
> I'm using "security=ADS", but this should not matter.
> I'm not using ACLs, though: I think this still shouldn't matter,
but I'm
> not sure.
I cannot switch over to ADS just yet in that environment.
Too many other services are binding to OpenLDAP at this stage. I also 
don't think that this should be an issue - although, in samba / smb / ad 
land, many things are tied together, so it could be an issue.
>> Is there any working config with FreeBSD/ZFS and Samba that honors Mac 
>> clients without making it a horrible experience for Windows / Linux 
>> clients (AppleDouble files)?
> 
> I use:
> vfs objects=fruit streams_xattr shadow_copy2 full_audit
> fruit:wipe_intentionally_left_blank_rfork = yes
> fruit:delete_empty_adfiles = yes
> fruit:nfs_aces=no
> fruit:metadata = stream
> fruit:encoding = native
> fruit:resource = xattr
> fruit:nfs_aces = no
This combination works at least without leaving sidecar files around 
(which is one of my main goals), and /for the most time/, Finder is not 
displaying any error when setting labels. In most cases, the xattr 
'DosStream.com.apple.metadata:_kMDItemUserTags:$DATA' is set (and 
seemingly with the right label, when reading it from the terminal), but 
it is not read back from the Finder (or sent back by smbd).

This is a viable compromise, at least one worth testing out (thanx Andrea).

But still, it would be nice if the 
DosStream.com.apple.metadata:_kMDItemUserTags:$DATA were read back. From 
what I can see on log.smbd and testing enumeration with smbclient 
allinfo, the xattr is never listed as an ADS.

I was about to try patching it (finding where the enumeration gets 
lost), but I see that the FreeBSD port already has around 30 patches in 
place. I'm giving up on Finder tags/labels for now. Art least, it 
doesn't clutter the filesystem with sidecar files for now. If any dev 
(particularly on samba at freebsd.org) does have a clue or can use help 
testing a patch, I'll be more than glad to set it up.

Best Regards,

Lorenzo



Thanx to any one

On 10/15/25 14:26, Lorenzo Perone via samba wrote:
> This is a viable compromise, at least one worth testing out (thanx Andrea).
Glad it helped.


> I was about to try patching it (finding where the enumeration gets 
> lost), but I see that the FreeBSD port already has around 30 patches in 
> place.
In fact I thing this is one of the biggest problem we have with our 
ports; I once tried to look into this (I wrote or edited some of those 
patches), but understanding what each one does, why it's there and how 
it interacts with the others is very hard.

  bye
	av.