Description of problem: As non root user rename of directory is not getting allowed There are two scenarios here, 1. when the directory inside mount-point, say "dir" is given non-root user(say qa1) permissions, is tried to be renamed fails with "Permission Denied". 2. when the sub-directory(say subdir) inside the above created "dir" exists, Also the "dir" quota space is full and we try rename the subdir, after increasing the quota limit for "dir". rename fails with "Disk quota exceeded" Given the fact that I am logged in as qa1(non-root user). These issues are seen with both nfs and glusterfs mount. Version-Release number of selected component (if applicable): glusterfs-3.4.0.40rhs-1 How reproducible: always Steps to Reproduce: 1. have volume of 6x2 config, enable quota and set limit 2. mount over nfs or glusterfs 3. create a dir, chown the dir to a non-root user. 4. set some limit on the dir 5. create a subdir inside the dir, fill data in the subdir, till limit is reached. 6. now increase the quota limit for dir to a higher value. 7. try to rename dir 8. try to rename dir/subdir execute steps 5, 7, 8 after logged into system as non-root user. Actual results: [qa1@rhslong03 nfs-test-dist-rep1]$ mount | grep nfs-test-dist-rep1 10.70.35.188:dist-rep1 on /mnt/nfs-test-dist-rep1 type nfs (rw,addr=10.70.35.188) first scenario, [qa1@rhslong03 nfs-test-dist-rep1]$ ls -ld qa1-rename/ drwxr-xr-x. 3 qa1 qa 96 Nov 6 17:07 qa1-rename/ [qa1@rhslong03 nfs-test-dist-rep1]$ mv qa1-rename/ qa1 mv: cannot move `qa1-rename/' to `qa1': Permission denied second scenario, [qa1@rhslong03 qa1-rename]$ pwd /mnt/nfs-test-dist-rep1/qa1-rename [qa1@rhslong03 qa1-rename]$ ls -ld dir drwxr-xr-x. 2 qa1 qa 49152 Nov 8 19:32 dir [qa1@rhslong03 qa1-rename]$ mv dir dir-rename mv: cannot move `dir' to `dir-rename': Disk quota exceeded whereas if you see I have lot of space left, [root@quota5 ~]# gluster volume quota dist-rep1 list Path Hard-limit Soft-limit Used Available -------------------------------------------------------------------------------- / 1.0TB 80% 377.4GB 646.6GB /qa1-rename 300.0GB 80% 224.1GB 75.9GB Expected results: rename in these cases should be allowed Additional info: Volume Name: dist-rep1 Type: Distributed-Replicate Volume ID: be61bc6e-3140-468b-899d-430c1935441d Status: Started Number of Bricks: 6 x 2 = 12 Transport-type: tcp Bricks: Brick1: 10.70.35.188:/rhs/brick2/d1r11 Brick2: 10.70.35.108:/rhs/brick2/d1r21 Brick3: 10.70.35.191:/rhs/brick2/d2r11 Brick4: 10.70.35.144:/rhs/brick2/d2r21 Brick5: 10.70.35.188:/rhs/brick2/d3r11 Brick6: 10.70.35.108:/rhs/brick2/d3r21 Brick7: 10.70.35.191:/rhs/brick2/d4r11 Brick8: 10.70.35.144:/rhs/brick2/d4r21 Brick9: 10.70.35.188:/rhs/brick2/d5r11 Brick10: 10.70.35.108:/rhs/brick2/d5r21 Brick11: 10.70.35.191:/rhs/brick2/d6r11 Brick12: 10.70.35.144:/rhs/brick2/d6r21 Options Reconfigured: features.quota: on features.quota-deem-statfs: on
It is happening even without in quota in consideration [root@rhslong03 nfs-test-dist-rep1]# mkdir dir6 [root@rhslong03 nfs-test-dist-rep1]# chwon qa1:qa dir6 bash: chwon: command not found [root@rhslong03 nfs-test-dist-rep1]# chown qa1:qa dir6 [root@rhslong03 nfs-test-dist-rep1]# ls -l dir6 total 0 [root@rhslong03 nfs-test-dist-rep1]# ls -ld dir6 drwxr-xr-x. 2 qa1 qa 36 Nov 8 2013 dir6 [root@rhslong03 nfs-test-dist-rep1]# [root@rhslong03 nfs-test-dist-rep1]# su qa1 [qa1@rhslong03 nfs-test-dist-rep1]$ mv dir6 dir6-rename
as per discussion with developer, here are the observations, glusterfs-nfs mount-point permissions, [root@rhsauto005 ~]# ls -ld /mnt/nfs-test-213/ drwxr-xr-x. 14 root root 49152 Nov 12 03:45 /mnt/nfs-test-213/ kernel-nfs mount-point permissions, [root@rhsauto005 ~]# ls -ld /opt drwxrwxrwx. 6 root root 4096 Nov 12 06:27 /opt rename operations on kernel-nfs mount-point, directory in consideration is "dir" [qa1@rhsauto005 nfs-test-213]$ ls -l /opt total 16 drwxr-xr-x. 2 qa1 qa1 4096 Nov 12 06:26 dir drwxrwxrwx. 5 1000 1000 4096 May 25 2012 qa drwxr-xr-x. 2 test test 4096 Nov 8 08:38 qa1 drwxr-xr-x. 2 root root 4096 Jun 21 04:05 rh [qa1@rhsauto005 nfs-test-213]$ mv /opt/dir /opt/dir-rename [qa1@rhsauto005 nfs-test-213]$ ls -l /opt total 16 drwxr-xr-x. 2 qa1 qa1 4096 Nov 12 06:26 dir-rename drwxrwxrwx. 5 1000 1000 4096 May 25 2012 qa drwxr-xr-x. 2 test test 4096 Nov 8 08:38 qa1 drwxr-xr-x. 2 root root 4096 Jun 21 04:05 rh
Couple of basic questions: 1. Does it happen only when Quota is enabled or without quota as well? 2. What is the behaviour with native/FUSE mount? i.e. Does the issue only seen in Gluster NFS?
(In reply to Susant Kumar Palai from comment #4) > Currently the glusterfs root inode is getting the permission 755. Hence, > from as the non root user doesn't have write permission on the directory > created by root, it will not be able to rename this directory ( EPERM > ERROR) even though it is made owner of that directory, which is an obvious > behaviour . When the non-root user is made owner, it got the write permission (in user-group-other sequence), so rename() should not FAIL ideally. If the issue is consistent with FUSE, then mostly the problem is in DHT or so. By the way, what does log say?
(In reply to santosh pradhan from comment #6) > Couple of basic questions: > > 1. Does it happen only when Quota is enabled or without quota as well? > > 2. What is the behaviour with native/FUSE mount? i.e. Does the issue only > seen in Gluster NFS? It happens even with quota disabled. And the the behaviour is same for native/FUSE mount as well.
modifying my 1st comment as there was a typo. Currently the glusterfs root inode is getting the permission 755. Hence, as the non root user doesn't have write permission on parent of the directory which is root ('/'), it will not be able to rename this directory ( EPERM ERROR) even though it is made owner of that directory, which is an obvious behaviour . But it can do all the operations inside that directory. I checked with samba and the behaviour is same as glusterfs mount . The exception is kernel nfs, where its root inode is getting 777 permission and hence, the rename operation is feasible there (as any non root user will inherit the write permission). So as of now the above behaviour is a obvious one from Glusterfs point of view.
Thanks to Santoch and Rajesh for providing there inputs. So, presently as per the trials we did for mount of different directories, it is found that kernel-nfs mount exports the same permissions as they are found for the "directory in consideration" on the server node. Whereas for Glusterfs volume mount, we still are doing a mount with permissions as 755. Also, for a subdirectory mount in a glusterfs volume also behaves the same as mentioned for kernel-nfs mount.
mount command/protocol(NFS) just fetches the permissions set at the backend directory and modify the same for mount point at client end. Does not do anything more than that. :) Difference between Gluster NFS/FUSE and Kernel NFS: For Gluster, volume is not just a single directory but a set of directories distributed across the bunch of the machines (called as bricks). If the client wants a mount with 777 permission, there can be workaround(s): 1) all the directories in all the bricks has to be chmod'd to 777 and restart the Gluster daemons. :) OR 2) Create a subdir with 777 permission and mount it. Why volume gets exported with 755 permission: As its a distributed arch, the directory has to be created in all the brick m/cs, and mkdir() considers umask() while creating directory. Permission ll be set accordingly. Having said all these, This does not look like a DEFECT. Can we close it ? :)
based on comment#10 and comment#11 closing this issue