Hello All, With autofs on Red Hat/Centos, the" /net -hosts" special map allows all NFS resources exported by all accessible NFS servers to get mounted under the /net directory without explicitly mounting each one of them. E.g. accessing /net/host1 will instruct autofs to mount all available resources on host1. At first, it didn't work. E.g. if I run cd /net/host1 I have always got "No such file or directory". After running tcpdump to analyse the packets, I discovered that this particular feature uses sunrpc (port 111) and a random UDP port (30000 above). The problem is how I set iptables rule for this random port. I know I can specify a port range like --dport 30000:60000, but this is not a safe way to configure a firewall. Cheers, Bill
Hi Bill. A quick google for "nfs firewall" gives the following link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/... (The above link will probably wrap or be split somewhere along the way.) You can tie down the port range to suit your requirements. See the above link for details. Regards, Morrie. On 13/06/2014 9:57 PM, Bill wrote:
Hello All,
With autofs on Red Hat/Centos, the" /net --hosts" special map allows all NFS resources exported by all accessible NFS servers to get mounted under the /net directory without explicitly mounting each one of them. E.g. accessing /net/host1 will instruct autofs to mount all available resources on host1.
At first, it didn't work. E.g. if I run
cd /net/host1
I have always got "No such file or directory".
After running tcpdump to analyse the packets, I discovered that this particular feature uses sunrpc (port 111) and a random UDP port (30000 above). The problem is how I set iptables rule for this random port. I know I can specify a port range like --dport 30000:60000, but this is not a safe way to configure a firewall.
Cheers,
Bill
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Jason White <jason@jasonjgw.net> writes:
Morrie Wyatt <morrie@morrie.id.au> wrote:
You can tie down the port range to suit your requirements.
NFSv4 can run over a TCP connection instead of UDP, if you prefer.
So can NFSv3 and, I think, NFSv2. I *think* it's even the default under Linux. These might help (the assignments are arbitrary): # Make NFS use static ports echo 'STATDOPTS="--port 32765 --outgoing-port 32766"' >>/etc/default/nfs-common echo 'RPCMOUNTDOPTS="-p 32767"' >> /etc/default/nfs-kernel-server echo 'RPCRQUOTADOPTS="-p 32769"' >> /etc/default/quota echo 'options lockd nlm_udpport=32768 nlm_tcpport=32768' >>/etc/modprobe.d/options.conf As at Debian 7 I must also explicitly pass -o nfsvers=3 to mount on the client side, or it spends ten seconds trying to initialize gss.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 16 Jun 2014 11:02:27 AM Trent W. Buck wrote:
Jason White <jason@jasonjgw.net> writes:
NFSv4 can run over a TCP connection instead of UDP, if you prefer.
So can NFSv3 and, I think, NFSv2.
Pretty sure TCP support was introduced to the standard with v3.
I *think* it's even the default under Linux.
The manual page for nfs(5) says: If no transport options are specified, the Linux NFS client uses UDP to contact the server’s mountd service, and TCP to contact its NLM and NFS services by default. If the server does not support these transports for these services, the mount(8) command attempts to discover what the server supports, and then retries the mount request once using the discovered transports. cheers, Chris - -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEVAwUBU6bFRI1yjaOTJg85AQKZ9Af/brE3iSqw7esGIya0o7rvw5Ue5Q7lg9cz pLtAtKEnyYlpdq09gut3LLoxxZreTOqUG+UbbbJ1u/iyI9yB2tXyQ99IozWmV6E0 rUk/g+i+rS/7aU6v85E6HXjCvZV2cQamHLa09VyQqWq7NRaYHnSUsFP/1ApMtfYX kZVx/6plLWwii/0gZooK/otVkAtqlyDqW6zOM75j4qbYkT6SSfaRkFbc7PzdObhV nY+hik+AHc9NhEzBWIYvn4X/ef/rkDSG0F1o7przsuJb0mRFF277UrG3q70D+OsM MzrpcQznjHDUhZD+w2cx6fnP6e3NphYvE8cLGo4kQc5XH8Voplz0Xg== =zOeE -----END PGP SIGNATURE-----
participants (5)
-
Bill -
Chris Samuel -
Jason White -
Morrie Wyatt -
trentbuck＠gmail.com