Bug 1193174

Summary: flock does not observe group membership
Product: [Community] GlusterFS Reporter: Chris Good <chris.good>
Component: nfsAssignee: hari gowtham <hgowtham>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: mainlineCC: bugs, chris.good, hgowtham, jthottan, mark.hagger, ndevos
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1211787 1369445 (view as bug list) Environment:
Last Closed: 2020-03-12 12:36:56 UTC Type: Bug
Regression: --- Mount Type: nfs
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1211787, 1369445, 1369446    

Description Chris Good 2015-02-16 18:33:15 UTC
Description of problem:

flock works correctly when the locking user either owns or has group ownership of the file however if fails with a ENOLCK if the lockfile is only accessible through non-primary group membership.

For instance:

[grapeshot@admin03]$ls -l locktest2
-rw-rw-r--  1 apache    apache       0 Feb 16 17:31 locktest.lock

The lockfile is owned by apache, the test user is a member of the apache group:

[grapeshot@admin03]$ id
uid=500(grapeshot) gid=500(grapeshot) groups=500(grapeshot),48(apache)

Confirming that we have write access:
[grapeshot@admin03]$ touch locktest.lock 
[grapeshot@admin03]$ 

Therefore flock against that file should succeed, the simple test case being:

[grapeshot@admin03]$ flock -e 200  200>locktest.lock 
flock: 200: No locks available


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


How reproducible:

Always fails when FS is mounted using the gluster built-in NFS.  With the same FS mounted instead using gluster-fuse it always succeeds.



Steps to Reproduce:
1. 
2.
3.

Actual results:


Expected results:


Additional info:

Volume Name: homegrapeshot
Type: Replicate
Volume ID: ced82a52-ae78-4225-919d-700987163888
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: admin-db01:/data/glusterfs/homegrapeshot/brick1/brick
Brick2: admin-db02:/data/glusterfs/homegrapeshot/brick1/brick
Options Reconfigured:
cluster.lookup-unhashed: off


Looking on the gluster servers we see the following errors:

2015-02-16 18:20:58.676592] E [client-rpc-fops.c:449:client3_3_open_cbk] 0-homegrapeshot-client-0: remote operation failed: Permission denied. Path: /Lodestone/marktest2/locktest.lock (b9de87e6-b500-417a-a064-e8075dde7082)
[2015-02-16 18:20:58.676768] E [client-rpc-fops.c:449:client3_3_open_cbk] 0-homegrapeshot-client-1: remote operation failed: Permission denied. Path: /Lodestone/marktest2/locktest.lock (b9de87e6-b500-417a-a064-e8075dde7082)
[2015-02-16 18:20:58.676878] E [nlm4.c:1347:nlm4_lock_fd_resume] 0-nfs-NLM: Unable to resolve FH: (10.8.8.60:690) homegrapeshot : b9de87e6-b500-417a-a064-e8075dde7082
[2015-02-16 18:20:58.676909] E [nlm4.c:1370:nlm4_lock_fd_resume] 0-nfs-NLM: unable to call lk()

The group membership on the gluster servers matches the client machine definitions.

Comment 2 Yaniv Kaul 2019-04-28 05:21:29 UTC
Still relevant?

Comment 3 hari gowtham 2019-04-29 06:51:38 UTC
I'm adding Jiffin from NFS, he would be the better person to answer this.

@Jiffin, Please do the needful.

Comment 4 Worker Ant 2020-03-12 12:36:56 UTC
This bug is moved to https://github.com/gluster/glusterfs/issues/911, and will be tracked there from now on. Visit GitHub issues URL for further details