SMB file names

Questions about using NAS on Mac OS.
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

To anyone it may concern: "fruit:encoding = native" breaks xattr support.
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

m_emelchenkov wrote: Mon Jun 21, 2021 1:39 am To anyone it may concern: "fruit:encoding = native" breaks xattr support.
Can you clarify what is broken and give an example to illustrate?

I'm pretty sure "fruit:encoding = native" causes no issue with Mac extended attributes in standard Samba. However, there may be an incompatibility with QNAP Samba. QNAP uses a proprietary vfs module called 'qnap_macea' (see 'vfs objects' configuration in smb.conf) which I'm guessing may stand for 'QNAP Mac Extended Attributes' but I could be completely wrong and I have no clue what it actually does.
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

QNAP uses two modules: qnap_macea and streams_depot. I think the same as you, that qnap_macea means "extended attributes", however I did not find any info about this module. streams_depot stores attributes in .streams folder in root of share. It is file-based and has tree structure. I think, they don't use streams_xattr because Ext4 can't store large attributes, at least with the kernel version they use. I read somewhere that modern kernels do not have limits on Ext4 xattr size, but I can't say that it is 100% true, I did not check it deeply.

So, what happens: extended attributes writes to .streams folder. But, can't read back. If you do "ls -al@" on Mac, you won't see it. Well, you can see some of them, i.e. you uploaded a file with multiple xattrs, and you'll see only one xattr of this file. File names are regular, no special characters. Intuition tells me "fruit:encoding = native" breaks encoding somewhere in "qnap_macea" module (or in "streams_depot", because it is declared as experimental, but I rate it as a low probability). Given the low quality of QNAP technical support, I will not even report this bug. I renamed all ":" characters from shell and that's all. I do not have contacts of developers, and going through official support channel will fail 100%. Yes, I lost ability to use AFP now, but it will be impossible to fix it anyway, so I do not see another solution (except configuring own AFP/SMB environment in containers).
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

I was wrong assuming qnap_macea is a closed source module. QNAP releases some of their source code under GPL, while I found only this link with its sources: https://github.com/neuschaefer/qnap-gpl ... ap_macea.c
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

Thanks for the clarification.

Yes ext4 filesystem has a 4 KB total size limit on xattrs. It's a limit of the filesystem, not the kernel. Filesystems such as XFS, JFS, Btrfs and ZFS have higher or no limits. The Linux kernel limits are 255 bytes for xattr name and 64 KB for xattr value.

You wouldn't be able to get any technical support from QNAP anyway, even if there is a bug in qnap_macea, because you're manually changing the Samba configuration and that's unsupported.

But whether xattrs were working with "fruit:encoding = native" or not, I wonder how xattrs work between AFP and SMB with QNAP's configuration? Standard Netatalk doesn't know how to deal with metadata stored in .streams directory.

You could try to modify smb.conf and remove qnap_macea in the vfs objects configuration, see what that does... could be better, could be worse...

Personally I shut off QNAP's Samba server and run a separate Samba server (the standard version) on the NAS so I can configure it exactly the way I want and don't have to rely on QNAP support. I don't like having metadata stored separately from the file, so I configure Samba to store everything in Linux xattrs, except resource forks which are stored in ._ AppleDouble files alongside their parent data file, but resource forks are rare or nonexistent nowadays, so it's only used for a very few old files. I don't use AFP or Netatalk anymore, but in theory it's possible to configure Samba and Netatalk so they store and read metadata in xattrs in a compatible manner between each other.

The 4 KB limit on xattrs is an issue if you use ACLs on the Linux side, and configure Samba to use Windows ACLs, both of which are stored in xattrs so can end up taking quite a bit of space.
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

m_emelchenkov wrote: Mon Jun 21, 2021 8:24 pm I was wrong assuming qnap_macea is a closed source module. QNAP releases some of their source code under GPL, while I found only this link with its sources: https://github.com/neuschaefer/qnap-gpl ... ap_macea.c
This appears to intercept extended attributes which name contains 'kMDItemUserTags' (Finder Tags), and only those. I can't quite tell what it's actually doing with them, but it looks like they might be handled as native Linux xattrs rather than being forwarded to the next VFS module (streams_depot), in a way compatible with AFP/Netatalk.
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

