All of lore.kernel.org
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: Patrick Goetz <pgoetz@math.utexas.edu>
Cc: linux-nfs@vger.kernel.org
Subject: Re: rpcbind redux
Date: Thu, 1 Oct 2020 14:30:36 -0400	[thread overview]
Message-ID: <20201001183036.GD1496@fieldses.org> (raw)
In-Reply-To: <6b0c5514-ebb1-fde7-abba-7f4130b3d59f@math.utexas.edu>

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?

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:30 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 [this message]
2020-10-01 18:41   ` Patrick Goetz
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=20201001183036.GD1496@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=pgoetz@math.utexas.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.