Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1245804

Summary: Cannot properly enable the nfs-secure service
Product: Red Hat Enterprise Linux 7 Reporter: Steve Dickson <steved>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Yongcheng Yang <yoyang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: bfields, chuck.lever, eguan, extras-qa, fs-qe, harshula, jlayton, nos, redhat.bugzilla, steved
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nfs-utils-1.3.0-0.15.el Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1173564 Environment:
Last Closed: 2015-11-19 04:30:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1173564    
Bug Blocks:    

Description Steve Dickson 2015-07-22 20:03:57 UTC 
+++ This bug was initially created as a clone of Bug #1173564 +++

Description of problem:

I have an nfsv4 mount, secured with kerberos, specified in /etc/fstab as:

box:/                           /mnt/box                nfs4    sec=krb5,intr,soft 0 0

To be able to mount this automatically at boot time, it appears the "nfs-secure" service must be running.
If I run 'systemctl start nfs-secure', then 'mount /mnt/box' mounts the share properly, but /mnt/box fails to mount automatically when booting.

Trying to enable nfs-secure.service fails:

# systemctl enable nfs-secure
Failed to execute operation: No such file or directory

What is the proper procedure to make a krb5 secured nfsv4 share mount at boot time ?

I can make this work, so the /mnt/box share gets mounted at boot time, by manually running:

ln -s /usr/lib/systemd/system/nfs-secure.service  /etc/systemd/system/multi-user.target.wants/nfs-secure.service

But since 'systemctl enable nfs-secure' should do something similar (??), there seem to be something wrong.


Version-Release number of selected component (if applicable):
nfs-utils-1.3.1-2.0.fc21.x86_64

--- Additional comment from Steve Dickson on 2014-12-12 10:06:25 EST ---

(In reply to Nils Olav Selesdal from comment #0)
> Description of problem:
> 
> I have an nfsv4 mount, secured with kerberos, specified in /etc/fstab as:
> 
> box:/                           /mnt/box                nfs4   
> sec=krb5,intr,soft 0 0
> 
> To be able to mount this automatically at boot time, it appears the
> "nfs-secure" service must be running.
> If I run 'systemctl start nfs-secure', then 'mount /mnt/box' mounts the
> share properly, but /mnt/box fails to mount automatically when booting.
> 
> Trying to enable nfs-secure.service fails:
> 
> # systemctl enable nfs-secure
> Failed to execute operation: No such file or directory
> 
> What is the proper procedure to make a krb5 secured nfsv4 share mount at
> boot time ?
> 
the nfs-secure.service is now a symlink to the rpc.gssd.service which
 now part of the nfs-client.target script, which should be enabled by default. 
Please check to see it is with
   systemctl status nfs-client.target

The daemon will be automatically started with the existence of the 
 /etc/krb5.keytab file. 

which means systemctl enable nfs-secure is no longer needed which is why it fails.

--- Additional comment from Nils Olav Selåsdal on 2014-12-12 10:18:11 EST ---

# systemctl status nfs-client.target
nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled)
   Active: inactive (dead)


Running 'systemctl enable  nfs-client.target' solves this, and mounts the nfs share at boot.


(Setting up an nfs client should probably be documented somewhere, or the nfs-client.target should be enabled automatically if /etc/fstab contains an nfs4 mount point)

--- Additional comment from Steve Dickson on 2014-12-13 10:52:48 EST ---

(In reply to Nils Olav Selesdal from comment #2)
> # systemctl status nfs-client.target
> nfs-client.target - NFS client services
>    Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled)
>    Active: inactive (dead)
> 
> 
> Running 'systemctl enable  nfs-client.target' solves this, and mounts the
> nfs share at boot.
> 
> 
> (Setting up an nfs client should probably be documented somewhere, or the
> nfs-client.target should be enabled automatically if /etc/fstab contains an
> nfs4 mount point)

Its the latter... I'll take care of it....

--- Additional comment from Fedora Update System on 2014-12-14 14:02:06 EST ---

nfs-utils-1.3.1-4.0.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.0.fc21

--- Additional comment from Fedora Update System on 2014-12-16 23:40:20 EST ---

Package nfs-utils-1.3.1-4.0.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.3.1-4.0.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.0.fc21
then log in and leave karma (feedback).

--- Additional comment from Bas Mevissen on 2014-12-23 18:46:57 EST ---

