NFS Permission Denied errors

[Christian Briggs]

NFS server = 11.23 PA-RISC
NFS Client = 11.11

/etc/exports file contents:
/export -anon=2
/var/opt/ignite/clients -anon=2
/var/opt/ignite/recovery/archives/host1 -anon=2,access=host1
/var/opt/ignite/recovery/archives/host2 -anon=2,access=host2
/var/opt/ignite/recovery/archives/host3 -anon=2,access=host3
(this pattern repeats out to host28 and hosts are HP-UX versions 11.0, 11.11, 11.23 PA-RISC and Itanium)

/var/opt/ignite/recovery/archives is a seperate filesystem.

When I attempt to mount on host1:
mount hpignite:/var/opt/ignite/recovery/archives/host1 /test

I get the error message "Permission Denied". Host1 is the only server that I experience that problem on. Also, host1 is able to mount both the /export filesystem and the /var/opt/ignite/clients filesystem. I have also tried removing the access=host1 flag with no luck and tried mounting a different directory in in /var/opt/ignite/recovery/archives (by both removing the access= flag and adding host one to the access= flag) - no luck. All permissions and ownership are the same on all of the directories, both the ones that work and the ones that don't (755, bin:bin)

Thoughts??? Points will be given...

[gstonian · Accepted solution]

I know you said you did this but when I had this same problem, I removed the host restrictions and simply left the directory in there. Try taking out the anon and access statements.

[Jeff_Traigle]

Since you're using the hostname for the access list, name resolution will occur. My first guess, since you state everything in the NFS configuration looks identical to the ones that work, is that the name resolution for host1 on the NFS server doesn't match host1's actual IP address. Does "nslookup host1" on the NFS server return what you expect?

[Chan 007]

Hi,

Check your Name resolution or else check the permission of the directories

/var/opt/ignite/recovery/archives/host1
/var/opt/ignite/recovery/archives/host2
/var/opt/ignite/recovery/archives/host3

They should be bin:bin and 755.

Chan

[Christian Briggs]

gstonian - I hadn't tried removing the anon=2 flag and when I did that it worked. This doesn't really fix my problem, it is really only a "work around", so I only gave you 9 points - I'll give you 10 (for a total of 19 on this thread) if you can fix the problem.

Jeff and Chan - I should have mentioned that I had checked resolution and forward and backward were both working on the client and the server.

10 points still up for grabs...

[Peter Godron]

Christian,
does your /etc/passwd file match the requirements as specified in "man exportfs"

"anon=uid
If a request comes from an unknown user, use uid as the
effective user ID.

Root users (user ID 0) are always treated as user
unknown by the NFS server unless they are included in
the root option below.

If the client is a UNIX system, only root users are
considered unknown. All other users are recognized
even if they are not in /etc/passwd.

The default value for uid is the user ID of user
nobody. If user nobody does not exist, the value -2 is
used. Setting the value of anon to -1 disables
anonymous access."

[gstonian]

Have you tried with the anon removed and the access=host1 left in ? The default for anon is -2 anyway.

I would of also recomended you check the hosts file for name resolution etc. but if you've checked that I'm a little unsure. Maybe try ipaddress ?

[Christian Briggs]

Well, I still have this problem.

gstonian: no, the filesystem won't mount if there are any mount options in the /etc/exports file on the server. I also tried via IP and that didn't work either.

Peter Godron: I'm not sure how to apply your suggestion. At first I thought that maybe the bin user ID was different on this client - but, alas, that is not the case. I can't find any differences in the password files of the clients that work and this one that does not.

General update:
As you may have guessed I am using these NFS mount points for the purpose of completing Ignite backups. Even though I am able to mount the directory through an open shell (after I removed all mount options as I described above), Ignite is still not able to perform it's mount process and fails with "Permission Denied".

[Denver Osborn]

What's different between problem host1 and a working host? Any firewall involved?

Are the working clients also hp-ux 11.11?

Have you looked at the archive dir for host1 on the IUX server and compare to working host's dir?

-denver

[Denver Osborn]

Doh. Almost forgot... Does showmount output look ok for /var/opt/ignite/recovery/archives/host1 entry?

/usr/sbin/showmount -e ignite_server |grep host1


-denver

[Christian Briggs]

Denver,
The IUX server is a multi-homed host so I am not traversing a firewall to get to any client. I have clients at all levels of 11+ and this is the only one that I have problems. Also, remember that I said that I could NFS mount other directories just nothing in /var/opt/ignite/recovery/archives.

The showmount command indicates that the NFS mount point is exported and that the client can (actually everyone) can connect to it.

[Denver Osborn]

can you try to re-export that archive, but use the host1 ip address instead of hostname.

from iux server,

exportfs -uv /var/opt/ignite/recovery/archives/host1

exportfs -v -o anon=2,access=host1.ip.address /var/opt/ignite/recovery/archives/host1

from host1,

mount -F nfs iux_server:/var/opt/ignite/recovery/archives/host1 /var/opt/ignite/recovery/arch_mnt


Does it still return permission denied?

-denver

[Mahesh_Dadi]

Hi to all,

I am alos having same issue.Unable mount nfs mount in nfs client machine.Showing Permission denied.

I have checked from nfs server exports file.nfs client machine is having access.

In nfs server i found nslookup it is showing wrongs resoultion.and corrected the host file in nfs server.

then i able to mount nfs mount point.

Thanks to all.

With Regards,

Mahesh