[RndTbl] wacky NFS port problem
trevor at tecnopolis.ca
Mon Oct 24 03:44:59 CDT 2016
OK, this is a new one...
Updated my kernel and rebooted tonight. Everything came up fine.
Except dovecot (IMAP server). It complained:
Error: service(imap-login): listen(*, 993) failed: Address already in use
#netstat -tulpn | grep 993
#ss -t -l 'sport = 993'
A wasted hour later I did:
netstat -n |grep 993
Sure enough I had a tcp connection between my workstation and my file
server on 993 to 2049. grep 2049 /etc/services... eureka!
2049 is nfs.
>From what I've figured out, nfs, which I have mount something on boot,
randomly grabbed 993 before dovecot did, and was holding it as long as the
nfs fs was mounted locally.
And because nfs is in-kernel it didn't show up in lsof et al.
I umounted it, waited for TIME_WAIT to expire and then I could start
*** This has never happened before on dozens of reboots... I guess it's
pretty much luck / race condition what port nfs gets, especially with
systemd possibly trying to do the mount and/or dovecot in parallel. I
have no idea when it tries to do the mounts, but I'm guessing before
Note, I'm using NFSv4 which (unlike older NFS) uses TCP stateful in a
persistent connection. Pretty much everything you know about v2/v3 throw
away when it comes to using v4.
I poked around nfs docs and google and found this option:
resvport / noresvport
Specifies whether the NFS client should use a privileged source port when
communicating with an NFS server for this mount point. If this option is
not specified, or the resvport option is specified, the NFS client uses a
privileged source port. If the noresvport option is specified, the NFS
client uses a non-privileged source port. This option is supported in
kernels 2.6.28 and later.
Refer to the SECURITY CONSIDERATIONS section for important details.
OK, down there is a section:
Using non-privileged source ports
Which basically says using privileged ports is for security so normal
users can't make/fake their own daemons and pretend to be any user they
want. OK, so I know that's a bit hokey from a sec standpoint, but it's
better than nothing, I guess. Regardless, having nfs client pick a random
high port might hurt me also because I use some of them for my own
purposes/daemons and I need them open also.
The docs say this:
"The exact range of privileged source ports that can be chosen is set by a
pair of sysctls to avoid choosing a well-known port, such as the port used
Which would be perfect, except I can't find any further reference to these
magic sysctls. I tried searching my box's /proc and /sys fs's for nfs &
ports, nfs & priv, nfs & mount, etc. Couldn't find anything relevant.
It would be really nice if I could specify the local source port, or at
least specify the list of no-no ports using this elusive, promised,
"sysctl". Anyone have any ideas?
What a strange bug to run into. Chance of 1 in 1024 and it had to hit me.
More information about the Roundtable