samba - Jul 2015 - vfs fruit unable to create xattr and ACL from OS X 10.10.4

Hello

I am trying to integrate OS X 10.10.4 clients into existing Samba infractructure
run by our IT department.
We are currently using Samba 4.2.3.
File share is stored on iSCSI array with ext4 filesystem which should support
both ACL and XATTR.

We are trying to setup vfs_fruit module to avoid possible performance problems
on OS X clients.
We do NOT user netatalk.

Current vfs_fruit config:

       vfs objects = catia fruit streams_xattr
       fruit:resource = file
       fruit:metadata = netatalk
       fruit:locking = none
       fruit:encoding = private
       fruit:aapl = yes
       readdir_attr:aapl_rsize = true
       readdir_attr:aapl_finder_info = true
       readdir_attr:aapl_max_access = true
       fruit:nfs_aces = yes
       fruit:veto_appledouble = yes

Problem -> OS X clients are unable to create new extended attributes (and
ACLs) with exception of ResourceFork and FinderInfo which are handled directly
by vfs_fruit and saved to internal AppleDouble file.

When I try to create new custom extended attribute with xattr -w
com.xattr.example testdata somefile
and than try to display it with ls -lae@ there is nothing there.

When I try to set new ACL with chmod +a “some ace” file I get “Operation not
supported”.


I want to ask about few things.

1) from vfs_fruit man page -> “All other named streams are deferred to
vfs_streams_xattr which must be loaded together with vfs_fruit.” From
vfs_streams_xattr man page  “The file system that is shared with this module
enabled must support xattrs.”.
How do I confirm for sure that our storage supports required xattrs thus
vfs_streams_xattr module should work with it?

2) Is there possible misconfiguration in vfs_fruit options listed above? Is
there any missing configuration for vfs_streams_xattr module?

3) Is it possible that OS X client is trying write directly to AppleDouble files
which can’t be accessed because of vetoing? (See log bellow)

Log -> I was trying to create xattr for files m/moravmi8/test/drak and
m/moravmi8/test/xattr.

