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.
Setting the global fruit:nfs_aces to no may help.
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?
(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
(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.
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
(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.
Created attachment 11379 [details] workstation log file
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.