Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Scott Andrews" <scott.andrews@columbus.rr.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: mount.nfs: Stale file handle
In-reply-to: <82edf12a-a9fa-49a7-bdd0-1689c70a3a5f@columbus.rr.com>
References: <82edf12a-a9fa-49a7-bdd0-1689c70a3a5f@columbus.rr.com>
Date:   Wed, 26 May 2021 15:56:47 +1000
Message-id: <162200860728.22484.2002016024131091474@noble.neil.brown.name>
Precedence: bulk

On Wed, 26 May 2021, Scott Andrews wrote:
>=20
> cat /proc/fs/nfs/exports
> # Version 1.1
> # Path Client(Flags) # IPs
> /=20
> *(ro,no_root_squash,sync,no_wdelay,no_subtree_check,v4root,fsid=3D0,uuid=3D=
6b179096:b8b5495a:873908b5:a2b35faa,sec=3D390003:390004:390005:1)
> /home=20
> *(rw,no_root_squash,sync,wdelay,uuid=3D6b179096:b8b5495a:873908b5:a2b35faa,=
sec=3D1)
>=20

Apart from the error, this is the only place that anything looks odd.
When / is exported a v4root, there doesn't need to be a uuid=3D.
It is the same uuid as for /home.
When I experiment I don't get a uuid=3D for /.

I don't know that this would cause a problem, but maybe it does.

Two extra pieces of debugging info that might be useful:

1/ Get a network trace for port 2049 traffic between client and server
 with tcpdump.
 Be sure to use "-s 0" and provide the binary packet capture - compress
 it and attach it to the email.

2/ Before attempting the mount, and after restarting rpc.mountd on the
server and running "exportfs -f", run "strace -s 1000 -o /tmp/somefile -p ...=
" on the
rpc.mountd process, then try the mount, then kill strace.
Then provide /tmp/somefile.

NeilBrown


>=20
> Can someone help with this issue?
>=20
> Thanks for any help/direction you may have
>=20
>=20