From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Description of problem: I have just installed RHEL ES V4 on a Dell Poweredge 2650. NIS authentication. Home directories are mounted via NFS from a RHEL. I have also mounted another filesystem via NFS to /data. It is exported from a Novell NetWare 6.0 fileserver. The problem is that some programs cannot save or create files in the folders mounted from the NetWare server. Examples of programs that cannot save files are gedit and kedit. gedit returns a message saying that the file could not be saved. kedit returns a message saying that it could not create a backup file. I also have some proprietary programs that return similar errors, that they can't create files that need to be created. Here are the gotchas: Gotcha 1: gedit, kedit, etc are able to save, create, or overwrite files in my NFS mounted home directory. No problems. Normal behavior. Gotcha 2: Other programs are able to save, create, and overwrite files in folders on the NFS mounted NetWare volume. Examples are vi, emacs, touch, and other propietary programs. I'm also able to cp, mv, and rm files in the same folders. Gotcha 3: I have an RHEL ES v3 server on an identical Dell Poweredge 2650. I have mounted the same NFS exports using the exact same options to the same exact mount points with the same exact permisions and I don't have any problems. I can access, modify, create, and save any file at will with any program. gedit and kedit work fine. This server has been running for 18 months without any problems with NFS mounted filesystems. The export from the NetWare server has worked fine during the same 18 months. Version-Release number of selected component (if applicable): nfs-utils-1.0.6-65.EL4 How reproducible: Always Steps to Reproduce: 1.Export a volume as an NFS share from a NetWare 6.0 fileserver. 2.Create a mount point on a RHEL ES V4 server. 3.mount -t nfs -o wsize=16384,rsize=16384,timeo=14,intr,udp,nolock server:/data /mountpoint Actual Results: Could not save files with gedit or kedit in any folders mounted from the NetWare 6.0 fileserver. Expected Results: I should've been able to save or create files with gedit and kedit. My proprietary programs should've been able to create files too. Additional info: A filesystem note. The RHEL V4 server that is having problems IS using LVM. The RHEL V3 server that doesn't have problems is NOT using LVM. Also, when first trying to diagnose the problem I was not specifying to use udp as the protocol. After specifying that the protocol should be udp some programs started working. However, there was no change in the behavior of gedit or kedit. And, some of my other programs still can't create files. If this can't be resolved I won't be able to upgrade to version 4 of RHEL. I will have to stay with version 3. Bummer.
I've done a little more snooping with strace. I ran strace on gedit and tried to save a file on NFS mounted filesystem. I also ran a program from our interviewing software (we conduct telephone surveys). They both failed with the same open command. What they have in common is that the both use the access mode O_EXCL when they try to create a file. In that the NFS mount is exported from a Novelll Netware 6.0 server, which doesn't support file locking, I use the following entry in fstab on my RHEL box: 10.0.4.242:/data /kdata nfs wsize=8192,rsize=8192,timeo=14,intr,nolock 0 0 This works fine with RHEL3 update 6 using nfs-utils-1.0.6-42. It seems to me that something is up with file locking, specifically, that the nolock mount option is being ignored or implemented incorrectly. However, I don't think the issue resides in nfs-utils. I've uninstalled nfs-utils-1.0.7 from a Fedora Core 4 box that is having the same issue and installed version 1.0.6-42. No change: strace reveals that file opening is failing when specified with the O_EXCL mode access specifier. Could it be the 2.6 kernel? I hope you can shed some light on this.
More testing: I wrote a small C program to see if I get the same result and I did. The program tries to create a file in a directory on an NFS mount and then write "Hello World!\n". Compiled it on a Fedora Core 4 box. I tried to open a file with this command: open("myfile.txt", O_RDWR|O_CREAT|O_EXCL, 0666); Using strace shows that I get the same results: open("myfile.txt", O_RDWR|O_CREAT|O_EXCL, 0666) = -1 ENOTSUPP (Unknown error 524) I verified that the file doesn't already exist. Both gedit and other console programs I run use the same access mode specifiers and fail with the same error message when trying to create the file on the NFS mount that is exported from NetWare. I then switched over to RHEL3 ES Update 6, same NFS mount from Netware, same program. I recompiled the program and it ran without errors.
Could you please post a bzip2 binary tethereal trace of this problem. Meaning on the client run: tethereal -w /tmp/data.pcap host <server> bzip2 /tmp/data.pcap. To insure you have captured some NFS traffic, Before bzip2-ing the file, you can look at the binary data by either doing a 'tethereal -R nfs -r /tmp/data.pcap' or 'ethereal -r /tmp/data.pcap' (although ethereal is not installed by default).... Also, for testing purposes, could you also post your hello world program....
Created attachment 123259 [details] tethereal capture of NFS v2 traffic Here is capture data of how I have currently configured NFS. I don't get errors this way. The file with NFS version 3 traffic has the data with errors.
Created attachment 123260 [details] tethereal capture of NFS v3 traffic This tethereal capture data contains the traffic data when errors occur trying to create files.
I did two captures using the following nfs mount options in /etc/fstab: nfsvers=2,rsize=16384,wsize=16384,timeo=14,intr,nolock 0 0 nfsvers=3,rsize=16384,wsize=16384,timeo=14,intr,nolock 0 0 The only difference is the nfsvers option. When I use nfsvers=2 I don't get errors trying to create files. When I use nfsvers=3 I get error 524 when programs try to create files. I'll attach the c++ code for the small program I wrote to duplicate the error.
Created attachment 123261 [details] C++ Source file for test program. All this program does is try to create a file named "binary" and then write the string "Hello World!" to it. The O_EXCL mode is what causes file creations to fail when using NFS V3. I have read that the O_EXCL mode flag doesn't work over NFS, but it appears that NFS V2 at least ignores it.
The problem is that NetWare server does not support a particular type of creates that v3 defaults to. But, there is code in the more recent kernels to handle this problem. Which kernel version are you using and would it be possible to update to U3 or beyond kernel?
This bug is pretty old and it is not clear whether this is still a bug or not. The client code appears to have some code which should recover from the server not handling NFS3_CREATE_EXCLUSIVE semantics by retrying with NFS3_CREATE_GUARDED instead. Also, I don't have access to this NetWare server. If this is still a problem with recent kernels, then please reopen this bugzilla and I will look at it then.