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):
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
issue a mount command from RHEL
mount server:/path/to/share /mnt
mount: server:/path/to/share failed, security flavor not supported
mount -o nfsvers=2 server:/path/to/share /mnt
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
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
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
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.
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
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
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
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.
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:
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]
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.