1. Secure NFS and NIS+ problem solved
I've been trying to figure out a problem with secure NFS and NIS+
lately (I'm using Solaris 8) and I think I've finally found a
solution. I've seen other postings reporting the same kinds of
problems without any real answers so I thought I'd post my results.
I'd been using NIS+ for a while for standard authentication, etc, but
just couldn't seem to get secure NFS working. I'm not an expert with
all of the details and terminology, but I'll try to explain what I've
To review the problem, I was attempting to share a file system with
the -o sec=dh option and mount it on the clients also with the sec=dh
option. When mounting the filesystem on a client, the mount command
would execute without any errors, but when trying to cd or ls at the
mount point I would get errors such as "Invalid argument". In my log
files on the client side I got entries:
NOTICE: authdes_create: unable to get client's netname, rpc status
I had made sure that I had all the involved hosts listed in the
hosts.org_dir table and everything and had credentials created for
them, to no avail.
The problem for me turned out to be that I was using the dh640-0
authentication scheme rather than the standard DES (or dh192-0). Of
course, that's not a problem in and of itself because I've been using
dh640-0 successfully for a while for all the standard NIS+ stuff.
From what I've found, dh640-0 is not supported for secure NFS at this
time... it would require additional kernel components that are not yet
packaged/released by sun (if anybody knows differently, let me know).
So, the error about not being able to get the client's netname meant
that it was looking for a dh192-0 credential and since I only had
dh640-0 credentials, it couldn't find what it was looking for.
The solution I ended up implementing was to configure both dh640-0 and
dh192-0 (which is often just referred to as DES) authentication
mechanisms on these machines (clients and the server):
/usr/lib/nis/nisauthconf dh640-0 des
I believe that by putting dh640-0 first, it will be used by default by
everything besides secure NFS.
For me, this meant that I had to create new dh192-0 credentials for
the machine serving the secure NFS filesystem and for all users that
needed to access the secure NFS filesystems. Also, if root on a client
needed access, I had to create dh192-0 credentials for that client
This is basically of the form:
The newly added credential will show up as auth_type of "DES" in the
Remember to do a "keylogin -r" on any machines you added new
Hope that is helpful,
2. Seeing 1 network from another
3. NIS+ password/account problem, solved
4. XSane Canon 630U config - So Near but yet so Far
5. NIS+ credentials problems : SOLVED
6. Serial port
7. NIS : auth problem with Linux nis server and SUN sparc nis client
8. news groups
9. Awe64 problem solved. Got another problem instead.
10. 2nd CDROM problem solved - MAKEDEV problem on 3.3
11. problem still not solved token ring problem (3c619rev.b)
12. NAT Problem Solved, New Problem
13. NIS+ Compatibility Mode (NIS Client - calendar problem)?