xattr in rsync are mapped differently than via SMB — NAS runs Samba with Mac friendly module vfs_fruit

[porg]

Use Case & User Goals

• The data superset is on the NAS.
• Occasionally I download files/folders of that superset to my Mac:
  • Via Finder (if hand picked) or rsync (for filtering or recursive use cases).
  • Then I view the files locally for a while (videos mostly).
  • The only aspects I change are the files' tags (metadata), not their content (data fork).
• Prior deleting the local file copies of the superset, I sync up their changed tags (mix of content classification tags and workflow tags) to the NAS.
  • Dragging files in Finder from Mac to NAS would copy them fully, not only their changed tags.
    • One can only achieve pure Finder tag transfer by manually copying tags. 👍 Very cumbersome.
    • Or await the full file transfer although only tags changed. 👍 Wasted bandwidth/time.
  • Rsync with the proper arguments (--archive --xattr) is clever enough to only transfer the xattr. 👎 Very fast!

Problem

1. rsync --xattr ~/path/ nas.local::Shared-rsync/path/ (sender on Mac, receiver on NAS) maps the xattr differently
2. than when copying from the Mac to a SMB mounted share (served by Samba with the Mac friendly vfs_fruit module)
   • 2a) CLI: cp ~/path/file.txt /Volumes/Shared/path/
   • 2b) GUI: In the Finder drag-n-drop file.txt from local ~/path/ to the mounted SMB share /Volumes/Shared/path/

• Viewing ~/path/ in a Finder window and the mounted SMB share /Volumes/Shared/path/ in another Finder window and copying with…
  • …methods 2a) and 2b) the Finder tags on the remote destination refresh immediately and correctly as they are on the local source.
  • …method 1) the Finder tags on the remote destinations get visually lost.
    • In reality they are now also there, but got written into the wrong xattr, and the previously correctly mapped xattr got deleted. Hence the tag(s) is/are not shown by the Finder anymore.

Environment

MacBook Pro (Mid 2014)

• MacOS 11.6.7 Big Sur
  • rsync version 3.2.4 protocol version 31 (installed via HomeBrew)
    • Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, symlinks, symtimes, hardlinks, hardlink-specials, hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv, no prealloc, stop-at, crtimes, file-flags
    • Optimizations: no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
    • Checksum list: xxh128 xxh3 xxh64 (xxhash) md5 md4 none
    • Compress list: zstd lz4 zlibx zlib none

Odroid Home Cloud 2 — Single Board Computer (SBC) acting as a Network Attached Storage (NAS)

• OpenMediaVault 5.6.21-2 (Debian based) Linux 4.14.222-odroidxu4
  • rsync version 3.1.3 protocol version 31
    • Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, prealloc
  • Samba, using module vfs_fruit for "Enhanced OS X and Netatalk interoperability", see config file:

/etc/samba/smb.conf 👈 Click to expand

``` ini # This file is auto-generated by openmediavault (https://www.openmediavault.org) # WARNING: Do not edit this file, your changes will get lost. #======================= Global Settings ======================= [global] workgroup = WORKGROUP server string = %h server dns proxy = no log level = 2 log file = /var/log/samba/log.%m max log size = 1000 logging = syslog panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = no unix password sync = no passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes socket options = TCP_NODELAY IPTOS_LOWDELAY guest account = nobody load printers = no disable spoolss = yes printing = bsd printcap name = /dev/null unix extensions = yes wide links = no create mask = 0777 directory mask = 0777 use sendfile = yes aio read size = 16384 aio write size = 16384 time server = no wins support = no multicast dns register = no # Special configuration for Apple's Time Machine # Coming from GUI autoconfig fruit:aapl = yes # Coming from GUI autoconfig # Extra options # OMV default extra options min receivefile size = 16384 write cache size = 524288 getwd cache = yes socket options = TCP_NODELAY IPTOS_LOWDELAY # Recommendations from # https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X # man vfs_fruit min protocol = SMB2 ea support = yes vfs objects = fruit streams_xattr # https://support.apple.com//HT207128 # would recommended "catia fruit streams_xattr". Did not try that yet. fruit:aapl = yes # Manually by me in extra options of GUI fruit:metadata = stream fruit:posix_rename = yes fruit:veto_appledouble = no fruit:nfs_aces = no fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes #======================= Share Definitions ======================= [Shared] path = /srv/dev-disk-by-label-share/Shared/ guest ok = no guest only = no read only = no browseable = yes inherit acls = yes inherit permissions = no ea support = no store dos attributes = no vfs objects = # Coming from GUI autoconfig. Afraid this nullifies. printable = no create mask = 0664 force create mode = 0664 directory mask = 0775 force directory mode = 0775 hide special files = yes follow symlinks = yes hide dot files = no # These seem to be derived from the settings for the share folder by the autoconfig: valid users = "wife","me" invalid users = @"kids" read list = "wife" write list = "me" vfs objects = fruit streams_xattr # Hence manually aded by me in extra options of GUI. ```

