Bug 1292771 - NFS Ganesha write access and WORM disk issues with Win7 Enterprise
Summary: NFS Ganesha write access and WORM disk issues with Win7 Enterprise
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: ganesha-nfs
Version: 3.7.1
Hardware: All
OS: All
medium
high
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-18 10:12 UTC by florent.delvaille
Modified: 2023-09-14 03:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-08 10:49:21 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


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

Description florent.delvaille 2015-12-18 10:12:39 UTC
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 10:21:21 UTC
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 11:45:41 UTC
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 13:13:59 UTC
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 10:49:21 UTC
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.

Comment 5 Red Hat Bugzilla 2023-09-14 03:15:02 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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