6

I am running a CoreOS EC2 instance. I run a process on this instance that listens on local port 950. Usually, everything works fine, but after a recent reboot of the CoreOS server the process could not listen on port 950 because it was already taken by another process.

This other process appears to be an NFSv4 client that is used to mount an AWS EFS volume. Here is what netstat tells me:

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 10.30.102.250:950       10.30.102.170:2049      ESTABLISHED

Here is the relevant part of /etc/mtab:

fs-faa33256.efs.us-west-2.amazonaws.com:/ /efs nfs4 rw,relatime,vers=4.1,\
rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,\
clientaddr=10.30.102.250,local_lock=none,addr=10.30.102.170 0 0

A couple of questions: 1. Why is the NFS client on the CoreOS server using a low-numbered port to communicate with the remote NFSv4 server? 2. Can I tell the NFS client to avoid using port 950 (or use only non-privileged ports)?

rlandster
  • 723
  • 1
  • 8
  • 22
  • 1
    I can't test it, but if you have `/sys/module/sunrpc/parameters/min_resvport` that may help; see https://serverfault.com/a/372751/293440 – Jeff Schaller Oct 15 '17 at 01:58
  • see also the [linked nfs page](http://nfs.sourceforge.net/nfs-howto/ar01s06.html#sec_portmapper) about why the NFS client uses low-numbered ports – Jeff Schaller Oct 15 '17 at 02:00
  • The output of `cat /sys/module/sunrpc/parameters/min_resvport` is `665`. – rlandster Oct 15 '17 at 02:07
  • Might try changing that to 951 – Jeff Schaller Oct 15 '17 at 02:30
  • I will try it. Assuming that the NFS server does not have a problem with it, is there any reason not to set `min_resvport` to 1025? – rlandster Oct 15 '17 at 02:33
  • On that assumption, no; and just for completeness, I would say you could either set min_resvport to 951 (allowing ports 951..1023) or max_resvport to 949 (allowing ports 665..949) -- lowering max_resvport would provide more allowable ports, if you need them. – Jeff Schaller Oct 15 '17 at 02:41
  • Any success or failures to report? – Jeff Schaller Oct 20 '17 at 20:40
  • We did not end up changing the `min_resvport` file, rather, we used the option `noresvport` when mounting the NFS volume which says to use non-privileged ports. If we had made the change as suggested by your original comment, that would have solved the issue as well. Of course, if our security rules mandated using privileged ports we would have had to use your suggestion instead of the `noresvport` option. Your original comment lead us to our solution, so we owe you thanks. – rlandster Oct 22 '17 at 01:22

1 Answers1

8

(The following answer is derived in large part from Jeff Schaller's comments to my original post.)

In order to prevent non-root users from mounting an NFS volume, an NFS server can require that an NFS client use a privileged port (1-1023). However, allowing only root users to mount an NFS volume offers little security these days as anyone who can put a machine on the network can be root on that machine.

Because of this old security practice, some NFS clients will default to using privileged ports when connecting to an NFS server.

This can cause port conflicts if your client needs to run a service on a privileged port. One way to get around this is to set the minimum and maximum privileged ports that the NFS client will use so that the NFS client will avoid ports used by other services. This port range can be set as kernel parameters; in CoreOS these parameters can be stored in the the files /sys/module/sunrpc/parameters/min_resvport and /sys/module/sunrpc/parameters/max_resvport.

You can avoid the whole privileged port issue altogether by adding an option when mounting the NFS volume telling the system to use non-provileged ports. In the case of Linux this is the noresvport option (see also the Linux nfs(5) man page).

This is the mount command we ended up using on our CoreOS server:

fs-faa33256.efs.us-west-2.amazonaws.com:/ /efs nfs4 rw,relatime,vers=4.1,\
rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,\
clientaddr=10.30.102.250,local_lock=none,addr=10.30.102.170 0 0
rlandster
  • 723
  • 1
  • 8
  • 22