Thanks for the report but there are a lot of variables here that make this very difficult to act on. First, there have been many changes in macOS 10.15 regarding file permissions and file system layouts (with APFS et al) and further changes in the more recent versions of macOS, 11 Big Sur and now 12 Monterey. Further, Python 3.7 is now in the security-fix-only phase of its life cycle which means we no longer produce binary installers for macOS or Windows for 3.7. 3.7.9 was released prior to the official release of macOS 11 and so, as noted on the changelog for 3.7.9, macOS 11+ is not fully supported by 3.7.x. We have also learned more about these operating systems since then and there are changes in Python and in how we manufacture python.org macOS installers that are reflected in current releases of Python 3.9.x and 3.10.x. Beyond that, AFAIK, we do not do any testing of macOS NFS clients or servers and have no setup for that at hand. And throwing in a third-party extension module (shiboken2.abi3.so) plus use of @rpath on top of all that adds even more variability.

My suggestion is to try to reproduce this with a current, fully-supported python.org macOS installer download (i.e. the 3.10.2 universal2 installer) and preferably on a current version of macOS, currently 12.2 or possibly 11.6.3, and also check "System Preferences" -> "Security & Privacy" -> "Privacy settings" like "Full Disk Access" and "Files and Folders"; if problems persist, try doing some dynamic loader debugging using the DYLD_* environment variables documented in the macOS dyld man page (man dyld). Otherwise, as your issue stands now, it seems unlikely that anyone here would be willing to invest the significant time to try to reproduce and debug what seems to be an unusual macOS configuration with out-of-date OS and Python versions.

Perhaps a simpler option is to just avoid use of NFS file systems on macOS for this purpose.

Sorry I don't have a more positive answer for you.