Inside the VM, host address is 10.0.2.2, local address is 10.0.2.15. (VirtualBox). This gets translated to 127.0.0.1 on the host side. To connect:
sudo mount -vvvt nfs4 -o clientaddr=127.0.0.1 10.0.2.2:/srv /mnt
I specified clientaddr because I figured the problem could be due to the addresses not matching, but it doesn't change anything. After a few minutes the client returns the usual Permission Denied message, access denied by server.
On the server side, I run
# rpc.mountd -d all -F # rpc.idmapd -vvvf # rpc.nfsd -d
I use systemd, so I am also monitoring the journal for any output. When I make the mount request, the following is visible over the network:
reply ERR 20: Auth Bogus Credentials (seal broken)
but nothing appears in the journal (which should have the output of rpc.nfsd) or in the output of rpc.mountd or rpc.idmapd, aside from some startup messages. Actually, in the case of rpc.mountd, I get the following occasionally:
rpc.mountd: auth_unix_ip: inbuf 'nfsd 127.0.0.1' rpc.mountd: auth_unix_ip: client (nil) 'DEFAULT'
As far as I am aware (please correct me!) there is no other source for information about NFS's functioning, and there is also no configuration involved. I have specified the verbose modes for each command, so I'm at a loss for how I am supposed to diagnose this issue.
I am assuming that it is a problem with my exports file, which is as follows:
But I would rather actually get some feedback from the system about what is going wrong than fiddle with my exports file by trial and error. So, does anyone know where I can find out more about what's going on?
I recently ran exportfs -rav
and now the client immediately returns 'Operation not permitted', and rpc.mountd outputs:
rpc.mountd: auth_unix_ip: inbuf 'nfsd 127.0.0.1' rpc.mountd: v4root_create: path '/' flags 0x12401 rpc.mountd: v4root_create: path '/srv' flags 0x10401 rpc.mountd: auth_unix_ip: client 0x1d69d70 '127.0.0.1' rpc.mountd: nfsd_fh: inbuf '127.0.0.1 1 \x00000000' rpc.mountd: nfsd_fh: found 0x1d73e90 path /
but this output may just be related to having run exportfs. (Note that I restarted the daemons several times before, so I don't know how exportfs made a difference)
OK, it seems that adding the 'insecure' option has fixed it:
secure This option requires that requests originate on an Internet port less than IPPORT_RESERVED. (1024). This option is on by default. To turn it off, specify insecure.
This is odd, since I was running the NFS client as root.
In any case, why wasn't this issue made apparent to the operator (myself) ? I don't see how a piece of software can be considered fit for production use if its diagnostics are kept completely hidden, so as to render it inaccessible to non-experts.. I don't mean to bash NFS here, but it seems like a notoriously obfuscated system that could really use some more transparency given how frequently it is used.. Anyway thanks for reading.