NFS-Client using NAT

[Sven_]

Hi,
I installed Kubuntu 12.04 as guest on a Windows 7 host. The computer is connected to a NFS server (which works for other, non-virtual systems in the lan) and I want to set up the guest as NFS client. I don't want to use a second IP for the client, so I use NAT as the networking method. The basic networking runs fine (I have internet-connection, can ssh from the guest to other machines, use ldap, and, with portforwarding also ssh from other machines to the guest).

When I try to mount a nfs-share, the server denies permission, the error-message, from the syslog of the server is

Code: Select all

rpc.mountd: refused mount request from <guest> for /nfsshare (/nfsshare): illegal port 5xxxx

This, as I read so far, means, that my guests nfsd uses a port >1024, to try to mount the share. As a possible solution I found, that I can use the insecure-option for exporting, but I do not really want to. Since this happens even with the mount-option resvport, which should force nfsd to use a privileged port, I guess it has something to do with the NAT portforwarding. At the moment I have no rules there (I tried to forward 2049 (nfsd) and 111 (portmapper), I read it somewhere, but it didn't help).

I'd be happy about any advice, how I could get this running...Sven

[noteirak]

The issue is, if I remember correctly, that your NFS server is not using a priviledged port, and so the nfs client is not happy about it. The only way to make it work is using insecure-option.
It has nothing to do with Virtualbox tho.

[Sven_]

Hmm...thanks, I'm not too sure myself, but I do believe, it's an issue, somehow related to NAT, and I'm quite sure it's the server, which doesn't (and shouldn't) allow the insecure ports, here's the verbose output of the client:

Code: Select all

mount.nfs: timeout set for Mon Apr 29 10:05:05 2013
mount.nfs: trying text-based options 'vers=3,soft,resvport,addr=192.168.0.2'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.0.2 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.0.2 prog 100005 vers 3 prot UDP port 42077
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting server:/share

• The 'insecure' option is made in the exports of the server. On the client I only have '(no)resvport', which tells the client whether it should try using a insecure port. From man nfs: "Using non-privileged source ports helps [...], but NFS servers must be configured to allow clients to connect via non-privileged source ports."
• For setting up the guest Ubuntu I used a script, which was used for other, non-virtual machines, too, and the, therefore, same konfiguration works for the other ones.

Edit: For testing purposes I used the network bridge now, and I was able to mount the share without changing any option (except giving myself an ip...). So it has to be something caused by NAT...

[noteirak]

Don't forget that you're doing NATing - which means that the source IP & port is rewritten and then sent out. If you require a specific range of source port from the client, you're out of luck I am afraid since it goes against the idea of NAT in the first place.

[Sven_]

But I can do portforwarding, in some way - shouldn't it be possible to maybe bind the nfs to one port and forward this one? Seemingly the choice of the port is done by the client, since the server wouldn't use a port it does not allow, I guess...

[noteirak]

Portforwarding is only for new incoming connections, not for outgoing. Since your client is the VM, you'll only get outgoing, and NAT is no help to you on this matter.
You'll need to switch to Host-Only or Bridged if you want the nfs client to control the source port used.

And I am still not convinced about this whole story TBH - It would be the first time I see a server carring about which port the client port is using on its side. The only thing the server would care about is what port is used as destination.

In any case, this whole issue is not a Virtualbox one, and will not be supported here.

[Sven_]

The server cares, because a sourceport <1024 tells it, the query comes from a system process, as far as I understand it.

But probably you're right and the problem is, that one has no influence on the outgoing port it is mapped to and I have to use one of the other ways... :/
Thanks anyways.

[noteirak]

It doesn't make sense for the server to care for a port under 1024 used by the client. The client is supposed to be used by userland processes normally, generally on the request of a user.
Why would it be limited to under 1024? It just doesn't make sense.
It only make sense for the server side for the port listening, as this follow a standart and is limited so a user cannot impersionate a real server for whatever reason.

[Sven_]

The insecure option in this entry also allows clients with NFS implementations that don’t use a reserved port for NFS.

As far as I understand it, it's to avoid normal users beeing able to impersonate the nfs-client, which, in this case is much worse, than impersonating the server, since you could gain access to all the exported files. But this is only my guess...

[noteirak]

Fair enough - I am not using NFS enough to have checked the implementation, so this is very much possible indeed.
Sadly, it does means that you're going to have a very hard time to make it work using NAT, if it ever works.

[MikeMondy]

In case anyone else looking for a solution to using NFS services from a guest that's using NAT...

I see a solution in the manual ... but it doesn't seem to work.

There is a setting for this, but it's only available as a command line option; it's not in the GUI. Run the following command: VBoxManage modifyvm VMNAME --nataliasmode# sameports. For example, with a VM named myguest and with only a single natnetwork in use, run: VBoxManage modifyvm myguest --nataliasmode1 sameports. I also tried "proxyonly" in addition to "sameports".

Using "sameports" is supposed to allow the guest to make requests from a privileged port and have the VirtualBox NAT engine *not* translate the privileged port to another arbitrary (and likely unprivileged) port.

However, network traces in the guest and on the NFS server reveal that the guest is using low numbered ports but they are still being NATted to high numbered ports.

[Vasily]

Actually you don't need to touch NAT settings to access NFS share, all you need is to configure your nfs server in specific to your OS way ,e.g. on my ubuntu server

Code: Select all

vvl@build:~$ grep export /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
/export       *(rw,sync,insecure,no_subtree_check) 
/export-1       *(rw,sync,insecure,no_subtree_check)

and this is on my mac

Code: Select all

vbox-lwip-uwe-trunk-release(2)# cat /etc/exports 
/Volumes/export -ro 

and my fresh installation of OL access both resources with autofs (with almost default configuration: just uncomment /net in /etc/auto.master )