Hi. On Mon, Jan 09, 2017 at 06:48:43PM -0500, Harry Putnam wrote: > Reco Wrote: > > Which brings me to this: > > > > 1) What security option are you using (i.e. none, sys, krb5, etc)? > > If unsure, please mount a share by hand and obtain mount options > > from /proc/mounts. > > It appears to be sys (sec=sys) > > 192.168.1.42:/projects/dv /projects/dv nfs4 rw,relatime,vers=4.0,\ > rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,\ > timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.29,local_lock=none,\ > ^^^^^^^ > addr=192.168.1.42 0 0
Ok, that simplifies things somewhat. So it's tcp-over-ipv4 type of NFS4 without any security worth mentioning. > > 3) Stop autofs, start it like this: > > > > /usr/sbin/automount -fd > > > > Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C. > > (below I marked with *** what might be a clue) You missed it by two lines ☺: > get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 6 version 0x30 > get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 17 version > 0x30 > > *** mount(nfs): no hosts available To workaround #828217 please comment out the line with '-host' in /etc/auto.master. > As I mentioned in the OP: > The host involved is a solaris x86 host. The file systems set for > nfs availability are not put into an /etc/exports type setup. That's what they want you to beleive. Please check out /etc/dfs/sharetab on NFS server. > The way it is done on solaris with the zfs file system... is during > the creation of a file system with `zfs create' One of the ways of doing it, certainly not the most easiest one. share(1M) is decade older at least and thousand times easier to use. > So maybe that has something to do with the problem... Hardly. The way you're doing on Solaris it you provide NFS shares to everyone and their dog in read-write mode with sec=sys by NFS versions ranging from two to four. At least these are defaults starting with Solaris 10. The thing that's broken here is autofs, not NFS implementation. Reco