2

I have successfully set up a working NFS server/client system on my local network machines. I love it!

But, having grown weary of the long delay when a mount is not available during boot-time, I decided to take @ridgy up on his suggestion to use autofs to mount the shares instead - using the information from this post.

I had firewall issues before, So, I immediately suspected the ufw might be the reason for the mounts timing out. So, I disabled ufw on server and client. And, sure enough; That got autofs working nicely. So, I am sure the basic configuration is correct.

The only other rules in ufw at this point are ALLOW rules for ports 2078 and 6589. There are no BLOCK rules set up. And, since NFS works fine with ufw on during fstab-controlled mounting, I am a bit confused as to where the blockage is occurring.

So far, I haven't found documentation on what ports/protocols are unique to autofs besides the usual NFS 111,2049 TCP/UDP.

Whenever I re-enable ufw. The shares become inaccessible again.

Any ideas?


@ridgy

After following your advice below to edit nfs-common and nfs-kernel-server.. I triple checked, and the edits were made exactly as shown. I rebooted and ran...

$sudo netstat -nalp | grep rpc... The output was;

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1220/rpcbind    
tcp        0      0 0.0.0.0:32767           0.0.0.0:*               LISTEN      4158/rpc.mountd 
tcp6       0      0 :::111                  :::*                    LISTEN      1220/rpcbind    
tcp6       0      0 :::32767                :::*                    LISTEN      4158/rpc.mountd 
udp        0      0 0.0.0.0:972             0.0.0.0:*                           1220/rpcbind    
udp        0      0 0.0.0.0:32767           0.0.0.0:*                           4158/rpc.mountd 
udp        0      0 0.0.0.0:111             0.0.0.0:*                           1220/rpcbind    
udp6       0      0 :::972                  :::*                                1220/rpcbind    
udp6       0      0 :::32767                :::*                                4158/rpc.mountd 
udp6       0      0 :::111                  :::*                                1220/rpcbind    
unix  2      [ ACC ]     STREAM     LISTENING     15939    1/init              /run/rpcbind.sock
unix  2      [ ]         DGRAM                    49175    4158/rpc.mountd     
unix  3      [ ]         STREAM     CONNECTED     48294    1220/rpcbind        /run/rpcbind.sock
unix  3      [ ]         STREAM     CONNECTED     16984    1220/rpcbind        
unix  3      [ ]         STREAM     CONNECTED     48275    4157/rpc.idmapd     
unix  3      [ ]         STREAM     CONNECTED     48276    4157/rpc.idmapd 

OK... So, I wonder... Where is rpc.statd ??? Additionally, my NFS shares (autofs was still disabled) were still visible from the client. even though the firewall had not been updated with the new rpc.mountd port 32767.

  • Interesting twist: If I deactivate ufw... mount the shares... then reactivate ufw... I am able to access the shares until I reboot... or the lock screen kicks in... then the dance must be repeated. So, to me, it seems like a mountd port needs to be configured. But, "ss -ltp" does not show me any listening ports for mountd. Again... Above my paygrade. – Orian Feb 9 '17 at 13:26
  • 1
    Maybe this answer might help? Or the hint in this answer: "I would recommend issuing iptables -L -v before and after you issue the showmount command". – ridgy Feb 9 '17 at 14:10
  • Thank you. I have read both posts and implemented the firewall changes suggested in the first post. Nothing changed/improved after that. Then, upon reading the second post, I realized how incredibly complicated all this jury-rigging actually is. So, I am backing off of this project and going back to the fstab method. It really shouldn't be this complicated should it? NFS mounts were working fine. All I wanted to do was use autofs instead of fstab. It seemed so do-able at the time. Thank you for the information. I regret that I don't have enough understanding to accomplish this... yet. – Orian Feb 9 '17 at 23:37
  • The problem here is the 'portmapper'; once I knew how to configure for showmountworking with firewalls, if I find out again I will tell you. To solve your initial problem, you could enter option noauto with the NFS entry in the /etc/fstab and add the mount command to rc.local, or additionally add user to the mount options and manually mount after logging in as normal user. – ridgy Feb 10 '17 at 9:56
2

In the end itwas not that complicated, following the hints in Securing NFS. I modified the files /etc/default/nfs-common and /etc/default/nfs-kernel-server according:

nfs-common:

.
.
# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS="--port 32765 --outgoing-port 32766"
.
.

nfs-kernel-server:

.
.
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
RPCMOUNTDOPTS="--manage-gids --port 32767"
.
. 

Why those ports? As 32767 is the highest 15bit-number, it is very unlikely that these ports are already in use by something else.

I am not using quotas, so I did not modify /etc/default/quota as suggested. And I had to reboot after I made these changes. Then I saw the result with

$ sudo netstat -nalp | grep rpc

