Bug 11335 - vfs_fruit does not play nice with vfs_zfsacl
vfs_fruit does not play nice with vfs_zfsacl
Status: RESOLVED WORKSFORME
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules
unspecified
x64 Solaris
: P5 normal
: ---
Assigned To: Ralph Böhme
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-16 21:57 UTC by Jorge Schrauwen
Modified: 2016-01-02 00:38 UTC (History)
3 users (show)

See Also:


Attachments
workstation log file (27.30 KB, text/plain)
2015-08-29 19:16 UTC, Jorge Schrauwen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge Schrauwen 2015-06-16 21:57:29 UTC
With AAPL enabled vfs_fruit does not seem to play nice with vfs_zfsacl.

I have the following ACLs:
d---rws---+  7 nobody   user           9 Jun 16 22:01 documents
         group:bckup_ro:r-x---a-R-c--s:-d-----:allow
         group:bckup_ro:r-----a-R-c--s:f------:allow
         group:sysadmin:rwxpdDaARWcCos:-d-----:allow
         group:sysadmin:rw-pdDaARWcCos:f------:allow
                 group@:rwxpdDaARWcCos:-d-----:allow
                 group@:rw-pdDaARWcCos:f------:allow
                 owner@:------a-R-c--s:fd-----:allow
              everyone@:------a-R-c--s:fd-----:allow


With the following config for vfs_zfsacl
   # store DOS attributes in ea
   ea support            = yes
   map hidden            = no
   map system            = no
   map archive           = no
   map readonly          = no
   store dos attributes  = yes

   # zfs acls
   nfs4:mode             = special
   nfs4:acedup           = merge
   nfs4:chown            = yes
   map acl inherit       = yes
   inherit acls          = yes

   # mac osx support (vfs object = +catia +fruit)
   # :: fruit:aapl breaks zfsacl bits *sad puppy*
   fruit:resource        = stream
   fruit:metadata        = stream
   fruit:encoding        = native
   fruit:aapl            = no

This works fine as long as vfs_fruit has the following set:
   fruit:aapl            = no

If this is set to yes (default) my OSX 10.10 client shows the following behavior:
copy from share to local = permissions - owner: none, group: read/write, everyone: none
copy to share = ACLs owner@, group@ and everyone@ get clobbered to rwx, rwx, r-x, other ACL's get properly inherited.

I had a peak at the code but I don't understand much of it, my best guess is that with aapl enabled OSX uses a different way of creating files that does not handle the zfs acl's well.

If I'm missing useful information feel free to ask, I will do my best to provide it tomorrow. It's past midnight here and I spend most of my day figuring this out.
Comment 1 Ralph Böhme 2015-06-17 10:54:42 UTC
Setting the global fruit:nfs_aces to no may help.
Comment 2 Thomas Werschlein 2015-08-28 13:49:35 UTC
The subject of the bug report ("vfs_fruit does not play nice with vfs_zfsacl") does match my problem. Although it manifests slightly different than what Jorge described.

I have a problem with the combination of vfs_zfsacl, vfs_fruit and "create mask = 0664".

The config looks like this:

[xattr]
  path = /test/xattr
  read only = No
  create mask = 0640
  ea support = Yes
  vfs objects = zfsacl fruit streams_xattr

If I drag a folder that was created on a Mac (10.10.4) to this share, the execute flag for the owner gets lost and renders the folder inaccessible.

On the server (Solaris 11.1) it looks like this (for several origins of directories):

root@host:/test/xattr# ls -l
total 6
drwxr-xr-x 2 user 0user 2 Aug 28 10:54 created_on_share_osx/
drwxr-xr-x 2 user 0user 2 Aug 28 10:54 created_on_share_win10/
drw-r-xr-x 2 user 0user 2 Aug 27 09:40 folder_created_on_mac/
drwxr-xr-x 2 user 0user 2 Aug 28 10:34 folder_created_on_win10/

