NFS mount fails with no error on client or server

I export a share from an AWS instance, running Amazon linux. I mount it on a couple different FreeBSD machines, one running 12.0, one running 11.2. NFS is not open to the internet, this happens across a VPN link. Both clients exhibit the same behavior, the initial mount works fine and everything works normally until the mount is inaccessible after less than an hour. Running ls shows "permission denied" when trying to read the mount point. There is no error in the system log on either client or server when the mount becomes inaccessible. Unmounting and re-mounting the share makes it immediately work fine again until another hour passes. I've tried tcp and udp options for the NFS mount, no difference.

Does this sound like a problem with NFS or with OpenVPN? This same OpenVPN config has been in place for years and otherwise works fine. This same NFS export/mount worked years ago but I haven't used it again until recently. Where should I start?

Thanks!
 
Are you using NFSv3 or v4? NFSv4 is a little easier to route/firewall. Speaking of firewalls, are there any in between the server and client? Maybe an AWS policy?
 
Tried both, same either way. No firewall, just VPN. This morning I decided to try mounting this share with sshfs. No problem there, it's been mounted all day so far. I'm starting to think there's some undocumented limitation with AWS and NFS.
 
Running ls shows "permission denied" when trying to read the mount point. There is no error in the system log on either client or server when the mount becomes inaccessible.
Re-reading this. This doesn't sound like an NFS/networking issue. If there are connection problems with NFS (either version) it's going to complain about it, a lot. You get stalls, accessing the filesystem just hangs. Maybe eventually even time-outs. When the connection is restored everything just continues as if nothing happened. I've never gotten a permission denied. Is that the actual error you're getting?
 
Well doesn't this always happen. It's made a liar out of me. When this fails I see this in the syslog now:

Aug 13 15:40:28 work kernel: newnfs: server '192.168.2.1' error: fileid changed. fsid 0:0: expected fileid 0x1400001, got 0x2. (BROKEN NFS SERVER OR MIDDLEWARE)
 
The mount point is 'cloud' and this is what happens when I ls in that dir:

lsdenied.png
 
I'll update this later but I think this was the problem, /etc/exports on the server was written like so:

Code:
/data/cloud       192.168.2.0/24(rw,sync,no_root_squash)

and the client was confused on filesystem id.
 
Nope, that's not it either. I wonder if Amazon Linux doesn't do regular NFS anymore since they built their own product on top of it.
 
Back
Top