Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 990220 - Group permission with high GID Number (200090480) is not being honored by Gluster
Summary: Group permission with high GID Number (200090480) is not being honored by Glu...
Alias: None
Product: GlusterFS
Classification: Community
Component: fuse
Version: 3.3.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-30 15:23 UTC by Rob
Modified: 2015-05-26 12:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-14 19:40:31 UTC
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:

Attachments (Terms of Use)

Description Rob 2013-07-30 15:23:40 UTC
Description of problem:

Gluster mounted storage do not honor group permissions.
A directory is set to be writable (770) by group berglab (with gid: 200090480).
Members belonging to the group cannot write to it.

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

How reproducible:

Steps to Reproduce:
1. Create a group, say berglab, with high GID Number: 200090480
2. chgrp 770 berglab; make a user, say berguser, belong to berglab
3. su - berguser and then touch ./berglab/t (will get permission denied) 

Actual results:
Permission denied

Expected results:

Additional info:

I suspect this has something to do with the high GID number of the group assigned.

Comment 1 Harshavardhana 2013-08-13 03:09:09 UTC
Tested it on GlusterFS release 3.4.0 - works perfectly - can you test that and let us know?

[root@sysrq gfs]# id test_user
uid=501(test_user) gid=200090480(test_group) groups=200090480(test_group)
[root@sysrq gfs]# su - test_user^C
[root@sysrq gfs]# ls
[root@sysrq gfs]# mkdir test
[root@sysrq gfs]# chown -R test_user:test_group test
[root@sysrq gfs]# ls -ltr
total 4
drwxr-xr-x. 2 test_user test_group 4096 Aug 13 00:09 test
[root@sysrq gfs]# stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 131072 directory
Device: 1fh/31d Inode: 13491293104798782419  Links: 2
Access: (0755/drwxr-xr-x)  Uid: (  501/test_user)   Gid: (200090480/test_group)
Access: 2013-08-13 00:09:39.274356636 -0700
Modify: 2013-08-13 00:09:32.643356000 -0700
Change: 2013-08-13 00:09:39.232356638 -0700
[root@sysrq gfs]# ls
[root@sysrq gfs]# su - test_user
[test_user@sysrq ~]$ cd /mnt/gfs/test/
[test_user@sysrq test]$ ls
[test_user@sysrq test]$ touch a
[test_user@sysrq test]$ rm a
[test_user@sysrq test]$ 
[test_user@sysrq test]$ pwd
[test_user@sysrq test]$ df -h .
Filesystem            Size  Used Avail Use% Mounted on
localhost:/gfs         50G  6.8G   41G  15% /mnt/gfs
[test_user@sysrq test]$ 
[test_user@sysrq test]$ mount | grep gfs
localhost:/gfs on /mnt/gfs type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

Comment 2 Rob 2013-08-13 13:38:03 UTC

Unfortunately, the NFS crash bug (
) I reported earlier prevents us to use Gluster 3.4.0.


Comment 3 Harshavardhana 2013-08-13 16:35:49 UTC
Are you saying that bug is reproduced in GlusterFS 3.4.0? - That bug is only for 3.3 branch - i haven't seen it for GlusterFS 3.4.x

Comment 4 krishnan parthasarathi 2014-07-16 10:48:08 UTC

Are you seeing this issue still in GlusterFS 3.5.1? Are you seeing it on a NFS mount point?

Comment 5 Niels de Vos 2014-11-27 14:54:31 UTC
The version that this bug has been reported against, does not get any updates from the Gluster Community anymore. Please verify if this report is still valid against a current (3.4, 3.5 or 3.6) release and update the version, or close this bug.

If there has been no update before 9 December 2014, this bug will get automatocally closed.

Comment 6 Niels de Vos 2015-05-26 12:33:32 UTC
This bug has been CLOSED, and there has not been a response to the requested NEEDINFO in more than 4 weeks. The NEEDINFO flag is now getting cleared so that our Bugzilla household is getting more in order.

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