linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Goetz <pgoetz@math.utexas.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: rpcbind redux
Date: Thu, 1 Oct 2020 13:41:39 -0500	[thread overview]
Message-ID: <f621c004-3402-09d0-b2d0-83d610525a7c@math.utexas.edu> (raw)
In-Reply-To: <20201001183036.GD1496@fieldses.org>

Hi Bruce,

Thanks for the reply. See below.

On 10/1/20 1:30 PM, J. Bruce Fields wrote:
> On Fri, Sep 25, 2020 at 09:40:16AM -0500, Patrick Goetz wrote:
>> My University information security office does not like rpcbind and
>> will automatically quarantine any system for which they detect a
>> portmapper running on an exposed port.
>>
>> Since I exclusively use NFSv4 I was happy to "learn" that NFSv4
>> doesn't require rpcbind any more.  For example, here's what it says
>> in the current RHEL documentation:
>>
>> "NFS version 4 (NFSv4) works through firewalls and on the Internet,
>> no longer requires an rpcbind service, supports Access Control Lists
>> (ACLs), and utilizes stateful operations."
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_file_systems/exporting-nfs-shares_managing-file-systems#introduction-to-nfs_exporting-nfs-shares
>>
>> I'm using Ubuntu 20.04 rather than RHEL, but the nfs-server service
>> absolutely will not start if it can't launch rpcbind as a precursor:
>>
>> -----------------------------
>> root@helios:~# systemctl stop rpcbind
>> Warning: Stopping rpcbind.service, but it can still be activated by:
>>    rpcbind.socket
>> root@helios:~# systemctl mask rpcbind
>> Created symlink /etc/systemd/system/rpcbind.service → /dev/null.
>>
>> root@helios:~# systemctl restart nfs-server
>> Job for nfs-server.service canceled.
>> root@helios:~# systemctl status nfs-server
>> ● nfs-server.service - NFS server and services
>>       Loaded: loaded (/lib/systemd/system/nfs-server.service;
>> enabled; vendor preset: enabled)
>>      Drop-In: /run/systemd/generator/nfs-server.service.d
>>               └─order-with-mounts.conf
>>       Active: failed (Result: exit-code) since Fri 2020-09-25
>> 14:21:46 UTC; 10s ago
>>      Process: 3923 ExecStartPre=/usr/sbin/exportfs -r (code=exited,
>> status=0/SUCCESS)
>>      Process: 3925 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
>> (code=exited, status=1/FAILURE)
>>      Process: 3931 ExecStopPost=/usr/sbin/exportfs -au (code=exited,
>> status=0/SUCCESS)
>>      Process: 3932 ExecStopPost=/usr/sbin/exportfs -f (code=exited,
>> status=0/SUCCESS)
>>     Main PID: 3925 (code=exited, status=1/FAILURE)
>>
>> Sep 25 14:21:46 helios systemd[1]: Starting NFS server and services...
>> Sep 25 14:21:46 helios rpc.nfsd[3925]: rpc.nfsd: writing fd to
>> kernel failed: errno 111 (Connection refused)
>> Sep 25 14:21:46 helios rpc.nfsd[3925]: rpc.nfsd: unable to set any
>> sockets for nfsd
>> Sep 25 14:21:46 helios systemd[1]: nfs-server.service: Main process
>> exited, code=exited, status=1/FAILURE
>> Sep 25 14:21:46 helios systemd[1]: nfs-server.service: Failed with
>> result 'exit-code'.
>> Sep 25 14:21:46 helios systemd[1]: Stopped NFS server and services.
>> -----------------------------
>>
>> So, now I'm confused.  Does NFSv4 need rpcbind to be running, does
>> it just need it when it launches, or something else?  I made a local
>> copy of the systemd service file and edited out the rpcbind
>> dependency, so it's not that.
> 
> Do you have v2 and v3 turned off in /etc/nfs.conf?

It's an Ubuntu system, hence doesn't use /etc/nfs.conf; however I do 
have these variables set in /etc/default/nfs-kernel-server :

   MOUNTD_NFS_V2="no"
   MOUNTD_NFS_V3="no"
   RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"

maybe this isn't the correct way to disable NFSv2/3, but it's all I 
could find documented.

The linux kernel version is 5.4.0, and the nfs-kernel-server package 
version is 1:1.3.4-2.5ubuntu3.3 (so upstream 1.3.4), but I'm not sure 
this is relevant.

> 
> If yes, and nfsd is still refusing to start, that sounds like an nfsd
> bug; with v4 only it should definitely be ignoring any failures to
> contact rpcbind.
> 
> --b.
> 

  reply	other threads:[~2020-10-01 18:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 14:40 rpcbind redux Patrick Goetz
2020-10-01 18:30 ` J. Bruce Fields
2020-10-01 18:41   ` Patrick Goetz [this message]
2020-10-01 20:06     ` J. Bruce Fields
2020-10-01 21:05       ` Patrick Goetz
2020-10-01 21:43         ` J. Bruce Fields
2020-10-02 15:12           ` Patrick Goetz
2020-10-05 13:54             ` J. Bruce Fields
2020-10-05 22:55               ` McIntyre, Vincent (CASS, Marsfield)
2020-10-05 23:20                 ` Patrick Goetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f621c004-3402-09d0-b2d0-83d610525a7c@math.utexas.edu \
    --to=pgoetz@math.utexas.edu \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).