On 26/02/2021 04:21, George N. White III wrote:
> On Thu, 25 Feb 2021 at 14:03, Ed Greshko <ed.greshko@greshko.com <mailto:ed.greshko@greshko.com>> wrote:
>
> On 26/02/2021 01:19, George N. White III wrote:
> > I haven't used CentOS7 for several years, so I was ignoring this
> > thread in the hope others could answer.
> >
> > My not very trustworthy memory is that "/etc/exports" on
> > the server needs the "insecure" option for NFS4 to work, see:
> > https://access.redhat.com/solutions/3773891 <https://access.redhat.com/solutions/3773891> <https://access.redhat.com/solutions/3773891 <https://access.redhat.com/solutions/3773891>> for explanation
> > and some diagnostic tests. My take on diagnostics is:
>
> FWIW, "others" have tried changing
>
> /home/egreshko 2001:b030:112f:2::0/64(rw,sync,insecure,no_root_squash,no_subtree_check)
>
> to
>
> /home/egreshko 2001:b030:112f:2::0/64(rw,sync,no_root_squash,no_subtree_check)
>
> And the mount from an F33 system still succeeds.
>
> The entry for "man exports":
>
> secure This option requires that requests not using gss originate on an
> Internet port less than IPPORT_RESERVED (1024). This option is
> on by default. To turn it off, specify insecure. (NOTE: older
> kernels (before upstream kernel version 4.17) enforced this re‐
> quirement on gss requests as well.)
>
> /run/sysconfig/nfs-utils had: GSS_USE_PROXY="yes" -- wonder if GSS is somehow at play here?
On my centos7 system....
[root@cos7 ~]# uname -r
3.10.0-1160.15.2.el7.x86_64
[root@cos7 ~]# cat /run/sysconfig/nfs-utils
RPCNFSDARGS=" "
RPCMOUNTDARGS=""
STATDARGS=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
GSSDARGS=""
BLKMAPDARGS=""
GSS_USE_PROXY="yes"
nfs-utils-1.3.0-0.68.el7
And, since it is now 05:40, I modified the exports file to be simply
/home/egreshko 2001:b030:112f:2::0/64(rw)
And from an F33 client which is the host of the the centos7 VM.
[root@meimei ~]# mount -v cos7:/home/egreshko /mnt
mount.nfs: timeout set for Fri Feb 26 05:45:37 2021
mount.nfs: trying text-based options 'vers=4.2,addr=2001:b030:112f:2::41,clientaddr=2001:b030:112f:2::2'
[root@meimei ~]# df -T | grep mnt
cos7:/home/egreshko nfs4 29599744 5328128 24271616 19% /mnt
So, I still can't find a way to duplicate the OP's problem without specifically changing a config file.
There is always the possibility of some "invisible character" error in a config file.
I even when to far as to mount the file system with a F33 "located" in the USA and the centos7 system
in Taiwan.
[root@acer ~]# mount -v [2001:b030:112f:2::41]:/home/egreshko /mnt
mount.nfs: timeout set for Fri Feb 26 06:03:52 2021
mount.nfs: trying text-based options 'vers=4.2,addr=2001:b030:112f:2::41,clientaddr=2001:440:66:cce::2'
[root@acer ~]# df -T | grep mnt
[2001:b030:112f:2::41]:/home/egreshko nfs4 29599744 5325056 24274688 18% /mnt
Google turns up many ways to get
"mount.nfs4: access denied by server while mounting". One that I
don't recall being mentioned is mismatched user/group ID's with "sec=sys".