Created attachment 1107070 [details] ganesha logs + tcpdump Description of problem: Gluster share created, access with nfs.ganesha. Share has 777 access. NFS writes is working fine from a Linux server. NFS read is working fine from a Windows 7 Enterprise server. NFS write is working to create empty directory/file. NFS write is not working (complaining the FS is ReadOnly) when adding data or renaming. Version-Release number of selected component (if applicable): [root@lpr-nas03 log]# rpm -qa | grep ganesha nfs-ganesha-gluster-2.2.0-9.el7rhgs.x86_64 glusterfs-ganesha-3.7.1-16.el7rhgs.x86_64 nfs-ganesha-2.2.0-9.el7rhgs.x86_64 How reproducible: Every time I try Steps to Reproduce: 1. Create glusterfs share with nfs-ganesha enabled 2. Access the nfs share from Win7 Enteprise server 3. Create directory/file and provide another name than the default one Actual results: Read only file system Expected results: Should create the directory/file Additional info: # tcpdump -i eno16780032 -n tcp dst port 2049 Tried to create file, then folder with default name, then folder with specific name
Ok so, the share having this issue is a WORM share. When disabling the WORM, it's working right the way, without issue. So it seems to be specificly related to this feature. Regards;
IIUC, the test being done internally maps to * Create a dir/file with default name * Rename it to a different name. Since this test fails with only WORM feature on, looks like once a file/dir is being created, any further WRITE* based operations including SETATTR/UNLINK on that dir/file gets failed by the Gluster Server, which I think is valid behaviour as server should not allow any later modifications to the file as per WORM feature norms. Could you please capture the pkt trace on the machine where nfs-ganesha server is running using the below cmd, re-run the test and attach the pkt trace in the bug. #tcpdump -i any -s 0 -w /var/tmp/nfs-server.pcap tcp and not port 22 Would like to see the Gluster Operations being performed/failed. Thanks!
This command only captured the calls that the NFS-client made: # tcpdump -i eno16780032 -n tcp dst port 2049 Unfortunately the capture does not have the replies from the NFS-server, which would contain an error message of some kind, at one point. The tcpdump command from comment #2 should work, but you can also use this: # tcpdump -i eno16780032 -s 0 -w /var/tmp/nfs-server.pcap tcp and port 2049 Thanks!
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days