Tru64 NFS client cannot access Red Hat NFS server - RPC: Authentication error

[Geert Van Pamel]

When a Tru64 client has mounted a remote NFS disk on a Red Hat server, I get the following error:

hbsitlab$ ls /scsitvxt/home
NFS3 RFS3_GETATTR failed for server hbsitvxt : RPC: Authentication error
/scsitvxt/home not found

When I do the ls from the Tru64 root account, it works:

lab# ls /scsitvxt/home
apache … watchdog

When mounting the same disk from another Red Hat client, everything is OK.

My only conclusion is that the Tru64 client is incapable to authenticate itself to Red Hat.

Is Red Hat running some special authentication protocol that Tru64 is unaware of?

Note that all UID and GID are identical on all machines.

[Aco Blazeski]

What is the mount command (post full command with all arguments) that you issue on Tru64 client ?
Also what is the mount command on RHL client?

Can you NFS mount some other disk (from Tru64 server for example) from your Tru64 clinet?

Also post the line from your RHL server that exports the NFS disk that you're trying to mount.

Regards,

[Ivan Ferreira]

I had NFS problems with Linux and AIX, and was solved by adding the "insecure" option to the directory export options.

You may try that.

[Ivan Ferreira]

Also, name resolution is very important for NFS to work correctly. Verify your DNS settings or host tables.

[Geert Van Pamel]

I have tried insecure as an export option, this did not help.

I have also tried insecure_locks or no_auth_nlm, this did not help neither.

DNS and /etc/hosts files are OK (NFS works perfectly from Red Hat clients, but does not work from Tru64 clients).

NFS between Tru64 clients & servers works also perfectly.

This is the export file on the Red Hat 7.2 Alpha NFS server (sorry Guys, but this is the most recent Red Hat for Alpha machines !)

I have tested all combinations:

/data hbsitlab(rw,sync)
/data hbsitlab(rw,sync,no_auth_nlm)
/data hbsitlab(rw,sync,insecure)
/data hbsitlab(rw,sync,insecure,no_auth_nlm)

This is the /etc/fstab file on the Alpha NFS Tru64 client

hbsitvxt:/data /scsitvxt/data nfs rw,bg 0 0

[Aco Blazeski]

Hi Geert,

pls try with following line (nfs ver 3) for mounting on your Tru64 client:

hbsitvxt:/data /scsitvxt/data nfsv3 rw,bg 0 0

also, if UIDs and GIDs are the same, maybe you should try in exports on RHL server to specify user/priviledges for filesystem that you export. I'm not sure what's the syntax for RHL but for Tru64 I do something like this:

/export_dir -rw=client_hostname -root=client_hostname

Maybe above will work /:-|

Regards

[Geert Van Pamel]

Per your advice I have done the following on the Red Hat server:

vi /etc/exports
...
/data hbsitlab(rw,sync,no_root_squash)

/sbin/init.d/nfs reload

and on the Tru64 client:

vi /etc/fstab
...
hbsitvxt:/data /scsitvxt/data nfsv3 rw,bg 0 0

umount /scsitvxt/data

mount /scsitvxt/data

hbsitlab$ ls /scsitvxt/data
NFS3 RFS3_GETATTR failed for server hbsitvxt : RPC: Authentication error
/scsitvxt/data not found

hbsitlab$ su -
Password:
lab# ls /scsitvxt/data
id068720 mysql

You see, from the root account it did always work, also with the following syntax:

vi /etc/exports
...
/data hbsitlab(rw,sync)

Only for non-root users it does not work with the following error... RPC: Authentication error

[Ivan Ferreira]

Root access should be anonymous at the server side. Try the option all_squash to verify what happens.

Are you using local authentication or a directory server?

[Geert Van Pamel]

Nothing changes ...

(on Red Hat NFS server)
vi /etc/exports
...
/data hbsitlab(rw,sync,all_squash)

/sbin/init.d/nfs reload

(on Tru64 client)
hbsitlab$ ls /scsitvxt/data
NFS3 RFS3_ACCESS failed for server hbsitvxt : RPC: Authentication error
/scsitvxt/data: I/O error
su -
lab# ls /scsitvxt/data
... mysql

[Geert Van Pamel]

We are using local authentication... but the /etc/passwd & /etc/group files are in synch -> same UID & GID for both machines.

[Aco Blazeski]

When I post my suggestions above I did not understood well your problem, that acctually you have access to nfs disk with root.

However what are the user/group/other permissions on the /data directory on RHL server ?

[Geert Van Pamel]

Protection of NFS /data server mount point.

vxt# ls -ld /data
drwxr-xr-x 6 root root 4096 Nov 4 08:35 /data

May I repeat that everything works from another Red Hat NFS client.

I have the problem only a Tru64 NFS client.

[Ivan Ferreira]

The error indicates that you are using NFSv3.

NFS3 RFS3_GETATTR


Try using NFSv2.

-o nfsv2

[Aco Blazeski]

Ok, I have that in mind (that you have problem only on Tru64 client).

However, can you try (just for test), to set permission to 777 on /data ?

Btw, nfs on tru64 means nfv ver 2 by default...

Regards

[Ivan Ferreira]

Disagree with Aco, from the mount man page:

Usually, the mount command tries to use Version 3 of the NFS protocol.

If the server does not support Version 3, then the mount command retries the mount using Version 2.

[Aco Blazeski]

Ok, I agree with Ivan,

I thought on option "-t"

-t nfs - version2
-t nfsv3 - version3

while nfsv2 is NFS argument.

Thank you Ivan for pointing that.

Regards

[Geert Van Pamel]

vi /etc/fstab
...
hbsitvxt:/data /scsitvxt/data nfs rw,bg,nfsv2 0 0

lab# umount /scsitvxt/data
lab# mount /scsitvxt/data

lab# ls /scsitvxt/data
... mysql

hbsitlab$ ls /scsitvxt/data
NFS2 getattr failed for server hbsitvxt : RPC: Authentication error
/scsitvxt/data: I/O error

vi /etc/fstab
...
hbsitvxt:/data /scsitvxt/data nfs rw,bg,nfsv3 0 0

lab# umount /scsitvxt/data
lab# mount /scsitvxt/data

hbsitlab$ ls /scsitvxt/data
NFS3 RFS3_ACCESS failed for server hbsitvxt : RPC: Authentication error
/scsitvxt/data: I/O error

Even chmod 777 /data on the NFS server does not make any difference...

I believe that Tru64 RPC authentication is not compatible with Red Hat... Do have Red Hat client/servers some special RPC authentication mechanism amongst them?

I do have both client machines registered on the NFS server

vxt# cat /etc/hosts.equiv
...
resitlab.bc
hbsitgvp.bc

(The first client is Tru64, the second Red Hat)

[Ivan Ferreira · Accepted solution]

Are the users members of too many groups?

See:

http://www.bjnet.edu.cn/sun-admin/FAQ/F-comp-sys-sun/Q13-0.html

I don't believe that you are using secure rpc, so the second option does not apply.

[Geert Van Pamel]

Ivan got it right... there was one user (me!) with too many group memberships on the client machine. The problem had nothing to do with a Tru64 problem, only with an NFS limitation.

I am now member of less than 16 groups and it works!

Anyway, what has always appeared wrong to me in the whole NFS security protocol is that the group membership is controlled by the "remote" server machine(s), and not by the "local" server, as is the case with e.g. OpenVMS proxy accounts.

As a consequence users on different client machines can have different access rights on the same NFS target server. To me this is illogical and is a security risk.