On Thu, 25 Feb 2021 at 18:11, Ed Greshko <ed.gres...@greshko.com> wrote:
> On 26/02/2021 04:21, George N. White III wrote: > > On Thu, 25 Feb 2021 at 14:03, Ed Greshko <ed.gres...@greshko.com > <mailto:ed.gres...@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". -- George N. White III
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