I just installed this package. Something went horribly wrong with it. First, it took ages to install. The "yum update" was hanging at the installation of nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it continued without any message.

After a reboot, the init process kept trying to start nfs client target (looking at the systemd screen output). So I could not get to the login prompt (not a nice behaviour BTW, one should expect network connections to fail occasionally).

System is a notebook, connected to the network/internet via wifi. Wifi light was flashing during attempted boot, so it looks like there was some network activity. Up to date with current updates, updates-testing and rpmfusion (non)free updates and updates-testing. Kernel 3.17.7-300.fc21.x86_64, but failed on other kernels too (even on fc20 kernel). System is updated from fc20 and before.

It took me a while to find out the nfs-client target was not starting and holding up boot. After disabling the nfs-client.target, boot went fine again.

My /etc/fstab does not contain any NFS or any other remote mount, only a few entries for the local disk partitions.

If I can be of any help in debugging this, please let me know.

--- Additional comment from Steve Dickson on 2015-01-02 09:19:07 EST ---

(In reply to Bas Mevissen from comment #6)
> I just installed this package. Something went horribly wrong with it. First,
> it took ages to install. The "yum update" was hanging at the installation of
> nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it
> continued without any message.
I've heard other complaints about the install taking forever... I didn't think
it had to do with nfs-utils.... but maybe there is something timing out.
 
> 
> After a reboot, the init process kept trying to start nfs client target
> (looking at the systemd screen output). So I could not get to the login
> prompt (not a nice behaviour BTW, one should expect network connections to
> fail occasionally).
The nfs-client.target is not started... it just enabled or disabled. If it
is enable then other daemon are started. I see this:

[  OK  ] Reached target NFS client services

Is that where its hanging?


> 
> System is a notebook, connected to the network/internet via wifi. Wifi light
> was flashing during attempted boot, so it looks like there was some network
> activity. Up to date with current updates, updates-testing and rpmfusion
> (non)free updates and updates-testing. Kernel 3.17.7-300.fc21.x86_64, but
> failed on other kernels too (even on fc20 kernel). System is updated from
> fc20 and before.
> 
> It took me a while to find out the nfs-client target was not starting and
> holding up boot. After disabling the nfs-client.target, boot went fine again.
Would it be possible to show me the exact place the boot was hanging?
Also what version of rpcbind are you using?

--- Additional comment from Fedora Update System on 2015-01-03 09:39:47 EST ---

nfs-utils-1.3.1-4.1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.1.fc21

--- Additional comment from Fedora Update System on 2015-01-03 14:11:47 EST ---

Package nfs-utils-1.3.1-4.1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.3.1-4.1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.1.fc21
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2015-01-14 02:28:27 EST ---

nfs-utils-1.3.1-4.1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from Bas Mevissen on 2015-01-14 10:06:50 EST ---

(In reply to Steve Dickson from comment #7)
> (In reply to Bas Mevissen from comment #6)
> > I just installed this package. Something went horribly wrong with it. First,
> > it took ages to install. The "yum update" was hanging at the installation of
> > nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it
> > continued without any message.
> I've heard other complaints about the install taking forever... I didn't
> think it had to do with nfs-utils.... but maybe there is something timing out.
>  

It was exactly there and took ages.

> The nfs-client.target is not started... it just enabled or disabled. If it
> is enable then other daemon are started. I see this:
> 
> [  OK  ] Reached target NFS client services
> 
> Is that where its hanging?
> 

Yes, indeed.

> Would it be possible to show me the exact place the boot was hanging?
> Also what version of rpcbind are you using?

Notebook has received updates in the mean time. So I cannot reproduce the exact situation any more. Would it be useful to enable the nfs-client.target again and see if it still hangs?

I tried in a cleanly installed virtual machine and there it seems to be fine.

--- Additional comment from Steve Dickson on 2015-06-08 10:51:00 EDT ---

(In reply to Bas Mevissen from comment #11)
> (In reply to Steve Dickson from comment #7)
> > (In reply to Bas Mevissen from comment #6)
> > > I just installed this package. Something went horribly wrong with it. First,
> > > it took ages to install. The "yum update" was hanging at the installation of
> > > nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it
> > > continued without any message.
> > I've heard other complaints about the install taking forever... I didn't
> > think it had to do with nfs-utils.... but maybe there is something timing out.
> >  
> 
> It was exactly there and took ages.
> 
> > The nfs-client.target is not started... it just enabled or disabled. If it
> > is enable then other daemon are started. I see this:
> > 
> > [  OK  ] Reached target NFS client services
> > 
> > Is that where its hanging?
> > 
> 
> Yes, indeed.
> 
> > Would it be possible to show me the exact place the boot was hanging?
> > Also what version of rpcbind are you using?
> 
> Notebook has received updates in the mean time. So I cannot reproduce the
> exact situation any more. Would it be useful to enable the nfs-client.target
> again and see if it still hangs?
> 
> I tried in a cleanly installed virtual machine and there it seems to be fine.
OK... thanks for the information!
Comment 1 Steve Dickson 2015-07-22 20:05:28 UTC 
The Fedora commit that fixes the problem
commit a6e040b49c7ffe2a7647b3c4e904ee5d8d8d2d82
Author: Steve Dickson <steved>
Date:   Sun Dec 14 13:31:00 2014 -0500

    Make sure nfs-client target is enabled (bz 1173564)
Comment 4 Yongcheng Yang 2015-08-06 07:12:02 UTC 
Verified with nfs-utils-1.3.0-0.17.el7.x86_64

Maybe we should change the bug summary to be: "Make sure nfs-client target is enabled", since there is nothing related with nfs-secure.service

[root@ibm-x3250m4-07 ~]# rpm -q nfs-utils
nfs-utils-1.3.0-0.13.el7.x86_64
[root@ibm-x3250m4-07 ~]#  systemctl is-enabled nfs-client.target
disabled
[root@ibm-x3250m4-07 ~]# rpm -Uvh nfs-utils-1.3.0-0.17.el7.x86_64.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:nfs-utils-1:1.3.0-0.17.el7       ################################# [ 50%]
post 1=2
Cleaning up / removing...
   2:nfs-utils-1:1.3.0-0.13.el7       ################################# [100%]
[root@ibm-x3250m4-07 ~]#  systemctl is-enabled nfs-client.target
enabled
[root@ibm-x3250m4-07 ~]# 
[root@ibm-x3250m4-07 ~]# reboot
Connection to ibm-x3250m4-07.rhts.eng.nay.redhat.com closed by remote host.
Connection to ibm-x3250m4-07.rhts.eng.nay.redhat.com closed.
[root@ibm-x3250m4-07 ~]# systemctl is-enabled nfs-client.target
enabled
[root@ibm-x3250m4-07 ~]# systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; enabled; vendor preset: disabled)
   Active: active since Thu 2015-08-06 15:01:46 CST; 2min 13s ago

Aug 06 15:01:46 ibm-x3250m4-07.rhts.eng.nay.redhat.com systemd[1]: Reached target NFS client services.
Aug 06 15:01:46 ibm-x3250m4-07.rhts.eng.nay.redhat.com systemd[1]: Starting NFS client services.
[root@ibm-x3250m4-07 ~]# 

Compare nfs-utils.spec of nfs-utils version 1.3.0-0.15.el7 & 1.3.0-0.14.el7
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[yyc@dhcp-12-138 ~]$ diff rpmbuild.nfs-utils-1.3.0-0.15/SPECS/nfs-utils.spec rpmbuild.nfs-utils-1.3.0-0.14/SPECS/
5c5
< Release: 0.15%{?dist}
---
> Release: 0.14%{?dist}
253a254
> 
301,306c302
< echo "post 1=$1"
< if [ $1 -eq 1 ] ; then
< 	# Initial installation
< 	/bin/systemctl enable nfs-client.target >/dev/null 2>&1 || :
< 	/bin/systemctl restart nfs-config  >/dev/null 2>&1 || :
< fi
---
> %systemd_post nfs-client.target
344,350d339
< %triggerin -- nfs-utils > 1:1.3.0-0.1
< # reset configuration files and running daemons
< if [ $1 -eq 2 ] ; then
< 	/bin/systemctl enable nfs-client.target >/dev/null 2>&1 || :
< 	/bin/systemctl restart nfs-config  >/dev/null 2>&1 || :
< fi
< 
397,399d385
< * Thu Jul 23 2015 Steve Dickson <steved> 1.3.0-0.15
< - Make sure nfs-client target is enabled (bz 1245804)
< 
[yyc@dhcp-12-138 ~]$ 

Move it to VERIFIED
Comment 5 errata-xmlrpc 2015-11-19 04:30:01 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2196.html