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.
Still relevant?
I'm adding Jiffin from NFS, he would be the better person to answer this. @Jiffin, Please do the needful.
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