Bug 1027686 - Windows clients are not able to retrieve and not respecting ACLs on directories
Windows clients are not able to retrieve and not respecting ACLs on directories
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: samba (Show other bugs)
2.1
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Raghavendra Talur
Lalatendu Mohanty
: Regression, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 04:48 EST by Lalatendu Mohanty
Modified: 2013-11-27 10:46 EST (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0.40rhs-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-27 10:46:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lalatendu Mohanty 2013-11-07 04:48:37 EST
Description of problem:

On smb mount points using Windows clients, when ACL is set for a user or a group , it is not getting reflected in the Windows folder properties. If I mount the volume using native fuse and "-o acl", then I can see (using getfacl command ) posix acl is properly set.

Version-Release number of selected component (if applicable):

glusterfs-server-3.4.0.39rhs-1.el6rhs.x86_64

How reproducible:

Always

Steps to Reproduce: 

Below test is done on a Active directory setup

1. Create and start a gluster volume
2. Do "gluster volume set <volume name> storage.batch-fsync-delay-usec 0 and "gluster v set <volume name> stat-prefetch off"
3. put "option rpc-auth-allow-insecure on" in /etc/glusterfs/glusterd.vol  and restart glusterd (in all rhs nodes)
4. Mount the gluster volume in the rhsnode which is joined to the windows domain
mount -t glusterfs -o acl ${rhsNode}:/${volname} /mnt/testvol/

5. Create a directory in the mount point
 mkdir /mnt/testvol/<dir>
6. Change the group of the directory to a group in the active directory domain

chgrp 'usersfromotherforests' /mnt/testvol/<dir>

7. Set the default permission on the folder

chmod 770 /mnt/testvol/<dir>

On the client

8. Mount the directory on a Windows client. 

9. Create a directory and a subdirectory in it.

10. Give a new group some permission on the directory and sub directory.

11. Check the  security properties to see if the group is present.

12. Verify that if the permissions (by doing some operation) you have given in step #10 is valid for the users from other group

Actual results:

Step #10, #11, #12  are failing. new acls are not visible on the directory and not being respected.

Expected results:


Additional info:

However after setting acls, If I run getfacl on the directory (on fuse mount with -o acl) to see if the posix acls are being set, I can see the posix acls being set correctly.

Volume Name: dis-rep12
Type: Distributed-Replicate
Volume ID: deb2f590-5275-4e26-8ccb-17ebd49b60de
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.70.37.136:/rhs/brick1/dis-rep12-b1
Brick2: 10.70.37.122:/rhs/brick1/dis-rep12-b1
Brick3: 10.70.37.136:/rhs/brick2/dis-rep12-b2
Brick4: 10.70.37.122:/rhs/brick2/dis-rep12-b2
Options Reconfigured:
performance.stat-prefetch: off
storage.batch-fsync-delay-usec: 0


[root@bvt-rhs3 dis-rep1]# getfacl hobbit
# file: hobbit
# owner: hobbit1
# group: domain\040users
user::rwx
group::r-x
group:SMBQE-2008-DC+dragons:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::---
default:group:SMBQE-2008-DC+dragons:rwx
default:mask::rwx
default:other::---
Comment 2 Lalatendu Mohanty 2013-11-07 05:13:48 EST
This was working in RHS2.1 and early builds of RHS2.1 U1. I think it was working in glusterfs-server-3.4.0.36rhs-1.el6rhs.x86_64on
Comment 4 Raghavendra Talur 2013-11-07 08:20:24 EST
This was caused by patch:
https://code.engineering.redhat.com/gerrit/#/c/15077/

Verified by reverting the patch.
Comment 5 Raghavendra Talur 2013-11-07 13:18:06 EST
https://code.engineering.redhat.com/gerrit/#/c/15349/

fixes the issue.
Comment 6 Lalatendu Mohanty 2013-11-08 05:05:03 EST
Verified on glusterfs-server-3.4.0.40rhs-1.el6rhs.x86_64 and samba-3.6.9-160.7. Not seeing the issue any-more.


rpm -qa | grep 'glusterfs\|samba'
samba-common-3.6.9-160.7.el6rhs.x86_64
glusterfs-geo-replication-3.4.0.40rhs-1.el6rhs.x86_64
samba-winbind-devel-3.6.9-160.7.el6rhs.x86_64
glusterfs-server-3.4.0.40rhs-1.el6rhs.x86_64
glusterfs-libs-3.4.0.40rhs-1.el6rhs.x86_64
samba-winbind-clients-3.6.9-160.7.el6rhs.x86_64
samba-winbind-3.6.9-160.7.el6rhs.x86_64
samba-3.6.9-160.7.el6rhs.x86_64
samba-client-3.6.9-160.7.el6rhs.x86_64
glusterfs-fuse-3.4.0.40rhs-1.el6rhs.x86_64
samba-winbind-krb5-locator-3.6.9-160.7.el6rhs.x86_64
samba-domainjoin-gui-3.6.9-160.7.el6rhs.x86_64
samba-glusterfs-3.6.9-160.7.el6rhs.x86_64
glusterfs-rdma-3.4.0.40rhs-1.el6rhs.x86_64
samba4-libs-4.0.0-55.el6.rc4.x86_64
glusterfs-api-3.4.0.40rhs-1.el6rhs.x86_64
glusterfs-3.4.0.40rhs-1.el6rhs.x86_64
samba-swat-3.6.9-160.7.el6rhs.x86_64
samba-doc-3.6.9-160.7.el6rhs.x86_64
Comment 8 errata-xmlrpc 2013-11-27 10:46:39 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1769.html

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