Yes ext4 filesystem has a 4 KB total size limit on xattrs. It's a limit of the filesystem, not the kernel. Filesystems such as XFS, JFS, Btrfs and ZFS have higher or no limits. The Linux kernel limits are 255 bytes for xattr name and 64 KB for xattr value.
As Ext4 is built into Linux Kernel, it progress over time, i.e:
"EXT4 in Linux 4.13 also has xattr-in-inode support, parallell discards, xattr deduplication, and support for extended attribute values up to 64k." (https://phoronix.com/scan.php?page=news ... Linux-4.13)
Does it means that xattr size will be limited to inode size chosen at file system format time? inode size limits only one xattr, or all xattrs of a file? Anyway, not for QNAP, its kernel version is 4.2.8.
You wouldn't be able to get any technical support from QNAP anyway, even if there is a bug in qnap_macea, because you're manually changing the Samba configuration and that's unsupported.
That's true.
But whether xattrs were working with "fruit:encoding = native" or not, I wonder how xattrs work between AFP and SMB with QNAP's configuration? Standard Netatalk doesn't know how to deal with metadata stored in .streams directory.
I wish to have more time to play with all this stuff, I wanted to get off with a little blood (=alter smb.conf only), but it seems it is not possible :)).
I checked with AFP, xattrs are not synced between SAMBA and AFP. Except "com.apple.metadata:_kMDItemUserTags". That's the only xattr they sync. OK, not only: also com.apple.ResourceFork.
That means, QNAP do not have proper xattr implementation at all, if SAMBA and AFP are not synchronised. And why am I not surprised :(.
I can understand xattrs are not the most used technology, especially on shares, but why not to just sync everything. For now it looks simply broken.
You could try to modify smb.conf and remove qnap_macea in the vfs objects configuration, see what that does... could be better, could be worse...
I was afraid to do it, because important data is stored there. Now I have sources of this module, we can see it makes interoperability of `kMDItemUserTags` xattr between Netatalk and SAMBA.
The 4 KB limit on xattrs is an issue if you use ACLs on the Linux side, and configure Samba to use Windows ACLs, both of which are stored in xattrs so can end up taking quite a bit of space.
I was never interested in this topic until yesterday. It's really interesting to know real-world examples of large xattrs.

As for qnap_macea, I read the sources too, I can see it deletes APPLE_USERTAG xattr, and "augment" files with USERTAG_EA_NETATALK xattr, even those which don't have it. The code is too cryptic for me, but your below assumption, I think, is right.
but it looks like they might be handled as native Linux xattrs
I cannot find this behaviour by its code, but it seems so. Because no `kMDItemUserTags` xattr in `.streams` folder, and also there is this xattr visible in Ext4 stream by calling `getfattr` command.

According to https://www.samba.org/samba/docs/curren ... uit.8.html:
"The OS X metadata and resource fork stream can be stored in a way compatible with Netatalk 3 by setting fruit:resource = file and fruit:metadata = netatalk."
So it's another vector what to try.
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

m_emelchenkov wrote: Mon Jun 21, 2021 11:50 pm Does it means that xattr size will be limited to inode size chosen at file system format time? inode size limits only one xattr, or all xattrs of a file?
Speaking of ext4 specifically, there are 100 bytes or so unused in the inode, which are used to store xattrs of the file if they fit in this available space. Otherwise a block is allocated to store the xattrs. Only one block can be allocated, not more. The size of this block must be less or equal to the memory page size used by the kernel. The standard page size on x86 architecture is 4 KB. Larger block and page sizes can be used if they are supported and enabled in the CPU and kernel and when formatting the ext4 filesystem, but this is a corner case for specialized environments with lots of memory. I'm not aware of a Linux distribution using larger than 4 KB pages by default.
According to https://www.samba.org/samba/docs/curren ... uit.8.html:
"The OS X metadata and resource fork stream can be stored in a way compatible with Netatalk 3 by setting fruit:resource = file and fruit:metadata = netatalk."
So it's another vector what to try.
Yes, this is the default configuration for vfs fruit designed to be compatible with Netatalk. But this assumes the streams are stored as filesystem xattrs using streams_xattr rather streams_depot.

From https://www.samba.org/samba/docs/curren ... uit.8.html
The module should be stacked with vfs_catia if enabling character conversion and must be stacked with vfs_streams_xattr, see the example section for the correct config.

The module enables alternate data streams (ADS) support for a share, intercepts the OS X special streams "AFP_AfpInfo" and "AFP_Resource" and handles them in a special way. All other named streams are deferred to vfs_streams_xattr which must be loaded together with vfs_fruit.
I understand it's dangerous for you to experiment with various configurations if you're dealing with important data. But instead of modifying the global configuration you can experiment with a specific share that you would create and use only for testing sample files separate from your important data, where you can override the global configuration. See the example provided at the end of the man page linked above:

Code: Select all

[My Test Share]
path = /path/to/test/folder
[...]
vfs objects = catia fruit streams_xattr
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = netatalk
fruit:encoding = native
(You would need to add the same share to AFP/Netatalk server of course.)
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

I created a local Ubuntu VM for testing. I testify that `fruit:encoding = native` is not compatible with `streams_depot`. It writes attributes but can't read it back. Commenting `fruit:encoding = native` reads all the attributes stored with this option enabled. It's a bug in SAMBA's `streams_depot` module. It's not exactly a QNAP issue, and `qnap_macea` does not involved in this bug.

As for other things—I experimenting now, I found different interesting and useful options to make SAMBA <--> Netatalk interoperability. But this interoperability works only with `streams_xattr`.

I think, QNAP chose `streams_depot` because it allows to store large chunks of data, incl. those from NTFS alternative data streams.
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

I use macOS High Sierra and there is a Finder bug: if you copy to SAMBA share a file with large xattr (i.e. 60 kilobytes), Finder truncates xattr to 4096 bytes. But if you copy the file via `cp` command from Terminal, it copies whole xattr without problem.
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

m_emelchenkov wrote: Tue Jun 22, 2021 4:23 am I think, QNAP chose `streams_depot` because it allows to store large chunks of data, incl. those from NTFS alternative data streams.
Yes I think so too. NTFS alternative data streams are rare, but as I mentioned previously, Linux ACLs (what QNAP calls 'Advanced Folder Permissions') and Windows ACLs, if enabled in QNAP Control Panel, are stored in filesystem xattrs so they compete for space with other xattrs.

I use streams_xattr in a mixed Windows & Mac environment, without Linux ACLs or Windows ACLs, so xattrs on Linux side are pretty much only used for Mac metadata. I have not (yet) encountered an issue because of the 4 KB limitation on ext4. But I understand that some Mac applications can store many or large extended attributes which total size could be larger than 4 KB. I don't even know what happens on the Samba side if that's the case - I ought to try that some time.

I don't like the idea of storing metadata in a separate directory like streams_depot does with the .streams folder. It makes the storage brittle. For example if you back up the shared folder on the server side but forget to include the .streams directory because it's hidden, you end up with a backup without metadata. Or if you perform file management operations on the server side (i.e. via SSH command line), like moving files around or renaming files, the files lose their metadata because the standard command line tools don't handle the .streams stuff.

It seems there is no good solution other than using a better filesystem than ext4, one which has much higher xattrs limits.
m_emelchenkov
Starting out
Posts: 32
Joined: Fri Aug 21, 2020 2:33 pm

Re: SMB file names

Post by m_emelchenkov »

I agree that streams_xattr is best of all to use with non-ext4 FS. Probably, ZFS, if talking about NAS. However, it's upper line of NASes, not small/home office machines. QNAP competitor uses brtfs, it seems it can support large xattrs too.
Storing metadata in separate folder is brittle, yes. It's just a workaround for FS limitations.

However, for my case (I don't use ACL), I don't see any real xattr usage except some macOS metadata like "quarantine" and "downloaded from". It should be really specific software which rely on xattr usage, I don't know such software (and can't find it by prompt googling).
I have not (yet) encountered an issue because of the 4 KB limitation on ext4. But I understand that some Mac applications can store many or large extended attributes which total size could be larger than 4 KB.
I tested on Ubuntu VM:

Code: Select all

$ cp BigAttr /Volumes/share1/
cp: BigAttr: could not copy extended attributes to /Volumes/share1/BigAttr: No space left on device
Result: the file will be copied to share, only xattr will not be copied. If copy from Finder, then it copies in silence, no errors, but also no xattr on the destination.
Mousetick
Experience counts
Posts: 1081
Joined: Thu Aug 24, 2017 10:28 pm

Re: SMB file names

Post by Mousetick »

FWIW in case you might be interested, this blog has a lot of info about xattrs on macOS:
https://eclecticlight.co/tag/xattr/
and a bunch of tools to view/edit/stat xattrs:
https://eclecticlight.co/xattred-sandstrip-xattr-tools/
Post Reply

Return to “Mac OS”