NFS authentication error

J

jphartmann

Setup is an Ubuntu host with a VirtualBox that has a FreeBSD 12 client having a bridged network adapter. The Ubuntu host is connected to a FreeBSD 11 server (and other stuff) via a VPN tunnel.

I wish to mount an NFS directory on the FreeBSD 11 server. The server is reachable from BSD since the network is bridged, so I don't need to run a separate tunnel. Ping "works".

I get an error message on mount from BSD (no cut'n'paste from the Vbox):

RPC: Authentication error; why = Client credential too weak.

The server log contains

mountd[686]: mount request from 10.8.0.6 from unprivileged port

Wouldn't it be nice if the message included the remote port number? [hint, hint, nudge, nudge]

As far as I can make sense of the tcpdump (on the BSD client) of the interaction, the request goes out from the BSD client on port 842.

The Ubuntu side can mount OK and netstat shows

tcp 0 0 asus:909 fb111:nfs ESTABLISHED

I speculate that the Vbox bridge reassigns the source port. Can anyone confirm?

https://unix.stackexchange.com/questions/261541/rpc-authentication-error-when-mounting-nfs describes a similar problem. The guy eventually broke down and used Samba.
 
Check the requests going from vm to the server on port 111 (sunrpc), and compare them on both sides, i.e.: # tcpdump -n host <vm> and <server> and port sunrpc.
 
Keep in mind that FreeBSD 12, aka CURRENT, is an unsupported developer snapshot. There aren't even any guarantees that the thing will actually boot which is also roughly why it's unsupported and offtopic here. Its best use is for testing and bugfixing.

For all we know this could easily be caused by something not fully compatible within CURRENT.

(edit) There's no direct need to mention the port; unprivileged means that it will be a port > 1024 is all, which won't be the cause of your problems. Also: is this by any chance used inside a jail as well? Because that could definitely explain a thing or two: NFS inside a Jail is extremely tricky if not impossible.
 
The FreeBSD is indeed 11.2 that I downloaded from the BSD download site as a preinstalled system for VirtualBox &c.

The network connexion is actually NAT. Apologies for not double checking; I was building a number of virtual machines. Virtual Box documentation does not explain how the source port is assigned; perhaps it is left to the stack.

Using a bridged connexion would mean that I would need a separate tunnel to the main server.

As for mentioning the source port number in the error message: It is right there in front of the nose of the programmer; it costs only %d to show it. It might provide information for a poor sod, particularaly if it is different from what port was used at the other end. And you now tell me to use tcpdump to see it?
 
jphartmann said:
As for mentioning the source port number in the error message:
Click to expand...
Not trying to play the devils advocate here, but within this field details are important. This is not an error message but simply a log message, there's a big difference (error / debug messages would definitely benefit from providing more information).

jphartmann said:
It is right there in front of the nose of the programmer; it costs only %d to show it.
Click to expand...
In my opinion it would still have no place there. The main issue would be OSI; you're working on the application level and therefor getting information from the network level isn't necessarily productive. In this particular case you can be certain that it isn't relevant because the log entry itself is proof that a connection got established, any problems beyond that have nothing to do with the network but the application itself.

The other possible problem I see is that - depending on the way it's included - it could easily be mistaken for a PID as well. Port numbers are the kind of information you might want after you raised logging verbosity. Which, according to mountd(8), can be achieved with -d (sort off).
 
ShelLuser said:
Not trying to play the devils advocate here, but within this field details are important. This is not an error message but simply a log message, there's a big difference (error / debug messages would definitely benefit from providing more information).


In my opinion it would still have no place there. The main issue would be OSI; you're working on the application level and therefor getting information from the network level isn't necessarily productive. In this particular case you can be certain that it isn't relevant because the log entry itself is proof that a connection got established, any problems beyond that have nothing to do with the network but the application itself.

The other possible problem I see is that - depending on the way it's included - it could easily be mistaken for a PID as well. Port numbers are the kind of information you might want after you raised logging verbosity. Which, according to mountd(8), can be achieved with -d (sort off).
Click to expand...


NFS has already broken layer separation of concerns by concerning itself with the port number (which is ridiculous). I agree with the poster that there should be some diagnostic information. Though In this case I'm not sure if knowing the port number would help that much since the host/server presumably has working tcpdump, but maybe there's a situation where it would be helpful. In this case luckily mountd at least mentions the connection from an unprivileged port, which should be enough. I think there are some implementations that don't even say that, leaving the user to trial and error.


It seems that if NFS (in general, not just on FreeBSD) were better documented and had proper logging and diagnostics, we would not have hundreds or thousands of these 'authentication' issues all over the internet and who knows how many hundreds of thousands of man-hours would have been saved. A while ago I think I read one thread on serverfault or something where some guy spent weeks trying to get it to work, even took it to some local Linux gathering, and the people there spent an hour or so trying to find a log or some other useful information, and eventually gave up.
 
There's just not enough information to help you. I'd start with the: rpcinfo -p on the server to get the service/port. Then I'd go to client and try to reach server: showmount -e <server>. Make sure both client and server can resolve each other properly including the middle man who does NAT.

As NFS server is Linux it's kinda out of topic but FreeBSD (and of course other OSs too) allows you to specify ports for rpcbind, mountd, statd and other services you may need. You can debug as ShelLuser told you. You can also strace the daemons on Linux or truss (1) on FreeBSD.

In my setup I have it other way around. FreeBSD is NFS server and clients, among others, are also VirtualBox VMs.
 
jphartmann said:
Setup is an Ubuntu host with a VirtualBox that has a FreeBSD 12 client having a bridged network adapter. The Ubuntu host is connected to a FreeBSD 11 server (and other stuff) via a VPN tunnel.

I wish to mount an NFS directory on the FreeBSD 11 server. The server is reachable from BSD since the network is bridged, so I don't need to run a separate tunnel. Ping "works".

I get an error message on mount from BSD (no cut'n'paste from the Vbox):

RPC: Authentication error; why = Client credential too weak.

The server log contains

mountd[686]: mount request from 10.8.0.6 from unprivileged port

Wouldn't it be nice if the message included the remote port number? [hint, hint, nudge, nudge]
Click to expand...

This error is not as useful as it sounds.
It stands for "you can't mount this nfs share".
Check out for the validity of the request mount point:
  • It exists,
  • no symlinks within ,
  • not crossing any other filesystem,
  • not defined twice (don't be mistaken by zfs self exports that are also defined in /etc/exports),
  • users allowed to mount point (vfs.usermount)
  • etc.
And, make sure your firewall won't drop nfs packets, use fixed ports number for services like mountd(), and rpc tools.
Ask sockstat() and rpcinfo() to get an overview of the ports used.

You may also activate the " -n" flag to the mountd() command, to take time to solve the issue.
 
You must log in or register to reply here.
Back
Top