Bug 870256

Summary: Samba "store dos attributes" feature doesn't work with GlusterFS.
Product: [Community] GlusterFS Reporter: Jeff Byers <jbyers>
Component: unclassifiedAssignee: Raghavendra Talur <rtalur>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2.5CC: fharshav, gluster-bugs, jbyers
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-16 20:27:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Byers 2012-10-25 23:44:19 UTC
Samba "store dos attributes" feature doesn't work with GlusterFS.

The Samba feature to map Windows/DOS specific file 
attributes onto Unix files and directories depends upon the 
use of extended file system attributes.

It is enabled by the following settings in the 'smb.conf' 
file:

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

The file system must support extended attributes, and be 
mounted with the 'user_xattr' option.

Unfortunately, when Samba is using a GlusterFS filesystem, 
it never creates any 'user.DOSATTRIB' extended attributes. 

The GlusterFS bricks are mounted with the 'user_xattr' 
option.

However, when I instead point Samba directly to the same 
brick that Gluster is using, the Samba 'store dos 
attributes' feature works fine.

I can manually create 'user.' extended attributes on both 
the GlusterFS and brick mounts:

    # setfattr -n user.test -v test /samba/volume/test.txt
    # setfattr -n user.test -v test2 /exports/brick/volume/test.txt

but when 'security.' attributes are used, the Gluster mount 
fails, and only the direct use of the brick works:

    # setfattr -n security.test -v test /samba/volume/test.txt
    setfattr: /samba/volume/test.txt: Operation not supported
    # setfattr -n security.test -v test2 /exports/brick/volume/test.txt

I'm not sure, but I believe that Samba may use the 
'security.' extended attributes, and failing that, gives up 
on the whole "store dos attributes" feature.

Versions:

    GlusterFS   3.2.5
    Samba       3.6.8
    CentOS      5.8
    
Perhaps there are GlusterFS volume options that I need to 
use to make this work, but I didn't see any likely 
candidates documented anywhere.

Comment 1 Jeff Byers 2012-11-07 00:45:28 UTC
Hello,

The problem I was having with GlusterFS and Samba using the
"store dos attributes" was a configuration error on my part.

The Samba debug log indicated:

[2012/11/05 17:42:34.265825,  8, pid=16066] smbd/dosmode.c:621(dos_mode)
  dos_mode: ./..
[2012/11/05 17:42:34.265932,  1, pid=16066] smbd/dosmode.c:247(get_ea_dos_attribute)
  get_ea_dos_attribute: Cannot get attribute from EA on file ./..: Error = Operation not supported

From the code, when this error reading the Extended
Attribute (EA) occurs, Samba turns the "store dos
attributes" feature off.

gitweb.samba.org - samba.git/blob - source3/smbd/dosmode.c
http://gitweb.samba.org/?p=samba.git;a=blob;f=source3/smbd/dosmode.c#l242

241         sizeret = SMB_VFS_GETXATTR(conn, smb_fname->base_name,
242                                    SAMBA_XATTR_DOS_ATTRIB, attrstr,
243                                    sizeof(attrstr));
244         if (sizeret == -1) {
245                 if (errno == ENOSYS
247                         || errno == ENOTSUP) {
249                                 ) {
251                         DEBUG(1,("get_ea_dos_attribute: Cannot get attribute "
252                                  "from EA on file %s: Error = %s\n",
253                                  smb_fname_str_dbg(smb_fname),
254                                  strerror(errno)));
255                         set_store_dos_attributes(SNUM(conn), False);

What was happening was that Samba was trying to read the
EA's from the root directory, but this was the GlusterFS
mount point, so it didn't have any.

The correct configuration is to have Samba use a sub-
directory of the GlusterFS volume mount-point.

The other problem I mentioned about the 'security' EA's not
working with GlusterFS, but working with the bricks
directly, does appear to be a problem with Samba:

vfs_acl_xattr — Save NTFS-ACLs in Extended Attributes (EAs)
http://www.samba.org/samba/docs/man/manpages-3/vfs_acl_xattr.8.html

which prevents the Samba "vfs objects = acl_xattr" feature
from being used -- it tries and fails to use
'security.NTACL' EA's.

Comment 2 Harshavardhana 2014-06-16 20:27:16 UTC

*** This bug has been marked as a duplicate of bug 1110018 ***