Red Hat Bugzilla – Bug 187370
Unable to mount NFS V3 share where sec=none is specified
Last modified: 2007-11-30 17:07:24 EST
Description of problem: unable to mount NFS V3 share from Solaris when sec=none is used. Version-Release number of selected component (if applicable): nfs-utils-1.0.6-65.EL4 How reproducible: always Steps to Reproduce: 1. create a share with following entry in /etc/dfs/dfstab share -F nfs -o sec=none,rw,anon=5021 /path/to/share 2. issue a mount command from RHEL mount server:/path/to/share /mnt Actual results: mount: server:/path/to/share failed, security flavor not supported Expected results: no errors. Additional info: mount -o nfsvers=2 server:/path/to/share /mnt works. Attached is snoop output of the mount process.
Created attachment 127057 [details] snoop output of the mount process
Could the raw snoop capture file be attached, please? That would be much more helpful than just the terse output.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This does not appear to be a bug. The NFSv3 client does not support AUTH_NONE as a valid authentication flavor. In this case, the server is returning AUTH_NONE as the only valid authentication flavor. Since the client does not support it, an error is generated. The NFSv2 case appears to work because it causes the file system to be mounted. It does not know that the server has specified that AUTH_NONE should be used. However, it generates AUTH_SYS over the wire, which the server appears to honor. If anything this is a bug in the Solaris NFS server because it does not seem to be respecting the security flavor specified by the share command. Without some more information, I will need to close this report as NOTABUG.
what is the command for raw snoop or tcpdump capture?
There are several commands which can be used, but -- On the Solaris server, use the snoop(1M) command: snoop -o /tmp/snoop.cap host <name_of_client> and then attach //tmp/snoop.cap to this bugzilla.
I was using tcpdump -w and did ls /net/solarishost/exported/folder
Created attachment 137650 [details] tcpdump -w nfsv3.cap
Perhaps I am not explaining what I need clearly enough. The capture file which was previously attached is not useful because 1) it only captured 3 packets and 2) those packets were truncated. If tcpdump is to be used, then the option, "-s 0" must be used in order to capture the entire packet. I suggested using snoop(1M) from the server because I knew that snoop does not require any special flags to capture the entire packet. Neither does tethereal from Linux. After performing the capture, please examine the capture file using either ethereal or wireshark, whichever you've got, to be sure that it contains whole packets and all of the packets, including at least MOUNT protocol traffic and any NFS traffic, if there is any.
console 1: tcpdump -s 0 -w /tmp/nfsv3.cap host hostname tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 30 packets captured 73 packets received by filter 0 packets dropped by kernel console 2: mount hostname:/share /mnt mount: hostname:/share failed, security flavor not supported
Created attachment 137768 [details] "tcpdump -s 0 -w /tmp/nfsv3.cap host hostname" while running mount command
Thanx! That is the the capture that I was looking for. This is as I described earlier. The Solaris NFS server returns only AUTH_NONE in the list of supported authentication flavors. The Linux NFSv3 client does not support AUTH_NONE, so fails the mount. What is the purpose of exporting the file system from the server using only AUTH_NONE?
My understanding is that it forces specified UID on all files created regardless which user created them. There is a deamon runing as UID and it must have write access to files created on the share. share -F nfs -o sec=none,rw,anon=UID /path/to/share sec=none If the option sec=none is specified when the client uses AUTH_NONE, or if the client uses a security mode that is not one that the file system is shared with, then the credential of each NFS request is treated as unauthenticated. See the anon=uid option for a description of how unauthenticated requests are handled. anon=uid Set uid to be the effective user ID of unknown users. By default, unknown users are given the effective user ID UID_NOBODY. If uid is set to -1, access is denied. Similar to a force_user directive in smb.conf: force_user (S) This specifies a UNIX user name that will be assigned as the default user for all users connecting to this service. This is useful for sharing files.
Okay. Thanx for the information from the Solaris man pages. It does seem like the Linux NFS client could/should support AUTH_NONE in much the same fashion as does Solaris.
Created attachment 138345 [details] Proposed patch
The attached patch modifies the mount process on the client to use the currently specified authentication flavor if the server has exported the file system to AUTH_NONE.
Fixed in util-linux-2.12a-16.EL4.22
This fix is available in the latest RHEL-4.5 Beta. If the customer is in a position to test the beta, please ask for testing feedback. Thanks.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0235.html