Description of problem: Tried to rename a file from a windows nfs client, earlier created from a nfs mount on a RHEL client. It created one more new file with the new name. whereas kernel-nfs refused to rename. Version-Release number of selected component (if applicable): [root@rhsauto032 ~]# rpm -qa | grep glusterfs glusterfs-api-3.4.0.17rhs-1.el6rhs.x86_64 glusterfs-3.4.0.17rhs-1.el6rhs.x86_64 glusterfs-geo-replication-3.4.0.17rhs-1.el6rhs.x86_64 glusterfs-libs-3.4.0.17rhs-1.el6rhs.x86_64 samba-glusterfs-3.6.9-156.2.el6rhs.x86_64 glusterfs-fuse-3.4.0.17rhs-1.el6rhs.x86_64 glusterfs-server-3.4.0.17rhs-1.el6rhs.x86_64 glusterfs-rdma-3.4.0.17rhs-1.el6rhs.x86_64 How reproducible: always Steps to Reproduce: 1. mount the volume over RHEL client using nfs, 2. create a volume -rw-r--r--. 2 root root 0 Aug 14 06:51 c 3. mount the volume over windows using nfs 4. try renaming file "c" from windows nfs client, -rw-r--r--. 2 root root 0 Aug 14 06:51 c -rw-r--r--. 2 root root 0 Aug 14 06:51 c-rename Actual results: a new file is created with root credentials also if I write something in the file "c", gets reflected in file "c-rename". Expected results: whereas once you try to create a new file in the mountpoint it fails because of permission issues to nfs client on windows. Also, kernel don't even allow the rename to succeed. Additional info:
Looks like specific behaviour of Windows NFS. I do not believe we can fix that on the NFS-server side.