I simply refuse to believe this is somehow not a feature, I need to get NFS to stop listening on the IPv6 addresses of a server, and also restrict which of it's IPv4 addresses it listens on as well.

I've been researching for hours but I just keep landing on the same four or five answers across different sites that provide no relevant solution.

When I run lsof -i -P on the server I can see NFS has opened more then just a few ports:

rpc.mount 7609 root    8u  IPv4 124179      0t0  UDP *:34231
rpc.mount 7609 root    9u  IPv4 124181      0t0  TCP *:55443 (LISTEN)
rpc.mount 7609 root   10u  IPv6 124183      0t0  UDP *:46874
rpc.mount 7609 root   11u  IPv6 124185      0t0  TCP *:55829 (LISTEN)
rpc.mount 7609 root   12u  IPv4 124187      0t0  UDP *:52359
rpc.mount 7609 root   13u  IPv4 124189      0t0  TCP *:37975 (LISTEN)
rpc.mount 7609 root   14u  IPv6 124191      0t0  UDP *:41861
rpc.mount 7609 root   15u  IPv6 124193      0t0  TCP *:33973 (LISTEN)
rpc.mount 7609 root   16u  IPv4 124195      0t0  UDP *:40059
rpc.mount 7609 root   17u  IPv4 124197      0t0  TCP *:50589 (LISTEN)
rpc.mount 7609 root   18u  IPv6 124199      0t0  UDP *:40265
rpc.mount 7609 root   19u  IPv6 124201      0t0  TCP *:35625 (LISTEN)
rpcbind   8103 _rpc    4u  IPv4  13941      0t0  TCP *:111 (LISTEN)
rpcbind   8103 _rpc    5u  IPv4  71849      0t0  UDP *:111
rpcbind   8103 _rpc    6u  IPv6  13945      0t0  TCP *:111 (LISTEN)
rpcbind   8103 _rpc    7u  IPv6  23221      0t0  UDP *:111

I need all the IPv6 ones to go away and change the IPv4 ones from listening on * to listen on,, and

Ineffective Method #1:

According to https://wiki.debian.org/NFSServerSetup, I could achieve this by modifying /etc/default/nfs-kernel-server to contain this line:


Apon restarting both rpcbind and nfs-kernel-server the output of lsof -i -P remains unchanged, it displays the same information as shown in the sample above

Ineffective Method #2:

To at least fix rpcbind, the file /etc/default/rpcbind states the following:

# Uncomment the following line to restrict rpcbind to localhost only for UDP requests
#OPTIONS="${OPTIONS} -h -h ::1"

I tried uncommenting that line and replacing it with this:


Not only did the output of lsof -i -P remain the same after restarting both services, but htop also showed that the physical command executed by systemd to start the service was, quite literally:

/sbin/rpcbind -f ${OPTIONS} -h

I tried manually substituting ${OPTIONS} with the correct value in the file, like this:

OPTIONS="-w -h"

Which correctly set the command run by systemd to this, as seen in htop:

/sbin/rpcbind -f -w -h

But still, the output lsof -i -P remains exactly the same as it was at the top of this post, all ports are still open on all IPv4 and IPv6 as both TCP and UDP, giving me a lot of paranoia knowing the machine can be accessed globally over it's IPv6 addresses

Ineffective Method #3:

I'm supposed to edit /etc/nfs.conf and define host=, but this appears to only be the method for all the more prestigious linux distros out there. I've always preferred headless debian for servers and I'm not looking to just uproot my entire infrastructure and install an entire different distro on my main file storage server to solve this because that would take a week of downtime and messing around which I just do not have

Ineffective Method #4:

Make a script to auto-config iptables to block the specific ports opened each time the service is restarted.

No, I'm not doing that, that's ridiculous. I refuse to believe there isn't a way to just correctly change the bind address like any other network enabled service allows you to do in 2022.

Other Issues:

Systemd already listens on the four :111 addresses with it's own 'rpc' service as well. From what I understand rpcbind should not be able to start when systemd's service already has the ports bound, yet it clearly does. Assuming this is a bug, which process receives any connections to port 111 in this broken state? How do I disable systemd from opening these ports? I don't need systemd's rpc stuff sitting around waiting for someone to hack either.

