NFS broken in Sequoia 15.6

I don't have any unusual options in my NFS server settings on the Mac - no added switches, just the defaults. And my /etc/exports is exactly as posted in the OP. My local network is controlled by an Arris cable modem - but the settings you suggested to check are not options the modem's admin web page even displays. I did check the basic network setup and noticed that the starting address for Wi-Fi had defaulted to a value that conflicted with both the Linux box and the Mac (both connect via ethernet), so I fixed that - but none of my devices/appliances that use Wi-Fi that I'm aware of had been assigned conflicting addresses, and anyway an IP address conflict would affect more than just NFS.

I'll look further into SMB - for now, I've removed the backup share from /etc/fstab and disabled the cron job. I gather from a quick web search that SMB is supported in the MacOS kernel, and the mount command on the Linux box does support -t smbfs, so hopefully the switch will be painless. Thank you for your input.

You're making a lot of assumptions about what I'm running there. Why don't you ask questions instead of assuming what I'm doing or not doing?

First, just to clarify: my NFS server settings are the defaults on MacOS, so it's possible that something did change there as I've never made any customizations on the NFS config files, other than my /etc/exports.

Also: there is no 3rd party security or networking software running on my network, other than on the Arris modem itself. I use the modem's firewall with all external ports blocked. This is all determined by my ISP - I do not have a lot of choice as to networking hardware.

That's what I intend to do, try switching to SMB. I'm not sure whether Bridged mode is supported, but regardless, I'd have to think hard before choosing to use my own modem instead of the ISP-provided unit. The main issue is availability: in case of hardware failure (which has happened more than once) I'd be on my own to replace the modem or have it fixed. I could be several days without network access at home, and the lost time is something I can't afford. The ISP, on the other hand, normally replaces the modem either the same day or the next business day.

Right, and if I was a business, that might be the best option, but buying *two* modems to ensure system availability is a bit above my budget. If absolutely necessary I would do it - but I'm not yet convinced the problem is in MY network and not some default setting in MacOS that changed in 15.6.

Trying SMB is a nonstarter I'm afraid - mount -t smbfs on the Linux box returns "unknown filesystem type", despite the mount(8) man page listing -t smbfs as supported. There is no mount_smbfs command either.

I have unplugged the Ethernet dongle, reserved a fixed IP address for the Mac's WiFi address on the router, and tried nfs-mounting the exported filesystem over WiFi. Unlike over ethernet, the mount command takes several seconds to return. At this point that's about all I can try without upgrading my Linux installation to a version that actually supports SMB, and I won't have time to do that now for a few months.

I should know sometime today (hopefully) whether the mount goes stale or not.

Edit: it went stale in <5 minutes. So there is apparently no solution. Sigh.

cifs-utils is installed (always was) and mount -t cifs is supported - but it doesn't work, at least not with the command line I've been trying. This is what I get:

% sudo mount -t cifs -v //macbookpro/Volumes/Passport/backup /mac/backup -o username=lise

Password for lise@//macbookpro/Volumes/Passport/backup: *********

mount.cifs kernel mount options: ip=192.168.0.3,unc=\\macbookpro\Volumes,user=lise,prefixpath=Passport/backup,pass=********

mount error(2): No such file or directory

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Is this the wrong syntax? It's correctly resolving the ip address for macbookpro, but the shared filesystem on the Mac is /Volumes/Passport/backup. The mount point /mac/backup exists on the Linux machine, so "no such file or directory" can't refer to that. I would think //macbookpro/Volumes/Passport/backup should be the UNC, but it appears to be interpreting the first two fields as comprising the UNC and the rest of the service name as a pathname. My guess is that the problem is that either my UNC syntax or my choice of filesystem to share is incorrect, but I don't know how to fix it.

(BTW, on my system, with a dead mount point, umount -f doesn't work - it just returns filesystem busy.)

This appears to be the solution. The mount stayed alive overnight, and I checked to make sure that files written on the share by the Linux machine's root user are owned by root and not by my personal account on the Linux box. (They are owned by me as seen by a user on the Mac, of course.)

The only negative is that I had to return to connecting via Ethernet because for some reason, WiFi connections and file transfers are painfully slow - under 1 Mb/s between hosts on the LAN, an order of magnitude slower than via Ethernet. Transfers with the outside world and even web browsing are slower yet - unacceptably slow. Not sure what the cause is, but it's a separate question that I'll post if I'm ever forced to go back to connecting via WiFi. (I am not even certain it's a MacOS issue, and may well be a problem in the cable modem/router.)

Thanks to all who replied, but especially to @etresoft for his invaluable help.

But what changed in the latest OS update? Why does this not work anymore?