Background Info

RFC 8276 — File System Extended Attributes in NFSv4 (December 2017)

• The Samba module vfs_fruit seems to be the implementation of that required mapping.
• Rsync as sender on Mac and receiver on the NAS seems to not use that same xattr mapping.

MacOS stores the Finder tags in an xattr named com.apple.metadata:_kMDItemUserTags as a binary PLIST.

• File 8.txt has the Finder Tag "•TODO" which also has the red label color.
• File 15.txt has the Finder Tag "Artwork" without any color. Later amended by tags "Automation" & "Billing".

HEX/plaintext output of xattr com.apple.metadata:_kMDItemUserTags 👈 Click to to see the raw BPLIST value in the xattrs

``` $ xattr -l ~/mac/path/8.txt # With Finder Tag "•TODO" & also having a red label color. com.apple.FinderInfo: 00000000 00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 com.apple.metadata:_kMDItemUserTags: 00000000 62 70 6C 69 73 74 30 30 A1 01 67 20 22 00 54 00 |bplist00..g ".T.| 00000010 6F 00 64 00 6F 00 0A 00 36 08 0A 00 00 00 00 00 |o.d.o...6.......| 00000020 00 01 01 00 00 00 00 00 00 00 02 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 19 |...........| $ xattr -l ~/mac/path/15.txt # With Finder Tag "Artwork" without any color. com.apple.metadata:_kMDItemUserTags: 00000000 62 70 6C 69 73 74 30 30 A1 01 57 41 72 74 77 6F |bplist00..WArtwo| 00000010 72 6B 08 0A 00 00 00 00 00 00 01 01 00 00 00 00 |rk..............| 00000020 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 12 |....| 00000034 $ xattr -l ~/mac/path/15.txt # Meanwhile tag "Automation" was added to the end. com.apple.metadata:_kMDItemUserTags: 00000000 62 70 6C 69 73 74 30 30 A2 01 02 57 41 72 74 77 |bplist00...WArtw| 00000010 6F 72 6B 5A 41 75 74 6F 6D 61 74 69 6F 6E 08 0B |orkZAutomation..| 00000020 13 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 |................| 00000030 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 1E |.| 00000041 $ xattr -l ~/mac/path/15.txt # Meanwhile tag "Billing" was inserted at start. com.apple.metadata:_kMDItemUserTags: 00000000 62 70 6C 69 73 74 30 30 A3 01 02 03 57 42 69 6C |bplist00....WBil| 00000010 6C 69 6E 67 57 41 72 74 77 6F 72 6B 5A 41 75 74 |lingWArtworkZAut| 00000020 6F 6D 61 74 69 6F 6E 08 0C 14 1C 00 00 00 00 00 |omation.........| 00000030 00 01 01 00 00 00 00 00 00 00 04 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 27 |..........'| 0000004b ```

Debian's xattr -l crashes with UnicodeDecodeError for com.apple.metadata:_kMDItemUserTags

• Sadly there's a yet undetected bug in the xattr command line tool on my NAS "Odroid Home Cloud 2", running Open Media Vault 5, Debian based.

• When attempting to display xattrs in the list output mode which is hardcoded to a combined HEX/plaintext-interpretation output, values which cannot be interpreted as ASCII or UTF-8 as they are present in the proprietary com.apple.metadata:_kMDItemUserTags cause a crash:

  xattr -l /nas/path/15.txt  # Run on the NAS via SSH from the Mac
  Traceback (most recent call last):
    File "/usr/bin/xattr", line 11, in <module>
      load_entry_point('xattr==0.9.6', 'console_scripts', 'xattr')()
    File "/usr/lib/python3/dist-packages/xattr/tool.py", line 196, in main
      attr_value = attr_value.decode('utf-8')
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 8: invalid start byte

  • Offtopic shortly: Could some Debian user please file this on my behalf? Debian has a really oldschool bug tracker (no web interface like Github or Bugzilla. One needs to install Terminal tool reportbug and have a Terminal based mail sending infrastructure. Really nerdy 1980ies mailing list backwards compatibility.

• When this display bug happens the xattr command line tool only shows key/value pairs prior the first problematic key/value pair in encounters, and for that problematic key/value pair it does not even show the key name.

  • So this made debugging harder. But through trial/error with custom xattr I nevertheless figured out what the genral mapping problem is.
  • Therefore to demonstrate the xattr mapping problems to you I use arbitrary self made xattr where both key/value contain ASCII only, so that I can also show how it looks on the NAS itself without any SMB alternate data stream (ADS) transformations.
  • But practically I care mostly for the Finder tags which are encoded as a binary PLIST in the xattr com.apple.metadata:_kMDItemUserTags working well in a mixed mode usage of the NAS sometimes accessed via rsync and sometimes via SMB.

Problem in detail

Ad 2) When using rsync <my-arguments> ~/path/ /Volumes/SMB-Mounted-Share/path/

