NFS Mount - permission denied - Tru64UNIX v4.0b

[A.W.R]

Hi,

We are trying to rebuild a Tru64UNIX v4.0b system. The system mounts NFS shares from another Tru64UNIX v.4.0b system.

We have included the share names in the NFS exports file.

When we try and mount from the client we get a "permission denied" error. No errors that we can find on the server.

Any suggestions would be great.

Thanks
Andrew

[Steven Schweda]

> We have included the share names in the NFS
> exports file.

With my weak psychic powers, I can't see
what's in that file. (Or which file you
think that is.) Something like a copy+paste
of a command like "cat /etc/exports" with its
output might be more helpful.

> When we try and mount [...]

Who, exactly, is "we"? ("who am i"?)
"mount" how, exactly?

Who owns what, where? ("ls -l", "ls -ld",
...)

As usual showing actual commands with their
actual output can be more helpful than vague
descriptions or interpretations. Guesswork
follows...

4.0b is before my time, but if the "we" above
is actually "root", then you might start
with:

man exports

paying particular attention to the
"-root=hostlist" (or similar) section (or to
the comments in "/etc/exports" itself?). For
good reasons, by default, NFS does not trust
a remote "root" user. If you want that, then
you need to say so. Around here, for
example:

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009

urtx# cat /etc/exports
#
# *****************************************************************
# * *
# * Copyright 2002 Compaq Information Technologies Group, L.P. *
[...]
# -root=0
# Maps all client superusers to uid 0; by default, superusers are
# mapped to user "nobody". This option overrides -anon=uid for
# client superusers.
# -root=hostname[:hostname]...
# Maps client superusers on only the specified hosts to uid 0;
# overrides the use of -anon=uid for client superusers.
[...]
/ -root=alp:alp2:debi:dy:dyi:ipc:rex:rux:sol:ung:urt:urtx,rw=alp:alp2:debi:dy:dyi:ipc:rex:rux:sol:ung:urt:urtx
[...]

(I trust everyone around here.)

[John Manger]

Its worth checking that the server machine can resolve the client IP <-> name correctly (both ways).

John M

[A.W.R]

Thank you for your response,

Please can you clarify to which name it must resolve, and how do we check this.

If I do a hostname the system comes back with a hostname HSV04.srvts.co.za

The IP name associated with the interface is drp.

Is the name the fully qualified hostname?

The other system currently has no domain configured. Do we need to do this?

Thanks
Andrew

[John Manger]

All things being equal, The NFS server must be able resolve the client's IP address to a name, and its name to an IP address. Thus /etc/hosts and/or DNS must agree on the IP/name pair for the NFS client. See mountd(8) and arguments -a and -d.

John M