This was reported on ntirpc at Github. After DanG's fix for transport reference counting, Gaurav Gangalwar wrote that s/he can deplete the available fds with: for i in {1..1000}; do echo $i; mount -t nfs -o vers=3,tcp :/export /mnt; umount /mnt; done There is a configurable parameter limiting the number of concurrent fds. They are cleaned up after a fairly long inactivity timeout. So an adversary (or runaway client) can quickly deplete the fds, preventing valid clients from mounting. The most obvious patch would be for umount to add the same SVC_DESTROY line that DanG (and previously me) had added for the TCP well known ports in dispatch. But that would allow runaway clients to flood the server. Preventing that seems to be the (undocumented) purpose of the configurable parameter. The parameter and cleanup code are relatively old, and added to ntirpc circa 2013. Was it a bad idea? Which security issue is more important?