[2015/07/28 14:12:52.509058,  3, pid=2393, effective(11669, 100),
real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1143(check_reduced_name)
 check_reduced_name [m/moravmi8/test/drak] [/mnt/ucebny_home/home]
[2015/07/28 14:12:52.509116,  3, pid=2393, effective(11669, 100),
real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1273(check_reduced_name)
 check_reduced_name: m/moravmi8/test/drak reduced to
/mnt/ucebny_home/home/m/moravmi8/test/drak
[2015/07/28 14:12:52.509190,  3, pid=2393, effective(11669, 100),
real(11669, 0)] ../source3/smbd/dosmode.c:196(unix_mode)
 unix_mode(m/moravmi8/test/drak) returning 0744
[2015/07/28 14:12:52.509343,  2, pid=2393, effective(11669, 100),
real(11669, 0)] ../source3/smbd/open.c:1005(open_file)
 UCEBNY\moravmi8 opened file m/moravmi8/test/drak read=No write=No
(numopen=2)
[2015/07/28 14:12:52.509748,  2, pid=2393, effective(11669, 100),
real(11669, 0), class=fruit]
../source3/modules/vfs_fruit.c:880(ad_header_read_rsrc)
 open AppleDouble: m/moravmi8/test/._drak, No such file or directory
[2015/07/28 14:12:52.509875,  2, pid=2393, effective(11669, 100),
real(11669, 0)] ../source3/smbd/close.c:780(close_normal_file)
 UCEBNY\moravmi8 closed file m/moravmi8/test/drak (numopen=1) NT_STATUS_OK
[2015/07/28 14:12:52.510396,  3, pid=2393, effective(11669, 100),
real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1143(check_reduced_name)
 check_reduced_name [m/moravmi8/test/xattr] [/mnt/ucebny_home/home]
[2015/07/28 14:12:52.510452,  3, pid=2393, effective(11669, 100),
real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1273(check_reduced_name)
 check_reduced_name: m/moravmi8/test/xattr reduced to
/mnt/ucebny_home/home/m/moravmi8/test/xattr
[2015/07/28 14:12:52.510877,  2, pid=2393, effective(11669, 100),
real(11669, 0), class=fruit]
../source3/modules/vfs_fruit.c:880(ad_header_read_rsrc)
 open AppleDouble: m/moravmi8/test/._xattr, No such file or directory

Captured packets from Wireshark in attachment.

If you have any ideas how should I procede I would be happy to hear them :-)
Regards
Michal Moravec
-------------- next part --------------

On Tue, Jul 28, 2015 at 02:55:32PM +0200, Michal Moravec
wrote:
> Hello
> 
> I am trying to integrate OS X 10.10.4 clients into existing Samba
infractructure run by our IT department.
> We are currently using Samba 4.2.3.
> File share is stored on iSCSI array with ext4 filesystem which should
support both ACL and XATTR.
> 
> We are trying to setup vfs_fruit module to avoid possible performance
problems on OS X clients.
> We do NOT user netatalk.
> 
> Current vfs_fruit config:
> 
>        vfs objects = catia fruit streams_xattr
>        fruit:resource = file
>        fruit:metadata = netatalk
>        fruit:locking = none
>        fruit:encoding = private
>        fruit:aapl = yes
>        readdir_attr:aapl_rsize = true
>        readdir_attr:aapl_finder_info = true
>        readdir_attr:aapl_max_access = true
>        fruit:nfs_aces = yes
>        fruit:veto_appledouble = yes
fwiw, I'd remove anything that is the default.
> Problem -> OS X clients are unable to create new extended attributes
> (and ACLs) with exception of ResourceFork and FinderInfo which are
> handled directly by vfs_fruit and saved to internal AppleDouble
> file.
>
> When I try to create new custom extended attribute with xattr -w
> com.xattr.example testdata somefile and than try to display it with
> ls -lae@ there is nothing there.
Hm, works for me:

mac$ mount | grep smb
//ralph at 10.10.11.100/AAPL on /Volumes/AAPL (smbfs, nodev, nosuid, mounted by
ralph)
mac$ touch /Volumes/AAPL/test
mac$ xattr -w foo bar /Volumes/AAPL/test
mac$ xattr -l /Volumes/AAPL/test
foo: bar
mac$ 
> When I try to set new ACL with chmod +a “some ace” file I get “Operation
not supported”.
As expected, afair the client doesn't support modifyint ACLs on an smb
mount. Have you verified this works against an Apple SMB server?
> I want to ask about few things.
> 
> 1) from vfs_fruit man page -> “All other named streams are deferred
> to vfs_streams_xattr which must be loaded together with vfs_fruit.”
> From vfs_streams_xattr man page “The file system that is shared with
> this module enabled must support xattrs.”.  How do I confirm for
> sure that our storage supports required xattrs thus
> vfs_streams_xattr module should work with it?
man setfattr
> 2) Is there possible misconfiguration in vfs_fruit options listed
> above? Is there any missing configuration for vfs_streams_xattr
> module?
Looks good.
> 3) Is it possible that OS X client is trying write directly to
> AppleDouble files which can’t be accessed because of vetoing? (See
> log bellow)
Probably not.
> Log -> I was trying to create xattr for files m/moravmi8/test/drak and
m/moravmi8/test/xattr.
> 
> [2015/07/28 14:12:52.509058,  3, pid=2393, effective(11669, 100),
> real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1143(check_reduced_name)
>  check_reduced_name [m/moravmi8/test/drak] [/mnt/ucebny_home/home]
> [2015/07/28 14:12:52.509116,  3, pid=2393, effective(11669, 100),
> real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1273(check_reduced_name)
>  check_reduced_name: m/moravmi8/test/drak reduced to
> /mnt/ucebny_home/home/m/moravmi8/test/drak
> [2015/07/28 14:12:52.509190,  3, pid=2393, effective(11669, 100),
> real(11669, 0)] ../source3/smbd/dosmode.c:196(unix_mode)
>  unix_mode(m/moravmi8/test/drak) returning 0744
> [2015/07/28 14:12:52.509343,  2, pid=2393, effective(11669, 100),
> real(11669, 0)] ../source3/smbd/open.c:1005(open_file)
>  UCEBNY\moravmi8 opened file m/moravmi8/test/drak read=No write=No
> (numopen=2)
> [2015/07/28 14:12:52.509748,  2, pid=2393, effective(11669, 100),
> real(11669, 0), class=fruit]
> ../source3/modules/vfs_fruit.c:880(ad_header_read_rsrc)
>  open AppleDouble: m/moravmi8/test/._drak, No such file or directory
> [2015/07/28 14:12:52.509875,  2, pid=2393, effective(11669, 100),
> real(11669, 0)] ../source3/smbd/close.c:780(close_normal_file)
>  UCEBNY\moravmi8 closed file m/moravmi8/test/drak (numopen=1) NT_STATUS_OK
> [2015/07/28 14:12:52.510396,  3, pid=2393, effective(11669, 100),
> real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1143(check_reduced_name)
>  check_reduced_name [m/moravmi8/test/xattr] [/mnt/ucebny_home/home]
> [2015/07/28 14:12:52.510452,  3, pid=2393, effective(11669, 100),
> real(11669, 0), class=vfs] ../source3/smbd/vfs.c:1273(check_reduced_name)
>  check_reduced_name: m/moravmi8/test/xattr reduced to
> /mnt/ucebny_home/home/m/moravmi8/test/xattr
> [2015/07/28 14:12:52.510877,  2, pid=2393, effective(11669, 100),
> real(11669, 0), class=fruit]
> ../source3/modules/vfs_fruit.c:880(ad_header_read_rsrc)
>  open AppleDouble: m/moravmi8/test/._xattr, No such file or directory
That's just an internal open.
> Captured packets from Wireshark in attachment.
> 
> If you have any ideas how should I procede I would be happy to hear them
:-)
I'd be happy to help, but being busy atm I'll have to see when to take
another look.

-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt at sernet.de

> On 29 Jul 2015, at 10:02, Ralph Böhme <rb at sernet.de> wrote:
> Hm, works for me:
> 
> mac$ mount | grep smb
> //ralph at 10.10.11.100 <mailto:ralph at 10.10.11.100>/AAPL on
/Volumes/AAPL (smbfs, nodev, nosuid, mounted by ralph)
> mac$ touch /Volumes/AAPL/test
> mac$ xattr -w foo bar /Volumes/AAPL/test
> mac$ xattr -l /Volumes/AAPL/test
> foo: bar
> mac$ 

It does not matter if I use ls -la@ or xattr -l. Nothing is there.
> As expected, afair the client doesn't support modifyint ACLs on an smb
> mount. Have you verified this works against an Apple SMB server?
I didn’t know that. I confirm client can’t do this with Apple SMB server either.
Thank you for info.

>>       fruit:nfs_aces = yes
>>       fruit:veto_appledouble = yes
> 
> fwiw, I'd remove anything that is the default.
Are there any possible problems with this approach apart from convention/cleaner
config?
Our Samba admin prefers it this way.

> man setfattr
admin-apple # touch test.txt
admin-apple # setfattr -n user.test -v test test.txt
admin-apple # setfattr -n security.test -v test2 test.txt
admin-apple # getfattr -d test.txt
# file: test.txt
user.test="test"

admin-apple # getfattr -n security.test -d test.txt
# file: test.txt
security.test="test2"

From this output I conclude extended attributes are indeed supported on our
storage array.
> I'd be happy to help, but being busy atm I'll have to see when to
take
> another look.
Thank you. I would appriciate some tips how to debug this and find what is
causing this problem.

MichalM