root@host:/test/xattr# for d in `ls -d *`; do runat $d ls -l; done
total 1
-r--r--r-- 1 root root 156 Aug 28 10:54 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 10:54 SUNWattr_rw
total 1
-r--r--r-- 1 root root 156 Aug 28 10:54 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 10:54 SUNWattr_rw
total 2
-rw-rw---- 1 user 0user 402 Aug 28 10:54 org.netatalk.Metadata
-r--r--r-- 1 root  root   156 Aug 28 10:54 SUNWattr_ro
-rw-r--r-- 1 root  root   472 Aug 28 10:54 SUNWattr_rw
total 1
-r--r--r-- 1 root root 156 Aug 28 10:34 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 10:34 SUNWattr_rw

As you can see, the directory "folder_created_on_mac" which was dragged from the Mac to the share lacks the "x" flag for the user. It is also the only directory that - no surprise - gets an additional xattr (org.netatalk.Metadata).

Without the "zfsacl" VFS module everything works fine, i.e. with

[xattr]
  path = /test/xattr
  read only = No
  create mask = 0640
  ea support = Yes
  vfs objects = fruit streams_xattr

the permissions are applied correctly:

root@host:/test/xattr# ls -l
total 6
drwxr-xr-x 2 user 0user 2 Aug 28 11:00 created_on_share_osx/
drwxr-xr-x 2 user 0user 2 Aug 28 11:00 created_on_share_win10/
drwxr-xr-x 2 user 0user 2 Aug 27 09:40 folder_created_on_mac/
drwxr-xr-x 2 user 0user 2 Aug 28 10:34 folder_created_on_win10/

root@host:/test/xattr# for d in `ls -d *`; do runat $d ls -l; done
total 1
-r--r--r-- 1 root root 156 Aug 28 11:00 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 11:00 SUNWattr_rw
total 1
-r--r--r-- 1 root root 156 Aug 28 11:00 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 11:00 SUNWattr_rw
total 2
-rw-rw---- 1 user 0user 402 Aug 28 11:00 org.netatalk.Metadata
-r--r--r-- 1 root  root   156 Aug 28 11:00 SUNWattr_ro
-rw-r--r-- 1 root  root   472 Aug 28 11:00 SUNWattr_rw
total 1
-r--r--r-- 1 root root 156 Aug 28 10:34 SUNWattr_ro
-rw-r--r-- 1 root root 472 Aug 28 10:34 SUNWattr_rw

Furthermore, if the "create mask" is set to the default of "0740" there is no problem either.

Ralphs suggestion of setting "fruit:nfs_aces" to "no" did not help in my case.

