Nfs mount to Tru64

[Michael Elleby III_1]

I've got an HP 6700 workstation, trying to mount a directory from an AlphaServer running DGUX 4.0 (Tru64)

I continually get a Permission denied message on any filesystem that I have exported. My 'showmount -e SERVERNAME' shows that the dirs are exported and access is granted to EVERYONE.

Both servers exist in the same domain, on the same subnet. I've even edited .rhosts on both to allow .rlogin.

Any suggestions?

Thanx.

Mike-

[Daniel Olson]

You may be running incompatible nfs versions. Do you have other servers accessing this fs?

[Helen French]

Did you try specifying the hostname in the 'access' field? I am not sure about the syntax in Tr64, but in HP this is how you specify it in the /etc/exports file:
/tmp -access=hp_hostname

[Michael Elleby III_1]

Yes, I've got about six other HP servers and workstations accessing this same filesystem.

Mike-

[Helen French]

Another option is to compare the /etc/rc.config.d/nfsconf file with other working HP systems. Check for a parameter - MOUNTD_VER. If it is set to value 2, then try changing it to 3.

[Shannon Petry]

There are a few things to look at for this. Namely because the server is refusing the client. The client is really not configurable with NFS, so lets peek at the server.
1. Make sure that the hostname is being resolved correctly. It helps to put in the IP address of the host into the access list of allowed hosts.
2. If your trying to mount via automounter instead of the mount command you need to do as someone else mentioned and configure the /etc/rc.config.d/nfsconf file and set AUTOFS=1
The default automount does not understand NFSv3 to the best of my knowledge.
3. rerun exportfs -a on the NFS server to ensure that any changes to the exports file are updated. I know with true64 in it's onset I had to exportfs -u -a ; exportfs -a to make things update.
4. make sure that portmap has not been changed on any system's /etc/services file. If they dont jive up this can cause problems

Lastly, the /.rhosts will make 0 difference to NFS. NFS could care less about that file, and does not use security the same way as remsh, rexec, rlp, etc...

Regards,
Shannon

[Michael Elleby III_1]

Shannon, my responses to your input:

1. Make sure that the hostname is being resolved correctly. It helps to put in the IP address of the host into the access list of allowed hosts.

I have attempted this mount using both the hostname and its static IP. Also, I have confirmed DNS entries exist and have also indicated on the DGUX Server that the only host allowed access to the filesystem I am trying to mount by editing the /etc/exports file and adding -access=subhp5.


2. If your trying to mount via automounter instead of the mount command you need to do as someone else mentioned and configure the /etc/rc.config.d/nfsconf file and set AUTOFS=1
The default automount does not understand NFSv3 to the best of my knowledge.

Not using the automounter.

3. rerun exportfs -a on the NFS server to ensure that any changes to the exports file are updated. I know with true64 in it's onset I had to exportfs -u -a ; exportfs -a to make things update.

To my knowledge, I have not been able to locate the exportfs command in DGUX 4.0, but I will look again. I did really dig deep on this one.

4. make sure that portmap has not been changed on any system's /etc/services file. If they dont jive up this can cause problems

Nothing has been changed.

Lastly, the /.rhosts will make 0 difference to NFS. NFS could care less about that file, and does not use security the same way as remsh, rexec, rlp, etc...

Wanted to test rlogin to see if there was any outside security issue with allowing the mount to the HP server.

Thanx for the input. I'll let you know if I find the exportfs command in DGUX.

Mike Elleby

[U.SivaKumar_2]

Hi,
Are you trying to access the nfs share as root ?

Try exporting the NFS with anon=0 option from
DGUX .

regards,
U.SivaKumar

[Keely Jackson]

Hi

To save you looking, exportfs does not exist in Tru-64. Showmount -e is the nearest equivalent.

Cheers
Keely

[Olivier ROBERT]

Hi Michael,

The client's IP address has to be resolved to a valid hostname on the server, either DNS or /etc/hosts or NIS. I don't think putting IP adresses in the exports file works. If the client's IP address is resolved to a DNS name, you should put the fully qualified domain name in /etc/exports, i.e. host part + domain part, for example subhp5.hp.com, and not only subhp5.
If that still doesn't work, you can try granting access to everyone. That SHOULD work if the IP address is resolved to a name. Try typing "nslookup ip_address_of_client" on the server to see how the client's address is resolved. You can try adding an entry for the client in the server's hosts file too. And finally, check the server's name resolution policy in /etc/svc.conf (the Digital UNIX equivalent of /etc/nsswitch.conf).
Regards,

Olivier

[Michael Elleby III_1]

Ok guys-

U. Siva - I had already tried this option, to no avail.

Keely - Was leaning toward it, since I could not find an exportfs command in the DGUX 4.0 ref pages. After Shannon's comment, I figured I might have overlooked it..

Olivier - DNS resolution works without issues. The only time I would use the IP address, is in my mount command. My current showmount shows that any exported filesystem grants access to everyone. Lastly name resolution policy in /etc/svc.conf is local,bind,yp..

Thanx for the input guys... Still banging away at this one...

Mike-

[Vikki Wikeley]

Do you have enough nfsd threads setup on the server ?
A free nfsd thread needs to exist for a client to connect to a server.
Try
ps axml | grep nfs
if there is an I next to nfs_udp or nfs_tcp there is an idle thread. If all your threads are used you will have to increase the number.

Hope this helps.

[Shannon Petry]

Sorry about exportfs, I have not touched true64 since the month compaq purchased dec, and as far as I remeber the hybred OS that first appeared and looked like winnt had an exportfs command, but that was a while ago so I could very well be wrong!

Anyway,
The easiest way to tell how the NFS server is getting the hostname resolution(if it is) is to rlogin to the server from the client and do a 'who -u' to show where the host is accessed from.

For fun tail the system log on the dec while manually trying to mount the filesystem to ensure that no system errors are reported.
Also try to mount the same filesystem a 2nd time on one of the other boxes to ensure that there is no problems.

Also, on the problem client make a new mount point and try the mount there read only.
I.e.
% mkdir /testnfs
% mount -o ro $decserver:/dir /testnfs
If the read only test works, then try again to mount in that same directory with no options.

You can also specify the version of NFS you want to mount with. This may help if the true64 box is requiring NFSv3.

Regards,
Shannon

[U.SivaKumar_2]

Hi,
Try this from DGUX server.
#nslookup xx.xx.xx.xx
where xx.xx.xx.xx is the ip address of the HP workstation.
Now your DNS server should give the DNS name of the IP address.

If not , then it is problem is due to missing PTR records for inverse lookup done by the server when the client tries to access it's nfs mounts.

regards,
U.SivaKumar

[Michael Elleby III_1]

Firstly, I wanted to thank you all for your suggestions... Here is where I am right now..

I noted that I can export any dir on the dgux box, and I cannot mount it with this particular (subhp5) HP client. I then went to another dgux 4.0 box, and I could mount any exported directories without any issues from this same HPUX client...

I'm still researching..

Mike-

[Michael Elleby III_1]

Hello all-

Finally got this one resolved. There was a problem with the mountd daemon on the Alphaserver.

Once I restarted this daemon without the minimal options (-i (internet address verification), and -n (allow non-root mount requests), the mount worked.

However, when I once again restarted the daemon with the minimal options, the mount still worked, so, I guess the prior process was corrupted somehow.

Mike.