2

MacOSX filesystems use extended attributes (e.g. "com.apple.quarantine", "com.apple.FinderInfo"):

$ ls -l@ .DS_Store 
-rw-r--r--@ 1 gareth  staff  18436  2 Nov 10:35 .DS_Store
    com.apple.FinderInfo       32
  1. Can these extended attributes be stored across an NFS mount at all?
  2. Can these extended attributes be stored across an NFS mount of an ext4 filesystem? That is, so that an extended attribute on an HFS+ file (seen with xattr -l ) can be seen in some way on the ext4 file system (with getfattr -d ).

A problem appears to be that ext4 file systems require user attributes to begin with "user.", which makes it incompatible with MacOSX: E.g. the following command works on Linux because the name starts with "user."

Linux# setfattr -n "user.hello" -v "some data" examplefile

but the following fails:

Linux# setfattr -n "com.apple.Finder" -v "some data" examplefile
setfattr: examplefile: Operation not supported

So could extended attributes ever be stored, unless they were automatically renamed? E.g. "com.apple.Finder" could be stored as "user.com.apple.Finder".

I have tried to research this using a MacOSX NFS client to mount a Debian Linux NFS server. (Finder -> Go -> Connect to Server...) The mount appears to work but as soon as the GUI tries to browse it tries to create a .DS_Store file with extended attributes and the whole NFS connection locks up and fails. (At least, I think that's the reason it fails. I was able to copy a small file without attributes, before attempting to browse.)

Any insights in to this question will be appreciated. Thanks!

Castaglia
  • 3,349
  • 3
  • 21
  • 42
Gareth Randall
  • 21
  • 3

1 Answers1

2

NFS protocol does not support extended attributes and. as a result, you can't transfer local extended attributes to the server. There are some effort in NFS community to make it possible, but it will take some time until it will be available.

kofemann
  • 4,626
  • 1
  • 25
  • 30