我正在运行 CoreOS EC2 实例。我在此实例上运行一个侦听本地端口 950 的进程。通常，一切正常，但在最近重新启动 CoreOS 服务器后，该进程无法侦听端口 950，因为它已被另一个进程占用。
另一个进程似乎是用于挂载 AWS EFS 卷的 NFSv4 客户端。这是 netstat 告诉我的：
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.30.102.250:950 10.30.102.170:2049 ESTABLISHED
这是的相关部分/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
几个问题： 1. 为什么 CoreOS 服务器上的 NFS 客户端使用低编号端口与远程 NFSv4 服务器通信？2. 我可以告诉 NFS 客户端避免使用端口 950（或仅使用非特权端口）吗？
（以下答案在很大程度上源自 Jeff Schaller 对我的原始帖子的评论。）
为了防止非 root 用户挂载 NFS 卷，NFS 服务器可以要求 NFS 客户端使用特权端口 (1-1023)。然而，如今只允许 root 用户挂载 NFS 卷几乎没有什么安全性，因为任何可以将机器放在网络上的人都可以成为该机器上的 root。
由于这种旧的安全实践，一些 NFS 客户端在连接到 NFS 服务器时将默认使用特权端口。
如果您的客户端需要在特权端口上运行服务，这可能会导致端口冲突。解决此问题的一种方法是设置 NFS 客户端将使用的最小和最大特权端口，以便 NFS 客户端将避免其他服务使用的端口。这个端口范围可以设置为内核参数；在 CoreOS 中，这些参数可以存储在文件/sys/module/sunrpc/parameters/min_resvport和 /sys/module/sunrpc/parameters/max_resvport.
您可以通过在挂载 NFS 卷时添加一个选项来完全避免整个特权端口问题，告诉系统使用非授权端口。对于 Linux，这是一个noresvport选项（另请参见Linux nfs(5) 手册页）。
这是我们最终在 CoreOS 服务器上使用的 mount 命令：
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