SOLVED CIFS/SAMBA/SMB with vfs_fruit not supporting Mac OS X resource forks beyond 128KiB

[anodos]

I understand this as: Unless you are sharing the same data with AFP.

Correct. These options are for sharing the same dataset with AFP. vfs_fruit intercepts xattr reads and writes for afp_resource and afp_info xattrs and can handle them in special ways that are compatible with how netatalk does things. The remaining stream reads / writes are passed to the next vfs_module (streams_xattr).

 

[tobiasbp]

It might be worth trying the following options if you're going to use vfs_fruit:

Code:

fruit:resource = stream
fruit:metadata = stream

Looking at the Fruit manpage in the section fruit:resource, I notice the following:

stream (experimental) - pass the stream on to the next module in the VFS stack. Warning: this option should not be used with the streams_xattr module due to the extended attributes size limitations of most filesytems.

Since fruit depends on streams_xattr, your suggestion seems odd. Why do you think this warning can be ignored? Is ZFS not one of most filesystems with the problematic size limit of extended attributes?

 

[anodos]

Looking at the Fruit manpage in the section fruit:resource, I notice the following:

stream (experimental) - pass the stream on to the next module in the VFS stack. Warning: this option should not be used with the streams_xattr module due to the extended attributes size limitations of most filesytems.

Since fruit depends on streams_xattr, your suggestion seems odd. Why do you think this warning can be ignored?

There is no size limit for xattrs in FreeBSD. I've written multi-gigabyte xattrs in testing. The problem was a buffer size imposed in source3/smbd/trans2.c. The warning is about passing afp_resource streams to the next module in the stack. This is because Samba had a hard-coded limit of 64KB and afp_resource streams tend to be above 64KB. I haven't seen any downside yet in my somewhat limited testing.

Do note that the default in FreeNAS is to enable streams_xattr with no fruit. From a functional standpoint (as far as I know), there is no real difference between fruit with

Code:

fruit:resource = stream
fruit:metadata = stream

and streams_xattr with no fruit.

Is ZFS not one of most filesystems with the problematic size limit of extended attributes?

No. The problem was with Samba and not with ZFS.

 

[lumaforge]

I hate to necro this thread but this is the most comprehensive conversation on this I've seen so far. The failure of MacOS to unzip files into a VFS_FRUIT environment with vetoing on is till a massive headache.

There's one thing I'm missing here in using the 'stream' option and that is, it states it passes it on to the next module. Does that mean there needs to be a specific (kind of) module coming after vfs_fruit in this scenario? Or can I just continue to pass it on to aio_pthread and then back to the filesystem as normal, just without streams_xattr?

Thanks!

 

[anodos]

I hate to necro this thread but this is the most comprehensive conversation on this I've seen so far. The failure of MacOS to unzip files into a VFS_FRUIT environment with vetoing on is till a massive headache.

There's one thing I'm missing here in using the 'stream' option and that is, it states it passes it on to the next module. Does that mean there needs to be a specific (kind of) module coming after vfs_fruit in this scenario? Or can I just continue to pass it on to aio_pthread and then back to the filesystem as normal, just without streams_xattr?

Thanks!

vfs_fruit by default handles writes for AFP_AfpInfo and AFP_Resource differently than other alternate datastream writes (puts them in an appledouble file). When you switch to "stream", it passes the writes for those streams to streams_xattr as well.