nfs-utils 2.4.1-1 server: stale file handle

[hfs99]

Server is an odroid-HC1 (same as odroid-XU4) so maybe this should go in armv7. Initial post to ask if anyone else has seen the issue.
$this->bbcode_second_pass_code('', '$ tail -20 /var/log/pacman.log
.....
[2019-06-19 13:30] [ALPM] upgraded nfsidmap (2.3.4-1 -> 2.4.1-1)
[2019-06-19 13:30] [ALPM] upgraded nfs-utils (2.3.4-1 -> 2.4.1-1)
[2019-06-19 13:30] [ALPM] transaction completed
.....
')
In this primitive setup, all access is anonymous.
/etc/exports:
$this->bbcode_second_pass_code('', '# Use `exportfs -arv` to reload.
/srv/public *(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001)')
ClientA: x86_64, fedora 30
* immediately after mount, tcpdump shows ~20 getattr/response pairs that looked normal
* after that it appeared all the server responses were "stale file handle" errors
* I didn't save the log but I assume I can provide packets if that would be helpful

ClientB: odroid-XU4:
* worked OK for a few seconds after mount (long enough to actually list the root directory).
* all queries produced "stale file handle" after that.
* I didn't try to capture any packets

I downgraded both nfs-utils and nfsidmap to 2.3.4-1
$this->bbcode_second_pass_code('', '[2019-06-23 15:53] [PACMAN] Running 'pacman -U /var/cache/pacman/pkg/nfs-utils-2.3.4-1-armv7h.pkg.tar.xz'
[2019-06-23 15:54] [PACMAN] Running 'pacman -U /var/cache/pacman/pkg/nfs-utils-2.3.4-1-armv7h.pkg.tar.xz /var/cache/pacman/pkg/nfsidmap-2.3.4-1-armv7h.pkg.tar.xz'
[2019-06-23 15:55] [ALPM] transaction started
[2019-06-23 15:55] [ALPM] downgraded nfsidmap (2.4.1-1 -> 2.3.4-1)
[2019-06-23 15:55] [ALPM] downgraded nfs-utils (2.4.1-1 -> 2.3.4-1)
[2019-06-23 15:55] [ALPM] transaction completed
[2019-06-23 15:55] [ALPM] running 'systemd-daemon-reload.hook'...
[2019-06-23 15:55] [ALPM] running 'systemd-update.hook'...
')
so I don't know which one causes the issue. Everything seems to be working "like before" at this point.

Feeble troubleshooting efforts:
* nfsstat looks about the same (to me) now as it did when things were broken. I didn't save screen dumps.
* I verified that some sort of NTP service was running on each side (in fact the server was still set to UTC, but changing it to America/Chicago to match the clients had no effect.)

[nesk]

Exact same problem here. Cubieboard1 on the server, amd64 Arch on the client.
Mounting NFS started working again after I downgraded nfs-utils and nfsidmap from 2.4.1-1 to 2.3.4-1 on the server. On the client I still have 2.4.1-1.

[hfs99]

@ nesk: Thanks for the response - good to know I'm not the only one.

Non-news: Fedora had an update from 2.3.3 to 2.3.4 on my desktop client. I verified that this had no effect on the issue.

I'll try to attach packets captured (on the client) during mount while things were broken. The client is asrock-1a@192.168.1.3. The server is srvalot@192.168.1.79. I gave the file an extension of .dmp. I think it might be called the "old tcpdump format"
$this->bbcode_second_pass_code('', '# tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
OpenSSL 1.1.1c FIPS 28 May 2019
# tcpdump -i enp0s25 -w stalenfs-aa.dmp host srvalot
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
^C185 packets captured
185 packets received by filter
0 packets dropped by kernel')
I'm guessing this must be an arm-only / corner / non-x86_64 issue or it would have been caught sooner / elsewhere. It would be nice to confirm that. No point in configuring my fedora30 system as a server since it is at rev 2.3.4. I have a second drive on my system (with OpenElec, not booted to in months) that I might nuke and install Arch. But no time for that today.

[hfs99]

[edit} There is a longer thread on this issue in Development/Packages, which is probably where it belongs

second attempt at previously mentioned attachment. Apologies for any duplication.

Oh wait. Now I see it says extension .dmp is not allowed.
Trying .pcap... No.
.bin? No.

Unless I'm going to give it a .jpg extension I guess it has to be hosted offsite
https://overtracks.com/sos/20190625/stalenfs-aa.dmp

[pachulo]

I think that I'm also facing this on my Pogoplug v4, but I dumbly cleaned the cached packages...could somebody upload nfs-utils & nfsidmap arm version 2.3.4-1?
Thanks a lot!

EDIT: Nevermind, I found them here:
http://tardis.tiny-vps.com/aarm/packages/n/nfs-utils/
http://tardis.tiny-vps.com/aarm/packages/n/nfsidmap/