Bug 1173564

Summary: Cannot properly enable the nfs-secure service
Product: [Fedora] Fedora Reporter: Nils Olav Selåsdal <nos>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: abuse, bfields, jlayton, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nfs-utils-1.3.1-4.1.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1245804 (view as bug list) Environment:
Last Closed: 2015-01-14 07:28:27 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:    
Bug Blocks: 1245804    

Description Nils Olav Selåsdal 2014-12-12 12:28:04 UTC
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

Comment 1 Steve Dickson 2014-12-12 15:06:25 UTC
(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.

Comment 2 Nils Olav Selåsdal 2014-12-12 15:18:11 UTC
# 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)

Comment 3 Steve Dickson 2014-12-13 15:52:48 UTC
(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....

Comment 4 Fedora Update System 2014-12-14 19:02:06 UTC
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

Comment 5 Fedora Update System 2014-12-17 04:40:20 UTC
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).

Comment 6 Bas Mevissen 2014-12-23 23:46:57 UTC
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.

Comment 7 Steve Dickson 2015-01-02 14:19:07 UTC
(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?

Comment 8 Fedora Update System 2015-01-03 14:39:47 UTC
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

Comment 9 Fedora Update System 2015-01-03 19:11:47 UTC
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).

Comment 10 Fedora Update System 2015-01-14 07:28:27 UTC
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.

Comment 11 Bas Mevissen 2015-01-14 15:06:50 UTC
(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.

Comment 12 Steve Dickson 2015-06-08 14:51:00 UTC
(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!