Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

/srv 127.0.0.1(rw,sync,no_subtree_check,no_root_squash)

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?

Thanks!

EDIT

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.

share|improve this question

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.