RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1293933 - nfs-server fails to start on atomic host
Summary: nfs-server fails to start on atomic host
Keywords:
Status: CLOSED DUPLICATE of bug 1406164
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Filesystem QE
URL:
Whiteboard:
: 1394395 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-23 15:11 UTC by Scott Dodson
Modified: 2017-02-28 14:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-28 14:42:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1396384 0 high CLOSED The nfs volume can't be access after upgrade to atomic host v7.3.1 2021-02-22 00:41:40 UTC

Internal Links: 1396384

Description Scott Dodson 2015-12-23 15:11:25 UTC
Description of problem:
It's probably unwise to run atomic host as an NFS server and maybe there are plans to containerize it? However nfs-utils package is installed but nfs-server fails due to missing /var/lib/nfs/{etab,mtab,state} files.

Version-Release number of selected component (if applicable):
2015-12-03 19:40:36     7.2.1     aaf67b91fa     rhel-atomic-host     rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard

How reproducible:
100%

Steps to Reproduce:
1. systemctl start nfs-server

Actual results:
rpc.mountd fails to start

systemd[1]: Starting NFSv4 ID-name mapping service...
systemd[1]: Reached target Host and Network Name Lookups.
systemd[1]: Starting Host and Network Name Lookups.
systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
systemd[1]: Reached target RPC Port Mapper.
systemd[1]: Starting RPC Port Mapper.
systemd[1]: Started Kernel Module supporting RPCSEC_GSS.
systemd[1]: Starting NFS Mount Daemon...
systemd[1]: Started RPC security service for NFS client and server.
systemd[1]: Started RPC security service for NFS server.
systemd[1]: Starting RPC bind service...
rpc.statd[2796]: Version 1.3.0 starting
rpc.statd[2796]: Flags: TI-RPC
rpc.statd[2796]: Initializing NSM state
systemd[1]: Started RPC bind service.
systemd[1]: Started NFSv4 ID-name mapping service.
rpc.mountd[2794]: couldn't open /var/lib/nfs/etab
systemd[1]: nfs-mountd.service: control process exited, code=exited status=1
systemd[1]: Failed to start NFS Mount Daemon.
systemd[1]: Dependency failed for NFS server and services.
systemd[1]: Job nfs-server.service/start failed with result 'dependency'.
systemd[1]: Unit nfs-mountd.service entered failed state.
systemd[1]: nfs-mountd.service failed.


Expected results:
nfs-server starts successfully

Additional info:

Comment 2 Scott Dodson 2015-12-23 15:50:10 UTC
I was pointed to this mailing list discussion on the topic. It seems like the outcome was that installation of nfs-utils installed only for client use cases though there were some differing opinions.

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-October/msg00081.html

Comment 3 Colin Walters 2016-01-04 16:45:56 UTC
It'd be best if nfs-utils learned to create those files automatically if they don't exist for compatibility with the OSTree model.

Comment 4 Scott Dodson 2016-01-04 16:49:35 UTC
Oh, sorry, one important note I should've added is that those files do exist in the RPMs. So I suspect this is a problem with atomic build process.

Comment 5 Colin Walters 2016-01-04 16:55:56 UTC
(In reply to Scott Dodson from comment #4)
> Oh, sorry, one important note I should've added is that those files do exist
> in the RPMs. So I suspect this is a problem with atomic build process.

It's a currently intentional part of rpm-ostree - we only take directories from RPMs, but the goal is to convert all content in /var into systemd-tmpfiles units owned by the packages.

This *could* change but it's just better if /var stays clean by default so that backups only snapshot data you care about, etc.

e.g. if a system isn't actually using NFS, no reason to back up those files, etc.

Comment 6 Steve Dickson 2016-01-04 20:24:25 UTC
First of all.. this will have to go through upstream so
there should probably be a Fedora bz opened up
so people see it..

(In reply to Colin Walters from comment #5)
> (In reply to Scott Dodson from comment #4)
> > Oh, sorry, one important note I should've added is that those files do exist
> > in the RPMs. So I suspect this is a problem with atomic build process.
> 
> It's a currently intentional part of rpm-ostree - we only take directories
> from RPMs, but the goal is to convert all content in /var into
> systemd-tmpfiles units owned by the packages.
While its true /var/lib/nfs/{etab,mtab,rmtab} are installed
from the RPM... Its not clear to me they need to
be since they are used but they are legacy ones
used with v3, so maybe something could be done.

Also these are all defined at compile time so
they could be moved other places.

> systemd[1]: Started NFSv4 ID-name mapping service.
> rpc.mountd[2794]: couldn't open /var/lib/nfs/etab
exportfs could create this since it has to be run
before mountd but we would have to deal with race
conditions.

> 
> This *could* change but it's just better if /var stays clean by default so
> that backups only snapshot data you care about, etc.
The directories under /var/lib/nfs store state that is
needed for reboots so throwing them under systemd-tmpfiles
I don't think will work.

Comment 7 Colin Walters 2016-01-04 20:37:08 UTC
(In reply to Steve Dickson from comment #6)
> 
> Also these are all defined at compile time so
> they could be moved other places.

I think the location is fine.

> The directories under /var/lib/nfs store state that is
> needed for reboots so throwing them under systemd-tmpfiles
> I don't think will work.

On an OSTree system, /var is persistent by default.  systemd-tmpfiles is just a good way to ensure directories (and files) exist there on boot if they didn't already.

Comment 8 Colin Walters 2016-11-11 21:52:03 UTC
*** Bug 1394395 has been marked as a duplicate of this bug. ***

Comment 9 Colin Walters 2017-02-28 14:42:28 UTC

*** This bug has been marked as a duplicate of bug 1406164 ***


Note You need to log in before you can comment on or make changes to this bug.