Bug 870256 - Samba "store dos attributes" feature doesn't work with GlusterFS.
Samba "store dos attributes" feature doesn't work with GlusterFS.
Status: CLOSED DUPLICATE of bug 1110018
Product: GlusterFS
Classification: Community
Component: unclassified (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Raghavendra Talur
Depends On:
  Show dependency treegraph
Reported: 2012-10-25 19:44 EDT by Jeff Byers
Modified: 2014-06-16 16:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-16 16:27:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Byers 2012-10-25 19:44:19 EDT
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' 

    # 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' 

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.


    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-06 19:45:28 EST

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

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)

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 16:27:16 EDT

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

Note You need to log in before you can comment on or make changes to this bug.