Original Post:
Trying to NFS mount a file system rw from a Solaris 2.5.1 machine to a
Solaris 2.6 machine.
Below is the entry in the /etc/dfs/dfstab on the server (snowhite) for the
file system to be exported:
share -F nfs -o rw=dswsun /opt/proeng
I put the rw option to try and force it even though rw should be the
default. The dfshares command correctly reports that the file system is
shared.
Many of you will probably notice that the file system to be exported is for
Pro/ENGINEER. Up to this point, I have always installed the software on
each machine but our CAD group is growing and it is becoming to time
consuming for me to upgrade each machine every time there is an update
(which is frequent). Therefore, I am going to nfs mount the software so
that I only have upgrade the server.
Below is the entry in /etc/vfstab to mount the filesystem on the client
(dswsun).
snowhite:/opt/proeng - /opt/proeng nfs - yes rw,bg,hard
The mount command output on the client for this file system indicates that
it is mounted rw. Again, I gave rw as a mount option even though this
should be the default behavior as I understand it.
/opt/proeng on snowhite:/opt/proeng read/write/bg/hard/remote on Wed Oct 22
09:30:47 1997
The permissions on the mounted filesystem are 755 for root and I am doing
everything as root.
When I cd to the /opt/proeng directory and try to "mkdir junk" I get the
standard and ubiquitous "Permission denied." Likewise, for those of you
that are familiar with configuring Pro/E, if I run ptcutil from the Pro/E
bin directory on the client I get the error message "no write access to the
selected load point."
Question: What the heck am I doing wrong or overlooking? I know it has to
be something simple.
********************************************************************************
Many, many responses were received all giving pretty much the same advice:
in /etc/dfs/dfstab include root=dswsun for the client.
Example: share -F nfs -o rw=dswsun,root=dswsun /opt/proeng
Many people also indicated that doing this creates an obvious security risk.
I received too many replies to thank everyone individually so please accept
my thanks here to everyone listed below and to those that I am sure are to
follow.
leach@OCE.ORST.EDU (Tom Leach)
Stephen Frost <sfrost@mitretek.org>
Stephen Harris <sweh@mpn.com>
zshouben@PCS.CNU.EDU (Shouben Zhou)
Frank Cusack <frank@fore.com>
"Karl E. Vogel" <vogelke@c17mis.region2.wpafb.af.mil>
Charlie Mengler <charliem@anchorchips.com>
Nikos George <nikos@jimmy.harvard.edu>
Sun System Admin <sysadm@its.brooklyn.cuny.edu>
Roy Culley <tgdcuro1@gd2.swissptt.ch>
Justin Zaglio <justin@caxton.com>
Michael Maciolek <mikem@centerline.com>
Scott Bailey <sbailey@inso.com>
hargrme@wisdom.maf.nasa.gov
bismark@alta.Jpl.Nasa.Gov (Bismark Espinoza)
Jerry Springer <springer.jerry@tci.com>
Jeff Woolsey <woolsey@jlw.com>
Jens Fischer <jefi@kat.ina.de>
brw@jazz.njit.edu
****************************************************************
Leo Crombach Phone: (716) 388-3566
System/Network Administrator Email: lcrombach@tropel.com
Tropel Corporation URL: http://www.tropel.com
60 O'Connor Road
Fairport, New York 14450
****************************************************************
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:06 CDT