Niels de Vos wrote: On 04/23/2012 06:22 PM, Chuck Lever wrote: > > So you did check the mail archive? I seem to recall other patches like > this in the past, and that there is a reason why rpcbind works this way. > I simply don't remember the specifics right at the moment. I did, but no messages about this subject come up for me... Maybe I'm looking in the wrong places :-/ I asked about this last November, and at that time Chuck referred me to the mail archive too. I couldn't find any discussion either. But the behavior is intentional, so I don't think you'll get a patch accepted. I never did discover the reason but I do have a workaround. I just don't run rpcbind. This was the most informative response I got: Date: Tue, 8 Nov 2011 19:01:51 +1100 From: Max Matveev <makc@xxxxxxxxxx> Subject: Re: rpcbind -h To: Jim Rees <rees@xxxxxxxxx> Cc: Chuck Lever <chuck.lever@xxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx Chuck's quote from the manpage reminded me - -h was used to work around the address selection: if server has more then one address the reply may use any of them. Some clients don't like it. This issue should go away after commit 74ef3df0236c55185225c62fba34953f2582da72 Author: Olaf Kirch <okir@xxxxxxx> Date: Wed Mar 2 10:09:24 2011 -0500 was added to libtirpc. rees> As I said before, I was hoping for the equivalent of "portmap rees> -l". I was ready to code up a patch of some kind but now have rees> a workaround (mount with nolock and don't run rpcbind at all). iptables is another option. max -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