tcp        0      0 0.0.0.0:32767           0.0.0.0:*               LISTEN      1018/rpc.mountd 
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      735/rpcbind     
tcp        0      0 0.0.0.0:32765           0.0.0.0:*               LISTEN      806/rpc.statd   
tcp6       0      0 :::32767                :::*                    LISTEN      1018/rpc.mountd 
tcp6       0      0 :::111                  :::*                    LISTEN      735/rpcbind     
tcp6       0      0 :::32765                :::*                    LISTEN      806/rpc.statd   
udp        0      0 0.0.0.0:875             0.0.0.0:*                           735/rpcbind     
udp        0      0 127.0.0.1:982           0.0.0.0:*                           806/rpc.statd   
udp        0      0 0.0.0.0:32765           0.0.0.0:*                           806/rpc.statd   
udp        0      0 0.0.0.0:32767           0.0.0.0:*                           1018/rpc.mountd 
udp        0      0 0.0.0.0:111             0.0.0.0:*                           735/rpcbind     
udp6       0      0 :::875                  :::*                                735/rpcbind     
udp6       0      0 :::32765                :::*                                806/rpc.statd   
udp6       0      0 :::32767                :::*                                1018/rpc.mountd 
udp6       0      0 :::111                  :::*                                735/rpcbind     
unix  2      [ ACC ]     STREAM     LISTENING     11412    735/rpcbind         /run/rpcbind.sock
unix  2      [ ]         DGRAM                    9521     806/rpc.statd       
unix  2      [ ]         DGRAM                    9614     1018/rpc.mountd     
unix  3      [ ]         STREAM     CONNECTED     11721    862/rpc.idmapd      
unix  3      [ ]         STREAM     CONNECTED     11722    862/rpc.idmapd      

As you can see, the ports rpc.mountd and rpc.statd are listening to are now static.

When entering showmounton the client(here 192.168.192.20), Wireshark shows the communication (server is 192.168.192.111). Important here: The GETPORT Call and the GETPORT reply, which returns Port:32767. The communication then uses this port.

enter image description here Now you should be able to modify the firewall rules according, and then use showmountand autofs through firewall.

Just for the record

Following the hints in the comments and my own experience, I found different behaviour in different distributions:

  • In current raspbian jessie (based on debian), there is a service nfs-common (file /etc/init.d/nfs-common), which when enabled starts e.g. rpc.statd at boot, respecting the port settings in /etc/default/nfs-common.
  • In current Ubuntu 16.04 there is no such service. rpc.statdis not started at boot, as it is not needed with NFS V4. But as soon as mount .... -o nfsvers=3 is done, rpc.statd is started, respecting the port settings in /etc/default/nfs-common.

I did not find a consistent documentation on that; in How to configure NFS the file /etc/init.d/nfs-common is explicitly mentioned, although it is not in the package. If anyone has hints/links on that it would be richly deserved.

One more remark: man rpc.mountd and man rpc.statd say (for option --port):

"If this option is not specified, rpc.statd will try to consult /etc/services, if gets port succeed, set the same port for all listener socket, otherwise chooses a random ephemeral port for each listener socket."

Even when setting the ports in /etc/services (as suggested in the above mentioned wiki), this did not work. So modifying the files in /etc/default seems mandatory - the man pages are not correct at that point.

| improve this answer | |
  • Many thanks for the deep search there. <impressed>. I will try this later this weekend. I have disabled autofs for now... got to get some tax work done. i will get back when I have a chance to dig into this again. BIG Cheers! – Orian Feb 10 '17 at 14:41
  • Please see my edit above. The system does not seem to be honoring my settings. Everytime I Flush and Reboot... A different port is used... This time it is Also, I don't quite understand what is meant by the "Remark" in your answer. Also, I am still not seeing the rpc.statd in netstat. Perhaps my system is suffering from too much noob tampering. – Orian Feb 11 '17 at 13:44
  • 1
    rpc.statd is used with NFS to keep information on file locks when clients die. I have one server having statd running and another one without, but both work, so I don't know the reason. For more information see the manpage. Regarding your netstat output, it is OK: rpc.mountd is listening on port 32767 tcp(6) and udp(6) as you configured. What do you mean with 'different port is used'? For my remark: It was just for the record; you may forget it. – ridgy Feb 11 '17 at 14:20
  • Once I got statd up and running on 32765, the mountd will no longer listen on 32767.. It uses three instances (?) using three totally different ports... All labeled as "Listening". No matter what I have tried, it will not "bind" ? the port specified in /etc/default... – Orian Feb 11 '17 at 14:30
  • How did you manage to get statd running? In nfs-common configuration (the one we edited) there is an entry # Do you want to start the statd daemon? It is not needed for NFSv4. NEED_STATD= I left this one empty, so it works. When rpc.mountddoes not bind to the one port you defined, there really will be three entries with different ports. Try without rpc.statd, when running NFS4. – ridgy Feb 11 '17 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.