Description of problem: Changing ACLs for directories sometimes gives "Access denied error", though the subsequent try is getting succeeded. When I get the error "Access denied" error, I can see below errors "Unknown gluster ACL version" in /var/log/messages Sep 2 16:24:35 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 1378119080 Sep 2 16:24:35 bvt-rhs1 smbd[7488]: [2013/09/02 16:24:35.104201, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:24:35 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: -459553296 Sep 2 16:24:35 bvt-rhs1 smbd[7488]: [2013/09/02 16:24:35.118681, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:24:35 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 10513 Sep 2 16:24:35 bvt-rhs1 smbd[7488]: [2013/09/02 16:24:35.151454, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:24:35 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 82 Sep 2 16:24:35 bvt-rhs1 smbd[7488]: [2013/09/02 16:24:35.172190, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:24:35 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 82 Sep 2 16:24:55 bvt-rhs1 smbd[7531]: [2013/09/02 16:24:55.207801, 0] modules/vfs_glusterfs.c:576(vfs_gluster_stat) Sep 2 16:24:55 bvt-rhs1 smbd[7531]: glfs_stat(./..) failed: No data available Sep 2 16:33:29 bvt-rhs1 smbd[7531]: [2013/09/02 16:33:29.531821, 0] modules/vfs_glusterfs.c:576(vfs_gluster_stat) Sep 2 16:33:29 bvt-rhs1 smbd[7531]: glfs_stat(./..) failed: No data available Sep 2 16:34:42 bvt-rhs1 smbd[7488]: [2013/09/02 16:34:42.596340, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:34:42 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 1378119823 Sep 2 16:34:42 bvt-rhs1 smbd[7488]: [2013/09/02 16:34:42.606279, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:34:42 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: -460631184 Sep 2 16:34:42 bvt-rhs1 smbd[7488]: [2013/09/02 16:34:42.618727, 0] modules/vfs_glusterfs.c:1041(gluster_to_smb_acl) Sep 2 16:34:42 bvt-rhs1 smbd[7488]: Unknown gluster ACL version: 10513 Version-Release number of selected component (if applicable): glusterfs-server-3.4.0.30rhs-2.el6rhs.x86_64 [root@bvt-rhs1 core]# rpm -qa | grep samba samba-common-3.6.9-160.3.el6rhs.x86_64 samba-swat-3.6.9-160.3.el6rhs.x86_64 samba-doc-3.6.9-160.3.el6rhs.x86_64 samba-winbind-clients-3.6.9-160.3.el6rhs.x86_64 samba-3.6.9-160.3.el6rhs.x86_64 samba-glusterfs-3.6.9-160.3.el6rhs.x86_64 samba-domainjoin-gui-3.6.9-160.3.el6rhs.x86_64 samba-winbind-devel-3.6.9-160.3.el6rhs.x86_64 samba-debuginfo-3.6.9-160.3.el6rhs.x86_64 samba4-libs-4.0.0-55.el6.rc4.x86_64 samba-winbind-3.6.9-160.3.el6rhs.x86_64 samba-client-3.6.9-160.3.el6rhs.x86_64 samba-winbind-krb5-locator-3.6.9-160.3.el6rhs.x86_64 How reproducible: Intermittently Steps to Reproduce: 1. As "user1" form windows mount point, create a folder and create some files (xlsx files) 2. Give acls (for write, read, execute) for User2 on these files 3. Also give acl for full control to user2. 4. Now edit the file and add some content. 5. Again on the parent try to remove permission for user2. Actual results: on Step-5 while changing ACLs for folder gives "Access denied error" error, however if you click "continue" button, the acls get set. Expected results: It should not give access denied error Additional info: I have checked the vfs log file, samba log files but don't have anything suspicious there
Correcting steps to reproduce Steps to Reproduce: 1. As "user1" form windows mount point, create a folder and create some files (xlsx files) 2. Give acls (for write, read, execute) for User2 on these files 3. On the parent folder, also give acl for full control to user2. 4. as User2, edit one the file and add some content. 5. As User1, on the parent folder, try to remove permission for user2.
I have raised the priority to high because, the bug brings down the user experience heavily and creates confusion. IMHO this bug should be treated with urgent priority.
I could reproduce the same issue on XFS partition exported over samba. It looks like a samba issue. The behaviour is pretty inconsistent. I don't get the error always but once the error comes, sometimes continue sets the acls, sometimes not.
Also "service smb restart" on the samba server does not fix the issue.
Lala, does this bug reproduce with vfs_acl_xattr?
Ira, I think, I have not tried the test with "vfs_acl_xattr". Now after reading "steps to reproduce", I think it might be a "not a bug", because after changing ownership of a file to user2, can user1 remove acls of user2?
Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/ If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.