Bug 1292771 - NFS Ganesha write access and WORM disk issues with Win7 Enterprise [NEEDINFO]
NFS Ganesha write access and WORM disk issues with Win7 Enterprise
Status: CLOSED EOL
Product: GlusterFS
Classification: Community
Component: ganesha-nfs (Show other bugs)
3.7.1
All All
medium Severity high
: ---
: ---
Assigned To: bugs@gluster.org
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-18 05:12 EST by florent.delvaille
Modified: 2017-03-08 05:49 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-08 05:49:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ndevos: needinfo? (florent.delvaille)


Attachments (Terms of Use)
ganesha logs + tcpdump (397.49 KB, application/zip)
2015-12-18 05:12 EST, florent.delvaille
no flags Details

  None (edit)
Description florent.delvaille 2015-12-18 05:12:39 EST
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
Comment 1 florent.delvaille 2015-12-18 05:21:21 EST
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;
Comment 2 Soumya Koduri 2015-12-18 06:45:41 EST
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!
Comment 3 Niels de Vos 2015-12-18 08:13:59 EST
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!
Comment 4 Kaushal 2017-03-08 05:49:21 EST
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.

Note You need to log in before you can comment on or make changes to this bug.