NFS mount permission denied

[Damle Yogesh]

My ignite client and server are running HP-UX 11.11.

I am trying to NFS mount the server disk onto client, but I am getting a "permission denied" error.

entry in /etc/exports looks like this:

/var/opt/ignite/recovery/archives/ -anon=2 access=

I also tried changing -anon=0. It did not help either.

Any thoughts?

Thanks in advance.

[Geoff Wild]

Do you have a comma or a space?

Should be:

/var/opt/ignite/recovery/archives/ -anon=2,access=


Rgds...Geoff

[RAC_1]

On client, are you trying to mount as root, then you would require option root=client_name/ip in /etc/exports file (on server)

Anil

[Damle Yogesh]

I have modified the entries as suggested by Goeff. It still does not work.

FYI.. The client has FQDN, where as the server does not. Hence client shows ..com when issue command "hostname". Same command on the server side shows .

I have tried modifying the exports file to take care of that as well.

what else can I do?

[Geoff Wild]

Just a thought - you did a:

exportfs -a

after modifying the file?

Rgds...Geoff

[Damle Yogesh]

Of course I did.

[Dave Olker]

Hi Damle,

The best way to get a good understanding of why a mount fails is to collect both a network trace of the failing mount attempt, and to enable debug rpc.mountd logging on the NFS server.

You can use nettl or ethereal to collect the network trace. As for the debug rpc.mountd logging - you simply send the running rpc.mountd daemon a SIGUSR2 signal.

# ps -e | grep rpc.mountd
# kill -17

This will toggle debug logging on the server and start logging rpc.mountd messages into the file /var/adm/mountd.log. Once debug logging is enabled, and the network trace is started, reproduce the mount failure and then immediately stop the network trace (as these tend to fill up quickly) and then send the running rpc.mountd another "kill -17" to toggle debug logging back off.

The mountd log file should tell you why the mount is failing, or at least point you in the right direction. The network trace is handy to have to know exactly which IP address the mount request is coming from.

In other words, if your NFS client has 2 LAN interfaces and you're only exporting the filesystem on the server for 1 of the interfaces, and the mount request originates from the 2nd client LAN interface - the server will reject it. The network trace will show the IP addresses of the client sending the mount request, and you can use nslookup on the server to ensure that the server resolves the client's IP address to the hostname listed in the exports file.

Hope this helps,

Dave

[A. Clay Stephenson]

Another source of problems is very restricted permissions (maybe 000) of the mountpoint directories on the NFS server itself. This is especially true for nested mounts. The permissions of the mounted filesystem directories may look fine so you need to umount the filesystem(s) and check the mountpoint permissions for each one.

[Sridhar Bhaskarla]

Hi,

Add the short hostname, fully qualified name and the IP address also and see if it works. It depends on how the client is 'appearing' to the NFS server.

-Sri

[Geoff Wild]

What is in nswitch.conf on both servers?

hosts: file [ SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue ] dns

If files then dns, I would add the hostsnames and FQDN of all servrs to the /etc/hosts file.


x.x.x.x node1 node1.yourdomain.com


Rgds...Geoff

[Damle Yogesh]

Thank you very much all of you. Its did help me toggle the debug switch with kill -17 and looking up nsswitch.conf file.

this problem has been solved.