• rsync works purely locally, and the xattrs transfer with a mapping which works in practise:

• In the Finder windows ~/path/ and /Volumes/SMB-Mounted-Share/path/ the file-with-finder-tags.txt shows the same tags in both windows immediately after sync.

  • On the Mac, xattr of the local file:

    xattr -l ~/file-with-arbitrary-xattr.txt
    myVar: Thanks

  • On the NAS via SSH:

    xattr -l file-with-arbitrary-xattr.txt
    user.DosStream.myVar:$DATA:
    0000   54 68 61 6E 6B 73 00                               Thanks.

  • On the Mac, xattr of the SMB accessed file:

    xattr -l /Volumes/SMB-Mounted-Share/path/file-with-arbitrary-xattr.txt
    myVar: Thanks

  • In this form rsync itself works purely locally: On a local filesystem ~/path/ and on a locally mounted remote filesystem /Volumes/SMB-Mounted-Share/path/ whose network abstraction is handled by SMB.

    • 👎 So the delta algorithm between the rsync sender on the Mac and the rsync receiver on the NAS does not get facilitated.
    • 💡 In the case that I only change metadata (majority of my use cases) it works fine as it only transfers the metadata changes.
    • 👎 But in case there's also a change in the data fork of the file, the whole file gets transfered, no delta transfer gets facilitated.

Ad 1) When using rsync <my-arguments> ~/path/ nas.local::Shared-rsync/path/

• rsync is used both as sender on the Mac and receiver on the NAS

  • 👍 So I would benefit from all delta transfer benefits.

  • 👎 but the xattr mapping goes practically wrong

  • ℹ️ Prior the next rsync

    • I deleted file-with-arbitrary-xattr.txt on the NAS.
    • Changed its xattr myVar to the Italian "Grazie".

  • Then ran the rsync:

    rsync --archive --xattrs --delete --verbose --stats \
    --progress --itemize-changes --human-readable \
    ~/path/ odroid.local::Shared-rsync/path/

  • On the Mac, xattr of the local file:

    xattr -l file-with-arbitrary-xattr.txt
    myVar: Grazie

  • On the NAS via SSH:

    xattr -l file-with-arbitrary-xattr.txt
    user.myVar: Grazie

  • On the Mac, xattr of the SMB accessed file:

    xattr -l /Volumes/SMB-Mounted-Share/path/file-with-arbitrary-xattr.txt
    # Returns NULL. The mapping seems to fail.

Followup

• I'm no developer, only a somehow tech-savvy user.
  • Hence I do not and cannot say rsync --xattr from Mac to Linux is wrongly implemented.
  • In its current form it is at best useful when using rsync itself only.
• But I can state clearly: In a mixed setup, and especially in a GUI setup (Finder) it is useless and dangerous (data-loss!) in its current form.
  • I think rsync should offer a mode to map the xattrs like SMB does, to be really of use in normal Mac/NAS practise.
  • And to be on the safe side for medium Mac/NAS/SMB-savvy users like me (before 2 days of research & experimentation) that combined "user" plus "DosStream" mapping should be considered to be the safe default when using --xattr on Mac rsync, and there should be rather a switch for a "a pure linux user namespace mode not compatible with SMB/Finder".

[SEIAROTg]

I think the mapping is configurable in Samba to match rsync's behavior.

https://www.samba.org/samba/docs/current/man-html/vfs_streams_xattr.8.html

[porg]

How exactly would that help?

I forgot everything meanwhile, my lengthy/detailed post is 2 years old.

By which concrete mappings could one improve the use case rsync is used both as sender on the Mac and receiver on the NAS ?

[SEIAROTg]

You can set the prefix to match rsync (as sender & receiver) and drop the suffix.

streams_xattr:prefix = user.
streams_xattr:store_stream_type = no

It also works for your first usage (rsync into SMB mount). However, when doing that rsync might fail (unrelated to these settings) when one xattr is a prefix of another, due to a bug in Apple SMB client implementation.

[porg]

Thanks. As I do not have that use case anymore (too often) I currently don't have the time to try it out and give feedback on it. But I gladly come back here, should I need it at a later time. Thanks for having taken the time!