ITEM: AF2879L
nfs mount 1831-011 access denied
NFS client attempts mount, but gives the following errors:
1831-011 access denied
1831-008 giving up on \
Seven frequent causes of mount problems are:
1. File system not exported, or not exported
to the client in question.
fix: export it.
2. Name resolution doesn't jibe with the exports list.
eg: export list says export to nfsclient
nfsclient's name is resolved as nfsclient.austin.ibm.com
mount permission is denied.
fix: export to both forms of the name
It can also happen if the client has 2 adapters
and 2 different names for the two adapters and
the export only specifys one.
fix: export both
It can also happen if the server can't do a
lookuphostbyname or lookuphostbyaddr on the client.
(make sure it can do
host \
host \ and resolve both to the same thing.
fix: straighten out name resolution.
3. The file system was mounted after
the NFS started. In that case the
export command is exporting the mount point
and not the device mount.
fix: run
/usr/etc/exportfs -ua; /usr/etc/exportfs -a
Then fix the filesystems file to mount
the file system on boot, so it is already
mounted when NFS starts from rc.nfs.
4. Something changed in the exports list or
in the mounts or somewhere else unexpectedly.
mountd is confused. Usually happens when something
was mounted; exported; umounted; something else
mounted on that mount point...etc.,etc.
fix: stopsrc -s mountd; startsrc -s mountd
5. The date is wildly off on one or both machines.
fix: get the date set right, reboot the machine.
6. The client is using an old mount protocol.
fix: Start the mountd on the server with the
-n option. (AIX V3 and later clients should not need
this but other vendors' clients might.)
7. The server can not accept a mount from
a user that is in more than 8 groups.
fix: decrease the number of groups the
user is in or mount via a different user.
(AIX V3 and later servers should not have this
problem but other vendors' servers might.)
Response:
In some experiments here, I get the exact same two messages when name
resolution is disabled on my NFS server, such that it cannot resolve
IP address of the hostname passed in from the client in the MOUNTPROC_MNT.
In a successful mount, client and server have the following RPC call
exchanges:
PMAPPROC_GETPORT
MOUNTPROC_MNT (client sends in his "machine" name, without DNS domain,
server responds with 36 bytes of RPC data)
RFS_GETATTR
RFS_STATFS
ACL_PCL_PROG
On a failing mount, with the 1831-011 and 1831-008 errors, the only
RPC calls exchanged are:
PMAPPROC_GETPORT
MOUNTPROC_MNT (client sends in his machine name, without DNS domain,
server is configured to be unable to resolve this hostname
to IP address, and server responds with 4 bytes of RPC
data.)
Response:
Now that you have informed me there are two network interfaces
on the failing client, here is the reason for your mount failure:
Hostname that cannot mount is rxp2,
primary interface is en0, 142.136.80.14 mask 255.255.255.0
secondary interface is tr0, 142.136.83.14 mask 255.255.255.0
142.136.83.14 resolves to rxp2tr.
default route is 142.136.83.1
In fact, traceroute optical2 (142.136.211.200) passes thru 83.1.
(optical2 is the NFS server)
The mount request is going out the 83.14 interface, with the hostname
rxp2. But at the server, machine rxp2 resolves to 80.14 address, doesn't
match the source address of the request, and fails.
This is a DNS environment, but the NFS server is not using DNS for
name resolution. So the first thing to try, before changing primary
and secondary interfaces, before changing DNS, is this:
Go to the NFS server's hosts file, and only use this entry:
142.136.83.14 rxp2
Yes, the rest of the corporation using DNS thinks rxp2 is 80.14,
but if NFS server doesn't use DNS, it lives in its own world of name
resolution.
Support Line: nfs mount 1831-011 access denied ITEM: AF2879L
Dated: February 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:28
Comments or suggestions?
Contact us