SUMMARY: Problems with 2.4 NFS

From: Mark Sturtevant (sturt@winternet.com)
Date: Mon Mar 04 1996 - 09:22:57 CST


Thanks to all who responded:

Dave Haut <dave@endeavour.exar.com>
stern@sunrise.East.Sun.COM (Hal Stern - Distinguished Systems Engineer)
keith@oz.health.state.mn.us (Keith M Willenson)
"Michael S. Fischer" <mfischer@nsi.edu>
"Rachel Polanskis" <grove@zeta.org.au>
kwthomas@wizard.nssl.uoknor.edu (Kevin W. Thomas)
albert@esther.rad.tju.edu (Dr. Micheal Albert)
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})

The problem did turn out to be a hostname problem, Solaris was looking at
the qualified DNS entry and using that, thanks to a wonderful person at
Sun I used the following command to find it out, "getent", with this
command I was able to see what the server was using as the hostname, I
shared the filesystem with the fully qualified name and it worked.

getent's syntax:

getent database [ key ... ]

This command actually follow's the /etc/nsswitch.conf file to get it's info.

Thanks again for everyone's help,

Mark Sturtevant

===========================================================================
Mark Sturtevant <sturt@winternet.com>
Unix Systems Administrator
P A R A N E T
===========================================================================

------ My Original Question:

Hey Everyone,

I have ran into a strange problem with NFS on Solaris 2.4. I have a
Solaris 2.4 server sharing filesystems to 2.3, 2.4 and 2.5 clients and have
ran into a problem sharing "ro" or "rw" to anything but a 2.4 client.

Here is a brief description:

----- on machine1 (Solaris 2.4):
 
# share -F nfs -o rw=machine2 -d "My Directory" /opt
# share
 
- /opt rw=machine2

---- on machine2 (Solaris 2.3):
 
# mount machine1:/opt /mnt
 
nfs mount: machine1:/opt: access denied
 
# showmount -e machine1
 
/opt machine2

The same thing happens for a Solaris 2.5 machine.

If I mount it from a Solaris 2.4 machine it works fine, I also tried
sharing a Solaris 2.3 machine and mounting it to a 2.4 & 2.5 machine wich
also works and last but not least I shared it on a 2.5 machine and
mounted it to a 2.3 & 2.4 machine wich also works.

I can see that Solaris 2.4 server is the one having the problem, it has
the latest kernel patch 101945-36. I am stumped, has anyone ran into
this problem? If so did you find a way to fix it? I really hate the
thought of not being able to share NFS's the way I want.

Thanks in advance for everyone's comments/ideas/solutions.

-------- All the answers:

From: Dave Haut <dave@endeavour.exar.com>

Mark,

A good one. did you try specifying the IP address instead of the name
of machine2 in machine1's dfstab file just to see if it works ??

Perhaps it's some sort of shared lib, DNS, NIS+, or gethostbyname problem.

My $.02

---------------------------------
  _ /| Dave Haut
  \,o.O' Sys Admin
  =(___)= EXAR Corporation
     U dave@exar.com
             (510) 668-7570
---------------------------------

From: stern@sunrise.East.Sun.COM (Hal Stern - Distinguished Systems Engineer)

check your hostnames and DNS configuration -- are you seeing
fully qualified names on the server/clients that are confusing
mount? (ie, mount expects unqualified names, but it's seeing
qualified names?)

--hal

From: keith@oz.health.state.mn.us (Keith M Willenson)

1) Is machine1 listed in machine2's /etc/hosts

I had more but it looks like you covered it. Note: the last share
takes precedence over all previous shares.

K

From: "Michael S. Fischer" <mfischer@nsi.edu>

Make sure you're using the fully-qualified domain name (FQDN) of the
client host when setting access permissions. If you log in to the
server from the client and type "who" you'll be able to see the name
of the client as the server sees it. If the two entries don't match
the mount will fail.

Make sure your hosts, NIS and DNS tables are set up properly to use
FQDNs as much as possible--this will eliminate possible sources of
conflict.

-- 
 |\  Michael S. Fischer                           System Administrator  _O_
 |   Internet: mfischer@nsi.edu            The Neurosciences Institute   |
()   Phone: 619.626.2000  Pager: 619.645.1394            San Diego, CA   |

From: "Rachel Polanskis" <grove@zeta.org.au>

hello make sure the name of the client is actually the same name in your dfstab e.g if you allow hostname.domain.com access to to NFS that is not the same as allowing 'hostname'

You can find this out by using rsh or rlogin.

if you only have to type rlogin hostname or rsh hostname to be able to use the programs, then that is what should be in the dfstab

if you need to put the canonical domain in as well, then that should be in there instead...

Rachel -- Rachel Polanskis Kingswood, Greater Western Sydney, Australia grove@zeta.org.au http://www.zeta.org.au/~grove/grove.html r.polanskis@nepean.uws.edu.au http://www.nepean.uws.edu.au/library/ "When the revolution comes, I will be shot by both sides"

From: kwthomas@wizard.nssl.uoknor.edu (Kevin W. Thomas)

Mark...

Try using the fully qualified domain name, such as machine1.a.b.c, on all systems.

Kevin W. Thomas National Severe Storms Laboratory Norman, Oklahoma

From: albert@esther.rad.tju.edu (Dr. Micheal Albert)

Dear Friend:

Just a thought. I believe this helped me with a similar problem with a 4.1.3 system.

Try changing the capitalization of the machine name and/or the domain name. What I did was "snoop" the network while the machines were trying to do nfs stuff. Do a "snoop -x0 -v" It gives a lot of junk. The complete machine names will appear in the packets. They come up as ascii strings, you should see them in snoop's "third column" where is ascii-izes the dump. Use the machine names and domain names with the same capitialization as in those dumped packets. I seem to remember some documentation saying that this should be case insensitive, but this worked for me.

Best wishes, Mike

From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})

My guess would be that the name is thought of differently. WHen you rlogin or rsh to the machine, what does "who" say about your machine name??

l & h, kev



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:54 CDT