This problems seems related to Bug 11448, so vfs_streams_xattr might actually be the culprit?
Comment 3 Stefan Metzmacher 2015-08-28 13:55:33 UTC
(In reply to Thomas Werschlein from comment #2)

Have you tried using zfsacl after fruit instead of before?

fruit streams_xattr zfsacl
or
fruit zfsacl streams_xattr
Comment 4 Thomas Werschlein 2015-08-28 20:13:24 UTC
(In reply to Stefan Metzmacher from comment #3)

Indeed, that did the trick! Both variations work.

I had the wrong impression that fruit and streams_xattr had to be at the end of the VFS stack. But the manpage only states "This module is not stackable other then described in this manpage." My bad.

Thanks a lot for pointing out.
Comment 5 Jorge Schrauwen 2015-08-29 18:55:40 UTC
Sorry for the late reply, I just saw the mention of fruit:nfs_aces.

I am now able to copy files from my shares to my mac. (Yay!)
However I am now unable to write to the share.

For completeness this is my vfs objects line:
vfs objects           = crossrename catia fruit streams_xattr zfsacl
Comment 6 Jorge Schrauwen 2015-08-29 19:02:20 UTC
(In reply to Jorge Schrauwen from comment #5)
Some followup info:

-- config snippet --
   vfs objects           = crossrename catia fruit streams_xattr zfsacl
   fruit:resource        = stream
   fruit:metadata        = stream
   fruit:encoding        = native
   fruit:aapl            = no
   fruit:nfs_aces        = no
-- end config snippet --

where test_normal was created without vfs_fruit/catia and test_fruit with it loaded with the following settings

-- directories created --
d---rws---+  2 sjorge   user           3 Aug 29 20:57 test_fruit
         group:bckup_ro:r-x---a-R-c--s:-d----I:allow
         group:bckup_ro:r-----a-R-c--s:f-i---I:allow
         group:sysadmin:rwxpdDaARWcCos:-d----I:allow
         group:sysadmin:rw-pdDaARWcCos:f-i---I:allow
                 group@:rwxpdDaARWcCos:-d----I:allow
                 group@:rw-pdDaARWcCos:f-i---I:allow
                 owner@:------a-R-c--s:fd----I:allow
              everyone@:------a-R-c--s:fd----I:allow
d---rws---+  2 sjorge   user           4 Aug 29 20:56 test_normal
         group:bckup_ro:r-x---a-R-c--s:-d----I:allow
         group:bckup_ro:r-----a-R-c--s:f-i---I:allow
         group:sysadmin:rwxpdDaARWcCos:-d----I:allow
         group:sysadmin:rw-pdDaARWcCos:f-i---I:allow
                 group@:rwxpdDaARWcCos:-d----I:allow
                 group@:rw-pdDaARWcCos:f-i---I:allow
                 owner@:------a-R-c--s:fd----I:allow
              everyone@:------a-R-c--s:fd----I:allow
-- directories created --

-- files created --
test_fruit/:
total 1
----rw----+  1 sjorge   user           0 Aug 29 21:00 [bspwm] June 2015 - unixporn.webloc
         group:bckup_ro:r-----a-R-c--s:------I:allow
         group:sysadmin:rw-pdDaARWcCos:------I:allow
                 group@:rw-pdDaARWcCos:------I:allow
                 owner@:------a-R-c--s:------I:allow
              everyone@:------a-R-c--s:------I:allow

test_normal/:
total 18
----rw----+  1 sjorge   user         289 Jun  6 09:45 [bspwm] June 2015 - unixporn.webloc
         group:bckup_ro:r-----a-R-c--s:------I:allow
         group:sysadmin:rw-pdDaARWcCos:------I:allow
                 group@:rw-pdDaARWcCos:------I:allow
                 owner@:------a-R-c--s:------I:allow
              everyone@:------a-R-c--s:------I:allow
----rw----+  1 sjorge   user         323 Jul  7 17:49 [bspwm] after 4 months with bspwm I finally made my own config! - unixporn.webloc
         group:bckup_ro:r-----a-R-c--s:------I:allow
         group:sysadmin:rw-pdDaARWcCos:------I:allow
                 group@:rw-pdDaARWcCos:------I:allow
                 owner@:------a-R-c--s:------I:allow
              everyone@:------a-R-c--s:------I:allow
--


Mac OS X fails after copying the first file (I copied both at ones)
MSG: "The Finder can’t complete the operation because some data in “[bspwm] June 2015 - unixporn” can’t be read or written.
(Error code -36)"

The resulting file with fruit enabled is empty.
Comment 7 Jorge Schrauwen 2015-08-29 19:16:42 UTC
Created attachment 11379 [details]
workstation log file
Comment 8 Jorge Schrauwen 2015-08-29 19:31:22 UTC
Fixed it!

So setting 'fruit:nfs_aces' to no AND having fruit AFTER zfsacls seems to work:
-----

   vfs objects           = crossrename streams_xattr zfsacl catia fruit

   # store DOS attributes in ea
   ea support            = yes
   map hidden            = no
   map system            = no
   map archive           = no
   map readonly          = no
   store dos attributes  = yes

   # handle snapshots and osx dirt
   veto files            = /.zfs/.$EXTEND/.AppleDouble/.AppleDesktop/.TemporaryItems/Network Trash Folder/._*/.DS_Store/Thumbs.db/
   delete veto files     = yes

   # mac osx support (vfs object = +catia +fruit)
   # :: buggy -> icons don't work, permissions are screwed up
   fruit:resource        = stream
   fruit:metadata        = stream
   fruit:encoding        = native
   fruit:aapl            = no
   fruit:nfs_aces        = no

   # service-side rename (files <50M)
   crossrename:sizelimit = 50

   # zfs acls
   nfs4:mode             = special
   nfs4:acedup           = merge
   nfs4:chown            = yes
   map acl inherit       = yes
   inherit acls          = yes

-----

Directory listing is now super fast, creating files has the correct ACL applied and copying to local now also has OK permissions. Copying a lot of small files seems slower though.