+++ 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!