> On Apr 6, 2018, at 12:07 PM, Orion Poplawski <orion@xxxxxxxx> wrote: > > On 04/03/2018 09:44 AM, Orion Poplawski wrote: >> Kernel is 3.10.0-693.21.1.el7.x86_64 I don't have Red Hat support for these >> systems. >> >> I discovered that I'd been forcing vers=4.0 mounts in order to work around a >> mounting issue. > > And I'm back to seeing the mount issue at boot. Here's the situation - we're > forcing kerberos on the public network, but allowing sec=sys on some private > networks: > > /etc/exports: > / -ro,async,fsid=0 192.168.1.0/24(sec=sys) > 192.168.2.0/24(sec=sys) *.nwra.com(sec=krb5) > /export/home -rw,async,nohide 192.168.1.0/24(sec=sys) > 192.168.2.0/24(sec=sys) *.nwra.com(sec=krb5) > > So for a while after boot, attempts to mount with sec=sys fail: > > # mount -t nfs4 -s -o > sec=sys,intr,rsize=262144,wsize=262144,noatime,lookupcache=positive,actimeo=1 > earthib.cora.nwra.com:/export/home/greg /mnt > mount.nfs4: Operation not permitted > > But then later they work: > > # mount -t nfs4 -s -o > sec=sys,intr,rsize=262144,wsize=262144,noatime,lookupcache=positive,actimeo=1 > earthib.cora.nwra.com:/export/home/greg /mnt > # umount /mnt > > This can cycle back and forth. > > I've attached a packet capture of some failed mount attempts. It seems that > even with specifying sec=sys, some kerberos stuff is going on. > It appears to be related to mounting a different sec=krb5 mount over the > public network from the same server. While that mount is active, the sec=sys > mounts fail. When it is unmounted, they work. At least now I think I can > work around this... Bruce- I examined the attached network capture. There are two attempts to do an EXCHANGE_ID operation. Both times: - a fresh GSS context is established successfully - a fresh TCP connection is established by the client - EXCHANGE_ID is sent using krb5i and the previously established GSS context -- client owner verifier is 0x5ac794e81d0a1d81 -- client owner is "Linux NFSv4.1 qcomp1.cora.nwra.com" -- state protection is SP4_MACH_CRED - the server responds NFS4_OK; the CONFIRMED_R, PNFS_MDS, and MOVED_REFER flags are set - the client destroys the GSS context - the client closes the TCP connection -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