Someone please tell me what's going on here, I wasted half a day on this

  • I tried ineffective method #1 and it works-for-me (tm) after restarting nfs-kernel-server: NFSD got listening only on the addresses specified by -H and stopped listening to INADDR_ANY or in6addr_any. Of course this didn't affect portmapper itself on port 111, nor rpc.mountd . AFAIK If using NFSv4 only, rpc.mountd is still needed locally by nfsd, but not by the clients anymore, so it can be firewalled. rpc.mountd is the one using all these ports: 2 (ipv4+ipv6) x 2 (udp+tcp) x 3 (protocols 2 3 4)
    – A.B
    Sep 11, 2022 at 15:03
  • As a matter of fact, using options -N 2 -N 3 for rpc.mountd will remove these 12 ports. Now about nlockmgr (which is probably not needed anymore with NFSv4) ... dunno . Actually talking about NFS v4.1 not sure about 4.0
    – A.B
    Sep 11, 2022 at 15:17
  • And my last comment. Specifically for NFSv3 firewalling on Linux (rather than configuration change) see conntrack-tools.netfilter.org/manual.html#helpers
    – A.B
    Sep 11, 2022 at 17:56
  • @A.B so I'm looking into rpc.mountd some more and now I don't even know how -H worked for you, much less why it doesn't work for me in that case. According to linux.die.net/man/8/rpc.mountd, and also 'man rpc.mountd' in my server, the -H option is to "Specify a high availability callout program. This program receives callouts for all MOUNT and UNMOUNT requests. This allows rpc.mountd to be used in a High Availability NFS (HA-NFS) environment.". Obviously this has nothing to with setting the host address. So clearly the Debian wiki is outdated. What version of Debian are you on?
    – LAX1DUDE
    Sep 12, 2022 at 6:42
  • Is it Debian 11 or some other version/distro. It doesn't look like -H has been supported in over a decade based on all the manpages I've been able to find online, and I am yet to find an rpc.mountd manpage that ever describes that a -H option does exist.
    – LAX1DUDE
    Sep 12, 2022 at 6:42

2 Answers 2


Although the manpage doesn't say, attempting to change the rpc.mountd listen address on Debian seems to only have an effect if the NFSv2 and NFSv3 disable flags are passed in the service's config.

I am, shamefully, using NFSv3, and on closer inspection the Debian wiki has these -N 2 and -N 3 flags in the example and says that part of the command is to change it for NFSv4. This issue with this is though at if we check manpages.debian.org and also man rpc.mountd there is actually no mention of an -H or -N argument being available.

It directly sates that the -H and --ha-callout prog option is in fact meant to:

Specify a high availability callout program. This program receives callouts for all MOUNT and UNMOUNT requests. This allows rpc.mountd to be used in a High Availability NFS (HA-NFS) environment.

In fact all versions of the manpage state this is the only function of -H

So I don't know what's going on here for sure, but I guess the Debian wiki was correct and I just didn't understand that this wouldn't work unless NFSv2 and NFSv3 are disabled. It's real strange though for the Debian wiki to contain information that has never been a part of the manpage for any version I've been able to dig up. The manpage basically threw me off completely to not trust the Debian wiki even though it turns out the information on it was actually 'correct'.

  • The correct man about -H (as --host) is man rpc.nfsd
    – A.B
    Sep 13, 2022 at 16:41

I had success on Debian 11 making nfsd listen only to the interface I wanted by setting RPCNFSDOPTS="-H 10.x.y.z -N 2 -N 3" on /etc/default/nfs-kernel-server.

/etc/default/nfs-kernel-server is sourced from /usr/lib/systemd/scripts/nfs-utils_env.sh and RPCNFSDARGS is set with whatever is in RPCNFSDOPTS and then some, specifically:


nfs-utils_env.sh is invoked and spits out its variables to /run/sysconfig/nfs-utils, and from there, the unit file that starts nfsd, /lib/systemd/system/nfs-server.service reads them and honors RPCNFSDARGS:

ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS

So the neatest way I found to do what you describe (which incidentally, I, too, didn't want to believe was not possible in the times we live) is to set RPCNFSDOPTS as described above, even though it is not mentioned there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .